Architectures as a Framework for Effective and Efficient Product ...

Department of Systems Engineering and Engineering Management, Stevens Institute of Technology

Architectures as a Framework for Effective and Efficient Product Development in a Dynamic Business Environment Eirik Hole Stevens Institute of Technology Castle Point on the Hudson Hoboken, NJ 07030 [email protected]

Abstract This paper argues for the significant role of product and system level architectures and architectural knowledge for a product or system developing enterprise. The explicit development and use of this knowledge can enable the enterprise to more effectively and efficiently address the accelerating rate of change in business and technology environment that characterize many industry domains today. Aspects of a framework for the explicit development, management and use of system level architectures and architectural knowledge are proposed as a basis for further research.

Introduction Today’s business environment is characterized by rapidly evolving markets and needs, available and emergent technologies as well as business models. This is especially visible in the consumer segment, but just as valid in other commercial sectors as well as in government and defense system domains. Enterprises are being challenged to respond to changing needs, technologies and new capabilities from competitors in ever decreasing development cycles while still maintaining product quality. “Products” are no longer limited to physical packages of © 2005 Stevens Institute of Technology, ISBN 0-615-12843-2 PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

hardware and software. End-to-end capabilities through integration with external systems as well as services through innovative business models and partnerships are becoming an important part of the equation. Technologies are not only evolving rapidly, but are just as rapidly being commoditized. Many authors including (Christensen 2003, Rechtin 2000) point out the inability of companies to “break” out of their legacy architectures as a significant contributor to their failure to address business opportunities and even create new markets. (Henderson and Clark 1990) attribute this partly to their findings that architectural knowledge at the system level is often implicitly embedded in an organization. This is in stark contrast, according to them, to how organizations explicitly handle component-level knowledge. Component level knowledge is captured in numerous artifacts, aided by mature processes, methods and tools, as well as targeted competence development of employees and clear organizational responsibility. In many traditional industries the fundamental structures of products and systems have changed very little over time. Small and incremental architectural changes and upgrades have been sufficient to serve new needs and exploit new technologies. These changes have often been small and introduced in incremental steps over a long period of time. They could therefore relatively

effortlessly be absorbed into the “fabric” of the existing organization and the existing architecture. To have the strategic asset of architectural knowledge of the products and systems an enterprise develops and markets implicitly embedded in the organization has traditionally served an organization well. The products have continuously improved in utility and efficiency by improvement on the component level and small adjustments to the architecture. There has seldom been a real need to fundamentally question the underlying architectural structures and frameworks. Seen in context of a dynamic business and technology environment combined with the observations of Henderson and Clark, this asset of a “given” architecture can also turn into a liability. It may serve as a filter on emerging opportunities – “if all you have is a hammer, everything looks like a nail”. A reasonable hypothesis is therefore that the ability to create and implement new architectures and innovate on an architectural level becomes critical for sustained success. Systems architecting and the management of architectural descriptions turn into key strategic competencies for success in a dynamic environment. The rest of the paper will give a brief overview of the potential impact of system architectures throughout an enterprise. I will also discuss aspects of the possible role system architectures can play as a framework supporting these activities in a more explicit and purposeful manner.

The Impact of System Architectures My literature review has so far revealed that the product development community has had the widest scope researching the impact of product and system architectures on an enterprise. One of the first and most frequently cited papers in the product development literature dealing with the impact of product and system architectures is “The PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

role of product architecture in the manufacturing firm” (Ulrich 1995). Ulrich defines product architecture as: “(1) the arrangement of functional elements; (2) the mapping from functional elements to physical elements; (3) the specification of the interfaces among interacting physical components”. Ulrich’s paper, and many of the following papers in this thread of research, discusses commercial and consumer oriented products and systems with a significant content of hardware and mechanical parts. IEEE Standard 1471 (IEEE 2000) offers a more general definition: “The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” (Morris and Ferguson 1993) go further in the direction of rules and refers to architecture as the “complex of standards and rules”. The inclusion of rules, standards and guiding principles as well as an increased focus on interfaces and communication (Maier 1998) might prove valuable for the future challenges of systems-of-systems and other systems where physical and logical structures are constantly changing and evolving. ((Maier and Rechtin 2000) provides and interesting discussion around the architecture of the Internet to illustrate this point). System Architectures and Marketing The marketing process generally determines what products should be brought to market and how they should be positioned. In the commercial domain, the marketing is probably the main source of “user”requirements and is a driving force in the architecture definition. The influence is also evident in the other direction. The architectural knowledge of an enterprise, often defined by its legacy architectures, will significantly determine what products an enterprise will bring to market. (Sanchez 1999) provides a thorough

