Research

by Alan MacCormack, Carliss Baldwin, Robert Lagerström, and David Dreyfus

Carliss and Alan (with Robert Lagerström and David Dreyfus) test a method that was designed and used previously to reveal the hidden internal architectural structure of software to see if it can also uncover new facts about an enterprise architecture. The test uses data from a 407 interconnected software applications, databases, and services biopharmaceutical company.

This paper works to understand Department of Defense (DoD) contracting trends since the beginning of Better Buying Power (BBP). By using data publicly available from the Governmentwide Point of Entry (GPE), this paper concludes that there are no clear trends in the levels of competition in the DoD, as measured by ratios of Justifications and Approvals (J&A) to contract awards, as a result of BBP. However, this is not to say that BBP is ineffectual, but that methodologies are still needed to implement the guidance outlined in BBP. To that end, this paper proposes a methodology to identify salient data rights in computer software. Our aim is to provide a means for program managers to understand which data rights are most important to ensure future sustained competition.

This article by Ali Almossawi (student of Alan MacCormack) explores a particular facet of quality in Firefox, namely, maintainability. By appealing to the explanatory powers of five practical measures of architectural complexity, and with the aid of static analysis and network manipulation tools, we arrive at some preliminary findings.

On this website, Ali Almossawi (student of Alan’s) visualizes the evolution of the Firefox Codebase and presents a set of metrics for all releases of Firefox that are indicative of quality. The site allows one to inspect them through one of several views. By looking at changes in these metrics, one can see the evolution of the Firefox codebase over time. This work is also be useful as a retrospective, investigative tool to help infer when, say, architectural issues may be the cause for unfavorable user sentiment following a release.

In this case study, Dan Sturtevant explores the cost of complexity in a software firm with with hundreds of commercial products and $1B in revenue. Techniques for measuring software architecture (and its breakdown) were used to identify parts of codebases that were well structured and other parts that were less-so. In this setting, architecture problems led to a tripling of quality & risk problems, a 2.5X drop in development speed, and staff attrition problems for development teams working on code with architecture issues.

This paper by Alan and Carliss (with John Rusnak) describe a methodology for characterizing the architecture of software systems and demonstrate it using a sample 1,286 software releases. This methodology is based upon network graphs, which allow us to identify linkages between the components in a system and reason about modularity, abstraction layers, API’s etc. System properties are shown to vary widely between systems, even when different systems perform the same function. These differences seem to arise from differences in the design and development process, and the type of organization building them.

The Impact of Component Modularity on Design Evolution: Evidence from the Software Industry

by Carliss Baldwin, Alan MacCormack, and John Rusnak

Software designs which are modular in nature are more “evolvable,” in that these designs facilitate making future adaptations. In essence, modularity creates “option value” which is particularly important when a system must meet uncertain future demands. In this work, Alan & Carliss (with John Rusnak) break new ground exploring the relationship between modularity and evolution in real systems by analyzing the evolution of a successful commercial software product over its entire lifetime. They measure modularity and find that it has a strong impact on design evolution. Specifically, they find that tightly-coupled components are harder to kill, harder to maintain, and harder to harder to adapt & improve.

In this paper, Carliss says that business ecosystems have become increasingly prevalent in many industries. These ecosystems encompass numerous corporations, individuals, and communities that are autonomous but related through their connection with an underlying, evolving technical system. In the future, Carliss believes the key problem for organization design will be the management of distributed innovation. Organization designers must think about how to distribute property rights, people, and activities across numerous self-governing enterprises in ways that are advantageous for the group as well as each player. Software architecture design (i.e. the use of modular components, web services, abstraction layers, platforms, and APIs) will play a key role.

The central role of “platform” products and services in mediating the activities of disaggregated “clusters” or “ecosystems” of firms has been widely recognized. But platforms and the systems in which they are embedded are very diverse. In particular, platforms may exist within firms as product lines, across firms as multi-product systems, and in the form of multi-sided markets. In this paper, Carliss (with Jason Woodward) argues that there is a fundamental unity in the architecture of platforms, discusses APIs, stability, control, and evolution. They conclude by addressing a number of fundamental strategic questions suggested by a unified view of platforms.

by Alan MacCormack, Carliss Baldwin, Robert Lagerström, and David Dreyfus

In this paper, Carliss and Alan (with Robert Lagerström and David Dreyfus) test a method for visualizing and measuring enterprise architectures (i.e. software portfolio architectures), and use measures to predict the costs of architectural change. Our data is drawn from a biopharmaceutical company, comprising 407 architectural components with 1,157 dependencies between them.

Technical Debt and System Architecture: The impact of coupling on defect-related activity

by Alan MacCormack & Dan Sturtevant

Technical debt is created when design decisions that are expedient in the short-term increase the costs of maintaining and adapting this system in future. In this article, Alan MacCormack and Daniel Sturtevant explain that as systems grow and evolve, their architectures can degrade, increasing maintenance costs and reducing developer productivity. This raises the question if and when it might be appropriate to redesign (“refactor”) a system, to reduce what has been called “architectural debt.” Unfortunately, they lack of robust data by which to evaluate the relationship between architectural design choices and system maintenance costs, and hence to predict the value that might be released through such refactoring efforts. Alan and Daniel address this gap by analyzing the relationship between system architecture and maintenance costs for two software systems of similar size but with very different structures: one has a “Hierarchical” design, the other has a “Core-Periphery” design. They measure the level of system coupling for the 20,000+ components in each system and use these measures to predict maintenance efforts or “defect-related activity.” Their results generate insight into how architectural debt can be assessed by understanding patterns of coupling among components in a system.