- 09 Mar 2017
- Working Paper Summaries
Exploring the Relationship Between Architecture Coupling and Software Vulnerabilities: A Google Chrome Case
Managing software vulnerabilities is a top issue in today’s society. By studying the Google Chrome codebase, the authors explore software metrics including architecture coupling measures in relation to software vulnerabilities. This paper adds new findings to research on software metrics and vulnerabilities, bringing the field closer to generalizable and conclusive results.
- 13 Feb 2015
- Working Paper Summaries
A Methodology for Operationalizing Enterprise Architecture and Evaluating Enterprise IT Flexibility
When dealing with complex information system architectures, changes often propagate in unexpected ways, increasing the costs of adapting the system to future needs. In this paper the authors use data from a real firm and develop a robust network-based methodology by which to visualize and measure any firm's enterprise architecture. They also explore the dynamics of how different types of coupling influence the flexibility of enterprise architectures. They conclude with insights for practicing managers who must, for example, allocate resources and identify opportunities for system redesign. Closed for comment; 0 Comments.
- 25 Jun 2014
- Lessons from the Classroom
FIELD Trip: Conquering the Gap Between Knowing and Doing
Forget what you remember about school field trips. Harvard Business School is in its fourth year of a bold innovation that ships all first-year students on global excursions. FIELD leaders Alan MacCormack and Tony Mayo describe lessons learned so far. Open for comment; 0 Comments.
- 09 Apr 2014
- Working Paper Summaries
Visualizing and Measuring Software Portfolio Architectures: A Flexibility Analysis
Contemporary business environments are constantly evolving, requiring continual changes to the software applications that support a business. Moreover, during recent decades, the sheer number of applications has grown significantly, and they have become increasingly interdependent. Many companies find that managing applications and implementing changes to their application portfolio architecture is increasingly difficult and expensive. Firms need a way to visualize and analyze the modularity of their software portfolio architectures and the degree of coupling between components. In this paper, the authors test a method for visualizing and measuring software portfolio architectures using data of a biopharmaceutical firm's enterprise architecture. The authors also use the measures to predict the costs of architectural change. Findings show, first, that the biopharmaceutical firm's enterprise architecture can be classified as core-periphery. This means that 1) there is one cyclic group (the "Core") of components that is substantially larger than the second largest cyclic group, and 2) this group comprises a substantial portion of the entire architecture. In addition, the classification of applications in the architecture (as being in the Core or the Periphery) is significantly correlated with architectural flexibility. In this case the architecture has a propagation cost of 23 percent, meaning almost one-quarter of the system may be affected when a change is made to a randomly selected component. Overall, results suggest that the hidden structure method can reveal new facts about an enterprise architecture. This method can aid the analysis of change costs at the software application portfolio level. Key concepts include: This method for architectural visualization could provide valuable input when planning architectural change projects (in terms of, for example, risk analysis and resource planning). The method reveals a "hidden" core-periphery structure, uncovering new facts about the architecture that could not be gained from other visualization procedures or standard metrics. Compared to other measures of complexity, coupling, and modularity, this method considers not only the direct dependencies between components but also the indirect dependencies. These indirect dependencies provide important input for management decisions. Closed for comment; 0 Comments.
- 04 Mar 2014
- Sharpening Your Skills
Sharpening Your Skills: Managing Innovation
Sharpening Your Skills curates a wide range of Harvard Business School's research and ideas around vital topics in business management. Closed for comment; 0 Comments.
- 16 Jul 2013
- Working Paper Summaries
Visualizing and Measuring Enterprise Architecture: An Exploratory BioPharma Case
Achieving effective and efficient management of the software application landscape requires an ability to visualize and measure the current status of the enterprise architecture. To a large extent, this huge challenge can be addressed by introducing tools such as enterprise architecture modeling as a means of abstraction. In recent years, Enterprise Architecture (EA) has become an established discipline for business and software application management. Ideally, EA aids the stakeholders of the enterprise to effectively plan, design, document, and communicate IT and business related issues. Unfortunately, though, EA frameworks rarely explicitly state the kinds of analyses that can be performed given a certain model, nor do they provide details on how the analysis should be performed. In this paper, the authors present and test a method based on Design Structure Matrices (DSMs) and classic coupling measures that could be effective in uncovering the hidden structure of an enterprise architecture. The authors perform such a test using data consisting of a total of 407 architecture components and 1,157 dependencies from a biopharmaceutical company (referred to as BioPharma). Findings suggest that this method can reveal new facts about architecture structure on an enterprise level, equal to past results in the initial cases of single software systems such as Linux, Mozilla, Apache, and GnuCash. Key concepts include: For BioPharma, the architectural visualization and computed coupling metrics can provide valuable input when planning architectural change projects (in terms of, for example, risk analysis and resource planning). Analysis shows that business components are Control elements, infrastructure components are Shared elements, and software applications are in the Core, thus providing verification that the architecture is sound. The hidden external structure of the architecture components at BioPharma can be classified as core-periphery with a propagation cost of 23%, architecture flow through of 67%, and core size of 32%. Closed for comment; 0 Comments.
- 22 May 2013
- Working Paper Summaries
Hidden Structure: Using Network Methods to Map System Architecture
All complex systems can be described in terms of their architecture, that is, as a nested hierarchy of subsystems. Despite a wealth of research highlighting the importance of understanding system architecture, however, there is little empirical evidence on the actual architectural patterns observed across large numbers of real world systems. In this paper, the authors developed robust and reliable methods to detect the core components in a complex system, to establish whether these systems possess a core-periphery structure, and to measure important elements of these structures. Overall, the findings represent a first step in establishing some stylized facts about the structure of real-world systems. Key concepts include: The majority of systems analyzed in this non-random sample—67 percent to 76 percent—possess a core-periphery structure. Another 20 percent are considered borderline core-periphery. However, a significant number of systems lack such a structure. This implies a considerable amount of managerial discretion exists when choosing the "best" architecture for a system. There are major differences in the number of core components across a range of systems of similar size and function, indicating that differences in design are not driven solely by system requirements. Instead, these differences appear to be driven, in part, by the characteristics of the organization in which development occurs. Open, distributed organizations tend to develop modular designs with smaller "Cores"; whereas closed, collocated organizations tend to develop tightly-coupled designs with larger Cores. The authors find that core components are often distributed throughout a system, rather than being concentrated in one place. Hence it is important not to assume that all key relationships in a system are located in a few subsystems. These issues are pertinent in software, given that legacy code is rarely re-written, but instead forms a platform upon which new systems are built. The authors find no discernible pattern of direct dependencies between components that can reliably predict the number and location of core components. The results highlight the critical importance of indirect dependencies, which generate multiple paths along which changes and problems can propagate. These findings highlight the difficulties facing a system architect. Closed for comment; 0 Comments.
- 27 Mar 2008
- Working Paper Summaries
Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis
Products are often said to "mirror" the architectures of the organization from which they come. Is there really a link between a product's architecture and the characteristics of the organization behind it? The coauthors of this working paper chose to analyze software products because of a unique opportunity to examine two different organizational modes for development, comparing open-source with proprietary "closed-source" software. The results have important implications for development organizations given the recent trend toward "open" approaches to innovation and the increased use of partnering in research and development projects. Key concepts include: A product's architecture tends to mirror the structure of the organization within which it is developed. New organizational arrangements can have a distinct impact on the nature of the resulting design, and hence may affect product performance in unintended ways. There are substantial differences in relative levels of modularity between software systems of similar size and function. Closed for comment; 0 Comments.
- 24 Jan 2008
- Working Paper Summaries
The Impact of Component Modularity on Design Evolution: Evidence from the Software Industry
What factors should influence the design of a complex system? And what is the impact of choices on both product and organizational performance? These issues are of particular importance in the field of software given how software is developed: Rarely do software projects start from scratch. The authors analyzed the evolution of a commercial software product from first release to its current design, looking specifically at 6 major versions released at varying periods over a 15-year period. These results have important implications for managers, highlighting the impact of design decisions made today on both the evolution and the maintainability of a design in subsequent years. Key concepts include: Data show strong support for the existence of a relationship between component modularity and design evolution. Tightly coupled components have a higher probability of survival as a design evolves compared with loosely coupled components. Tightly coupled components are also harder to augment, in that the mix of new components added in each version is significantly more modular than the legacy design. Closed for comment; 0 Comments.
- 26 Nov 2007
- Research & Ideas
Best Practices of Global Innovators
Corporate R&D labs used to be the key for companies to create competitive advantage. But in the 21st century, innovation is moving out of the lab and across the globe. That's why Harvard Business School professor Alan MacCormack and his research collaborators believe that a real source of competitive advantage is skill in managing innovation partnerships. Key concepts include: Innovation is increasingly driven through collaborative teams due to product complexity, availability of a low-cost but highly skilled labor pool, and advances in development tools. Collaboration adds to the top and bottom lines by shortening development lead times, increasing capacity, and facilitating access to skills, capabilities, and intellectual property that a firm does not possess internally. Many efforts at innovation collaboration fail because they begin with the goal of lowering costs. Successful collaboration programs develop a collaboration strategy that is aligned to their business needs. They also organize for effective collaboration and invest in building collaborative capabilities. Closed for comment; 0 Comments.
- 31 Aug 2007
- Working Paper Summaries
Innovation through Global Collaboration: A New Source of Competitive Advantage
Collaboration is becoming a new and important source of competitive advantage. No longer is the creation and pursuit of new ideas the bastion of large, central R&D departments within vertically integrated organizations. Instead, innovations are increasingly brought to the market by networks of firms, selected according to their comparative advantages, and operating in a coordinated manner. This paper reports on a study of the strategies and practices used by firms that achieve greater success in terms of business value in their collaborative innovation efforts. Key concepts include: Consider the strategic role of collaboration, organize effectively for collaboration, and make long-term investments to develop collaborative capabilities. Successful firms found that attention to these 3 critical areas generated new options to create value that competitors could not replicate. Successful firms went beyond simple wage arbitrage, asking global partners to contribute knowledge and skills to projects, with a focus on improving their top line. They redesigned their organizations to increase the effectiveness of these efforts. Managing collaboration the same way a firm handles the outsourcing of production is a flawed approach. Production and innovation are fundamentally different activities and have different objectives. Closed for comment; 0 Comments.
- 14 Jun 2007
- Working Paper Summaries
Evolution Analysis of Large-Scale Software Systems Using Design Structure Matrices and Design Rule Theory
Designers have long recognized the value of modularity. But because design principles are informal, successful application depends on the designers' intuition and experience. Intuition and experience, however, do not prevent a company such as Microsoft from constantly grappling with unanticipated challenges and delays in bringing software to market. Clearly, designers need a formal theory and models of modularity and software evolution that capture the essence of important but informal design principles and offer ways to describe, predict, and resolve issues. This paper evaluates the applicability of model and theory to real-world, large-scale software designs by studying the evolution of two complex software platforms through the lens of design structure matrices (DSMs) and the design rule theory advanced by Kim Clark and Carliss Baldwin. Key concepts include: Important software modularity principles have remained informal. DSM models reveal a key characteristic of modular architectures: The design rules must be explicitly defined so that otherwise dependent modules can be decoupled. Each independent module can then be replaced with a better version. DSM modeling and the design rule theory of Clark and Baldwin have the potential to formally account for how design rules create options in the form of independent modules and how they enable independent substitution. DSM modeling and design rule theory are general enough to model decisions other than those encoded in source code. Closed for comment; 0 Comments.
- 05 Jul 2006
- Working Paper Summaries
Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code
How does a product's design mirror the organization that develops it, and how does such a dynamic occur? To track the evolution of one design over time, this exploratory study compared software designs developed via different modes of organization-open source versus proprietary development. As it turned out, the architecture of the product developed by a highly distributed team of developers (Linux) was more modular than another product of similar size developed by a co-located team of developers (Mozilla). The study helped reveal potential performance tradeoffs from architectures with different characteristics. Key concepts include: The value of design is a managerial choice. There are important, measurable differences in modularity between different software systems of comparable size and function. Systems may vary dramatically in terms of their robustness to change, and the costs and efficiency of future enhancements. Closed for comment; 0 Comments.
- 14 Feb 2005
- Research & Ideas
The World in Your Palm?
Cell phones are cameras, too. Music players are photo albums, too. PDAs browse the Internet, too. A Cyberposium panel looks at the limits of convergence. Closed for comment; 0 Comments.
- 01 Mar 2004
- Lessons from the Classroom
Mission to Mars: It Really Is Rocket Science
Do the successful Mars missions mean NASA again has the right stuff? Professor Alan MacCormack dissects the space agency’s "Faster, Better, Cheaper" program. Closed for comment; 0 Comments.
- 09 Mar 2003
- Research & Ideas
Education, Technology, and Business: What’s the Catch?
In a panel discussion on current and future business opportunities in the American education market, four entrepreneurs hashed out the pros and cons of entering this tricky sector. There are opportunities—for the daring and undaunted. HBS professor Alan MacCormack moderated this panel at the Conference on Social Enterprise held recently at Harvard Business School. Closed for comment; 0 Comments.
- 02 Dec 2002
- Research & Ideas
The Secret of How Microsoft Stays on Top
Critics say Microsoft's incredible two-decade run at the top of the computer industry has less to do with innovation than it does with bully tactics. But new research from Harvard Business School professors Marco Iansiti and Alan MacCormack suggest a different reason: the company's ability to spot technological trends and exploit key software technologies. Closed for comment; 0 Comments.
- 30 Apr 2001
- Research & Ideas
Why Evolutionary Software Development Works
What is the best way to develop software? HBS professor Alan MacCormack discusses recent research proving the theory that the best approach is evolutionary. In this article from MIT Sloan Management Review, MacCormack and colleagues Marco Iansiti and Roberto Verganti uncover four practices that lead to successful Internet software development. Closed for comment; 0 Comments.
Designing an Agile Software Portfolio Architecture: The Impact of Coupling on Performance
This study deepens our understanding of how firms can better design software portfolio architectures to improve their agility. The authors examined data from over 1,000 different software applications and 3,000 dependencies between them. They found that indirect measures of coupling and dependency have more power in predicting IT agility than direct measures.