discussion on how product architectures both supports and inhibits the marketing process. In particular he discusses the merit of modular architectures to enable a wide product variety based on relatively few modular technologies. On a more general level it is almost selfevident that the architectural knowledge of an enterprise will significantly influence the perceived feasibility of certain products and product features. Sanchez also provides some interesting thoughts around the ability to create new architectures. He says: “In the long term, an organization’s knowledge about how to create new product and process architectures determines the new product and process architectures it can create to bring new kinds of product offers to market”. A further aspect to consider, is the whole product offering (Moore 2002). The characteristics of the system architecture will determine the flexibility an enterprise has to integrate its products with other systems and products. This contributes to the possibilities for innovative partnerships both in product offering as well as distribution and sales channels. System Architectures and R&D R&D is probably the area most frequently associated with system architectures. Architecture and architecting is often associated with the early stages of the system design effort (ANSI/EIA 1999, Hatley, et al. 2000, IEEE 1999). The architecture has several impacts on the development effort. On the softer side, the (perceived) architecture provides the vision of the end product. It also identifies the major elements of the system and their relationships and serves as a template for the system design. The architecture will also be a determining factor in the ease of developing new variants and versions of a product. This is one of the driving forces behind the trend towards

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

platforms and modular architectures (Baldwin and Clark 2000). (Henderson and Clark 1990) identified the frequently close alignment between the main elements of the dominant product architecture and the structure of the R&D organization of an enterprise. (Sosa, et al. 2000) provide a detailed study on the technical communication in development teams and its close mapping to design interfaces. The degree of alignment between the product architecture and the development team will significantly influence the volume and frequency of communication needed between the different teams. There is more to the impact of architectures on the organizational aspects than effective and efficient communication between teams. (Fine 1998) discusses the aspects of competencies and proximity. This becomes increasingly important as the development effort is increasingly sourced out to the extended enterprise. Tasks and teams can therefore not be defined purely based on the logical and physical partitioning of a system or product. R&D competencies and capacities internally and externally have to be considered. So does the spatial and cultural proximity as well as the information system infrastructure. The considerations will therefore increasingly have to include the strategic aspects of core competencies vs. outsourcing. System Architectures and Manufacturing The characteristics of the physical implementation elements (by this I mean both hardware and software elements) will determine the available sourcing options. The implementation technology chosen will determine the manufacturing capabilities needed. The functional allocation and interface definitions will determine the availability of COTS elements vs. tailored manufacturing. The degree of coupling between the elements and the criticality and sensitivity of the interfaces will determine the

integration effort and capabilities needed at various stages in the assembly process. (Fine 1998) proposes supply chain design as the ultimate core competency of an enterprise. He discusses various aspects of the tight coupling between the product architecture and the possible design options for the supply chain. An enterprise that brings products to market that mainly consists of (de facto) industry standard components, such as a personal computer, will have totally different drivers for its product architectures and supply chain design than an enterprise that brings a tightly coupled product, such as an aircraft engine, to market. The first one has a multitude of sourcing options, and its architecture will probably be driven by compliance with de-facto interface standards, cost and inventory considerations. The supply chain will be characterized by what Fine refers to as a horizontal integration, where each player can operate with great independence as long as they conform to the interface standards. The aircraft engine is a case of a vertically integrated supply chain. The system architecture will to a large extent be driven by performance and available technology. Each component of the engine has to be carefully balanced with the other components. A majority of the elements require highly specialized capabilities both in their development, manufacturing and assembly. Close cooperation is needed to ensure product quality and performance. In an empirical study (Novak and Eppinger 2001) identify a general strong correlation between product complexity and the level of vertical integration in the supply chain. System Architectures and After Market Support The need for after market support and the after market support an enterprise chooses to provide will vary significantly according to

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

