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

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.


Visualizing and Measuring Software Portfolio Architectures: A Flexibility Analysis

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.


The Architecture of Platforms: A Unified View

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.


Organizational Design for Distributed Innovation

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 Impact of Component Modularity on Design Evolution: Evidence from the Software Industry

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.


Hidden Structure: Using Network Methods to Map System Architecture

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.