A Methodology for Operationalizing Enterprise Architecture and Evaluating Enterprise IT Flexibility

A Methodology for Operationalizing Enterprise Architecture and Evaluating Enterprise IT Flexibility by Alan MacCormack, Robert Lagerstrom, and Carliss Y. Baldwin

We propose a network-based methodology for operationalizing enterprise architecture. Our methodology is based upon using a “Design Structure Matrix” (DSM) to capture the coupling between different components in a firm’s architecture, including business and technology-related aspects. We apply our methodology to data gathered in a large pharmaceutical firm. We show that this methodology helps to identify layers in the firm’s architecture associated with different technologies (e.g., applications, servers and databases). We also show that it reveals the main “flow of control” within the architecture, as denoted by the classification of components into Core, Peripheral, Shared and Control elements. We analyze the cost of change for a subset of software applications within this architecture. We find that the cost of change is associated with the degree to which applications are highly coupled. We show the best measure of coupling that predicts the cost of change is one that captures all the direct and indirect connections between components. We believe our work constitutes an important step in making the concept of enterprise architecture more operational, improving a firm’s ability to analyze its architecture, understand its performance implications, and adapt and improve it in the future.

Read Paper

Contact the Authors:

Trade-offs Between Productivity and Quality in Selecting Software Development Practices

Trade-offs between Productivity and Quality in Selecting Software Development Practices by Alan MacCormack, Chris F. Kemerer, Michael A. Cusumano, and Bill Crandall 

Choosing appropriate practices for a project can be hard, given the various dimensions of performance each claims to optimize. Using data from 29 projects, this study examines the impact of eight development practices on both productivity and quality. Results suggest managers should choose a coherent system of practices on the basis of the specific objectives the software must meet.

Read Full Article

Faculty Member Outlines Values of Software System Architecture

Faculty Member Outlines Value of Software System Architecture by Alan MacCormack

Over the last 10 to 15 years, even the most traditional of industries have come to rely on software, for everything from inventory control to vehicle navigation. The average automobile today has more software than the first Apollo moon rocket. Your garden variety microwave may even have an algorithm for cooking popcorn to fit your specific tastes. Despite this dramatic increase in the pervasiveness and importance of software, however, many companies lack a fundamental understanding of the architecture underlying their code. This problem costs firms millions of dollars per year.

Read Full Article

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

The Impact of Component Modularity on Design Evolution: Evidence from the Software Industry by Alan MacCormack, John Rusnak and Carliss Y. Baldwin

Much academic work asserts a relationship between the design of a complex system and the manner in which this system evolves over time. In particular, designs which are modular in nature are argued to be more “evolvable,” in that these designs facilitate making future adaptations, the nature of which do not have to be specified in advance. In essence, modularity creates “option value” with respect to new and improved designs, which is particularly important when a system must meet uncertain future demands.

Despite the conceptual appeal of this research, empirical work exploring the relationship between modularity and evolution has had limited success. Three major challenges persist: first, it is difficult to measure modularity in a robust and repeatable fashion; second, modularity is a property of individual components, not systems as a whole, hence we must examine these dynamics at the microstructure level; and third, evolution is a temporalphenomenon, in that the conditions at time t affect the nature of the design at time t+1, hence exploring this phenomenon requires longitudinal data.

In this paper, we tackle these challenges by analyzing the evolution of a successful commercial software product over its entire lifetime, comprising six major “releases.” In particular, we develop measures of modularity at the component level, and use these to predict patterns of evolution between successive versions of the design. We find that modularity has a strong and unambiguous impact on design evolution. Specifically, we show that i) tightly-coupled components are “harder to kill,” in that they have a greater likelihood of survival in subsequent versions of a design; ii) tightly-coupled components are “harder to maintain,” in that they experience more surprise changes to their dependency relationships that are not associated with new functionality; and iii) tightly-coupled components are “harder to augment,” in that the mix of new components added in each version is significantly more modular than the legacy design.