industry domain and business strategy. It is beyond the scope of this paper to discuss this in detail. I will only highlight a few aspects of the impact the system architecture can have. (Johannesen 2000) lists commonality, standard compliance, modularity, reliability, maintainability, and testability as major architectural attributes that influence the supportability of a system. The first three attributes have similar effects as discussed under horizontal and vertical supply chain integration in the previous section. They will also influence factors such as upgradeability and replacement of obsolescent technologies. Reliability is influenced by the overall system structure and level of redundancy as well as the chosen implementation technology and will determine the general availability of the system as well as the required maintenance intervals. Maintainability is mainly influenced by the physical assembly structure of the system. System Architectures and Business Strategy The discussion above indicates that the architecture of a system or a product impacts virtually all aspects of bringing a product to market. The coupling between the system architecture and the overall business strategy of an enterprise is therefore quite significant. The architectural knowledge of the enterprise influences decisions concerning demand generation for its products through market positioning, product portfolio, sales, distribution and support channels, and strategic and tactical partnerships. It influences internal and external supply chain decisions with regard to both R&D and manufacturing structurally as well as through viable sourcing options given by capability, capacity and technology needs.

Explicit Development, Use and Management of System Architectures Two questions naturally rise based on the broad impact of system architectures discussed above and the observations of (Henderson and Clark 1990). Will an enterprise that explicitly manages and uses its product or system level architectural competence have an advantage in more effectively addressing emerging market and technology opportunities? And further, will it be able to increase the efficiency with which it brings its products to market? Let us first consider some aspects of implicit architectural knowledge as discussed by Henderson and Clark. System architectures are to a large extent given by company and industry legacy. The knowledge of these architectures is practically woven into the fabric of the enterprise. They are reflected in the organizational structure, the formal and informal communication channels between organizational entities, in the information content exchanged over these channels, and in the problem solving strategies for system level problems occurring at the interfaces. As a consequence, any significant change of the system architecture will pose a fundamental threat to the enterprise itself. The economical, cultural and organizational cost and risk of significant changes to these architectures are considered so high that even self-evident needs for change are suppressed. The consequence is that the system architecture is not a variable in the decision-making in the areas discussed above. Instead this architectural knowledge is rather an implicit constraint influencing these decisions. All the impacts of system architectures discussed above are mutually dependent. This means that the system architecture itself can just as well be a dependent variable as an independent variable in the respective decision-making processes. As an example it would seem to make more sense that the

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

business strategy drives the system architectures and not the other way around. The architectural knowledge of the enterprise will of course constrain the viable range of possible architectures and consequently viable business strategies. A prerequisite for rational decision-making is that the architectural knowledge is explicit and can be assessed. In addition benefits can also be expected based on Henderson and Clark’s observations on the explicit management of component knowledge. They observed continuous improvement and innovation on the component level that led to improvement of critical performance parameters and reduction of component cost. They identified clear organizational responsibility, knowledge capture in well-defined artifacts and continuous and targeted development of skills, methods, tools and processes as significant contributing factors. Explicit system level architectural knowledge might therefore enable architectural innovation that more effectively can address changes in the business and technology environment. It may also result in better architectures in general that improves the efficiency in product development, manufacturing and support. Current architecture frameworks, such as (DoD 2003, DotT 2000, TOG 2005, USCIOC 1999, Zachman 1987) are mainly concerned about the description of architectures. This is a fundamental and necessary element of explicit architectural knowledge management, but it is not sufficient. In addition a framework for explicit architectural knowledge management will have to address: • Organizational responsibility for the development and enforcement of system architectures • How system architectures are created: • Processes, methods and tools to synthesize and analyze architectural properties of a system • General rules and guidelines • Inputs used and outputs created

• •

•

Influence of business, organizational, financial, “political” and technological constraints How system architectures are used • Alignment between the system architecture and the development organization • Use of architectural information in the coordination, management and decision making throughout development, manufacturing and support • Alignment between the underlying system architecture and the manufacturing system, the supply chain and the extended enterprise in general • Use of architectural information when seeking and evaluating business opportunities How system architectures are managed and maintained over time • Architectural evolution over product generations and variants • Rationale for keeping or “breaking” the architecture • Configuration Management of architectural descriptions • Alignment of architecture strategy with business and technology strategies

Conclusion This paper has reviewed the potential impact of system architectures and system level architectural knowledge on the demand generation, product creation, supply chain design and after market activities of a product or system developing enterprise. It further argues for the potential benefit of explicit system level architectural knowledge management. This can enable improved short term and long term decision-making, architectural innovation to more effectively

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

address changes in the business and technology environment and better architectures in general to increase the efficiency of product development, manufacturing and support. The aspects of explicit architectural knowledge management that are proposed can serve as a basis for several research topics to create a framework for the development, use and management of system architectures.

References ANSI/EIA, "Processes for Engineering a System," ANSI/EIA, 1999. Baldwin, C.Y. and Clark, K.B., Design Rules Vol 1. The Power of Modularity. Cambridge: The MIT Press, 2000. Christensen, C.M., The Innovator's Dilemma, Business Essentials Edition ed: Harper Collins, 2003. DoD Architecture Framework, vol. Volume 1: Definitions and Guidelines, Version 1 ed. City: Dept. of Defence, 2003. DotT, Treasury Enterprise Architecture Framework. Department of the Treasury, 2000. Fine, C.H., Clockspeed - Winning Industry Control in the Age of Temporary Advantage. New York, NY: Basic Books, 1998. Hatley, D., Hruschka, P., and Pirbhai, I., Process for System Architecture and Requirements Engineering. New York: Dorset House Publishing, 2000. Henderson, R.M. and Clark, K.B., "Architectural Innovation: The Reconfiguration of Existing," Administrative Science Quarterly, vol. 35, pp. 9-30, 1990. The Institute of Electrical and Electronics Engineers, Inc., "IEEE Standard for Application and Management of the Systems Engineering Process," IEEE 1220-1998, The Institute of Electrical and Electronics Engineers, Inc., 1999.

The Institute of Electrical and Electronics Engineers, Inc., "IEEE Recommended practice for architectural description of software-intensive systems," IEEE Std 1471, The Institute of Electrical and Electronics Engineers, Inc., 2000. Johannesen, L.H., Supportability Assessment and Evaluation During System Architecture Formulation and Development, Master Thesis, University of Exeter, 2000. Maier, M.W., "Architecting principles for systems-of-systems," Systems Engineering, vol. 1, pp. 267-284, 1998. Maier, M.W. and Rechtin, E., The art of systems architecting, 2nd. ed. Boca Raton: CRC Press, 2000. Moore, G.A., Crossing the Chasm. New York, NY: HarperBusiness, 2002. Morris, C.R. and Ferguson, C.H., "How architecture wins technology wars," Harvard Business Review, vol. 71, pp. 8696, 1993. Novak, S. and Eppinger, S.D., "Sourcing By Design: Product Complexity and the Supply Chain," Management Science, vol. 41, pp. 189 - 204, 2001. Rechtin, E., Systems architecting of organizations: Why Eagles can't swim. New York, NY: CRC Press, 2000. Sanchez, R., "Modular architectures in the marketing process," Journal of Marketing, vol. 63, pp. 92, 1999. Sosa, M.E., Eppinger, S.D., and Rowles, C.M., "Understanding the Effects of Product Architecture on Technical Communication in Product Development Organizations," Massachustes Institute of Technology; Sloan School of Management, 2000, pp. 35. TOG, TOGAF "Enterprise Edition" Version 8.1, The Open Group, Accessed on: Jan. 6th. 2005, http://www.opengroup.org/architecture/tog af8-doc/arch/

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Ulrich, K., "The role of product architecture in the manufacturing firm," Research Policy, vol. 24, pp. 419, 1995. USCIOC, Federal Enterprise Architecture Framework, v1.1 U.S. Chief Information Officers Council, 1999. Zachman, J.A., "A framework for information systems architecture," IBM Systems Journal, vol. 26, pp. 454 - 470, 1987.

Biography Eirik Hole is currently a PhD Student and a Lecturer in Systems Engineering at Stevens Institute of Technology in New Jersey, USA. He received his Dipl.Ing. degree (~Msc) in Aerospace Engineering from the University of Stuttgart in Germany in 1995. Mr. Hole has 8 years of experience working in various systems engineering related positions. He started his career as a Systems Engineer on a new generation missile system program. He has also worked as a Systems Engineer on other European military programs. Mr. Hole has lately worked as a consultant in the area of applied systems engineering and requirements management as well as on the practical application of SE and RM tools. His consulting experience includes customers from defense as well as the automotive and consumer goods industry in Scandinavia, Central and Southern Europe..