Read Paper

Evolution Analysis of Large-Scale Software Systems Using Design Structures Matrices and Design Rule Theory

Evolution Analysis of Large-Scale Software Systems Using Design Structure Matrices and Design Rule Theory by Matthew J. LaMantia, Yuanfang Cai, Alan David MacCormack and John Rusnak

Designers often seek modular architectures to better accommodate expected changes and to enable parallel development. However, we lack a formal theory and model of modularity and software evolution, which can be used for description, prediction, and prescription. According to Baldwin and Clark’s  theory, modular architectures add value to system designs by creating options to improvethe system by substituting or experimenting on individual modules. In this paper, we evaluate their theory by looking at the design evolution of two software product platforms through the modeling lens of design structure matrices (DSMs) and design rule theory. Our analysis shows that DSM models and options theory can explain how real-world modularization activities in one case allowed for different rates of evolution in different software modules and in another case conferred distinct strategic advantages on a firm (by permitting substitution of an at-risk software module without substantial change to the rest of the system). The experiment supports our hypothesis that these formal models and theory can account for important aspects of software design evolution in large-scale systems.

Read Paper

Visualizing and Measuring Software Portfolio Architectures: A Flexibility Analysis

Visualizing and Measuring Software Portfolio Architectures: A Flexibility Analysis by Robert Lagerstrom, Carliss Y. Baldwin, Alan MacCormack, and David Dreyfus

In this paper, we test a method for visualizing and measuring software portfolio architectures and use our 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. We show that the architecture of this system can be classified as a “core-periphery” system, meaning it contains a single large dominant cluster of interconnected components (the “Core”) representing 32% of the system. We find that the classification of software applications within this architecture, as being either Core or Peripheral, is a significant predictor of the costs of architectural change. Using OLS regression models, we show that this measure has greater predictive power than prior measures of coupling used in the literature.

Read Paper

Visualizing and Measuring Enterprise Architecture: An Exploratory BioPharma Case

Visualizing and Measuring Enterprise Architecture: An Exploratory BioPharma Case by Robert Lagerstrom, Carliss Baldwin, Alan MacCormack and David Dreyfus

We test a method that was designed and used previously to reveal the hidden internal architectural structure of software systems. The focus of this paper is to test if it can also uncover new facts about the components and their relationships in an enterprise architecture, i.e., if the method can reveal the hidden external structure between architectural components. Our test uses data from a biopharmaceutical company. In total, we analyzed 407 components and 1,157 dependencies. Results show that the enterprise structure can be classified as a core-periphery architecture with a propagation cost of 23%, core size of 32%, and architecture flow through of 67%. We also found that business components can be classified as control elements, infrastructure components as shared, and software applications as belonging to the core. These findings suggest that the method could be effective in uncovering the hidden structure of an enterprise architecture.

Read Paper

Hidden Structure: Using Network Methods to Map System Architecture

“Hidden Structure: Using Network Methods to Map System Architecture” by Carliss BaldwinAlan MacCormack and John Rusnak

In this paper, we describe an operational methodology for characterising the architecture of complex technical systems and demonstrate its application to a large sample of software releases.  Our methodology is based upon directed network graphs, which allows us to identify all of the direct and indirect linkages between the components in a system. We use this approach to define three fundamental architectural patterns, which we label core-periphery, multi-core, and hierarchical. Applying our methodology to a sample of 1,286 software releases from 17 applications, we find that the majority of releases possess a “core-periphery” structure. This architecture is characterized by a single dominant cyclic group of components (the “Core”) that is large relative to the system as a whole as well as to other cyclic groups in the system. We show that the size of the Core varies widely, even for systems that perform the same function. These differences appear to be associated with different models of development—open, distributed organizations develop systems with smaller Cores, while closed, co-located organizations develop systems with larger Cores. Our findings establish some “stylized facts” about the fine-grained structure of large, real-world technical systems, serving as a point of departure for future empirical work.

Read Paper