The Enterprise as a System
Lead Authors: James Martin, Bud Lawson, Judith Dahmann
To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a system,” rather than as a collection of functions connected solely by information systems and shared facilities (Rouse 2005 and 2009; Lawson 2010). What distinguishes the design of enterprise systems from product systems is the inclusion of people as a component of the system, not merely as a user/operator of the system.
The term 'enterprise system' has taken on a narrow meaning of only the information system an organization uses. Research and project experience has taught us that to design a good enterprise system, we need to adopt a much broader understanding of enterprise systems. The greater view of enterprise systems is inclusive of the processes the system supports, the people who work in the system, and the information [and knowledge] content of the system. (Giachetti 2010)
It is worth noting that the concept of "service" systems also includes people in the system. The thoughts above do not take this into account, primarily since their perspectives come mainly from a product system experience. The practice of service systems engineering is relatively new and is an emerging discipline. For more information on this, see the articles on Service Systems Engineering.
Creating Value
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process. These elements in the enterprise can be treated as a "system" and the processes, methods, and tools ESE can be applied.
There are three types of organizations of interest: businesses, projects, and teams (see note 1). A typical business participates in multiple enterprises through its portfolio of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.
- Note 1. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.
Resource Optimization
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its stakeholders. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called Systems Engineering Organizational Strategy.
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called Enterprise Capability Management.
Enabling Systems Engineering in the Organization
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE capability can make a substantial contribution at the enterprise level, as well as at the project level. The article called Systems Engineering Organizational Strategy discusses enabling SE in the organization, while the article called Enabling Businesses and Enterprises focuses on the cross-organizational functions at the business and enterprise levels. The competence of individuals is discussed in the article called Enabling Individuals.
Kinds of Knowledge Used by the Enterprise
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.
Projects, Programs, and Businesses
The term “program” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms project and program are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items (services, products, facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.
The Office of Government Commerce provides a useful distinction between programs and projects:
The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...
A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters. (OGC 2010)
Enabling the Enterprise
ESE, by virtue of its inherent trans-disciplinarity (Sage 2000, 158-169) in dealing with problems that are large in scale and scope, can better enable the enterprise to become more effective and efficient. The complex nature of many enterprise problems and situations usually goes beyond the abilities of standard tools and techniques provided to business school graduates (See also Complexity). ESE can augment the standard business management methods using the tools and methods from the SE discipline to more robustly analyze and evaluate the enterprise as a holistic system. A more general viewpoint, or “view,” for dealing with the enterprise consisting of scale, granularity, mindset, and time frame is provided by White (2007) and by McCarter and White (2009, 71-105).
ESE can provide the enablers to address the concerns of enterprise executives as shown in Table 1 (Rouse 2009). The methods for dealing with, and the special characteristics of, complex adaptive systems must be properly considered when adapting traditional systems engineering (TSE) practices for use at the enterprise level—many of which come out of the systems science and systems thinking domains (von Bertalanffy 1968; Weinberg and Weinberg 1988; Miller and Page 2007; Rouse 2008, 17-25). For an approach to complex adaptive systems (CAS) engineering, refer to White (2009, 1-16) and to McCarter and White (2009, 71-105).
| Executive Concerns | SE Enablers |
|---|---|
| Identifying ends, means, and scope and candidate changes | System complexity analysis to compare "as is" and "to be" enterprises |
| Evaluating changes in terms of process behaviors and performance | Organizational simulation of process flows and relationships |
| Assessing economics in terms of investments, operating costs, and returns | Economic modeling in terms of cash flows, volatility, and options |
| Defining the new enterprise in terms of processes and their integration | Enterprise architecting in terms of workflow, processes, and levels of maturity |
| Designing a strategy to change the culture for selected changes | Organizational and cultural change via leadership, vision, strategy, and incentives |
| Developing transformation action plans in terms of what, when, and who | Implementation planning in terms of tasks, schedule, people, and information |
Enterprise Engineering
Another distinction is that “enterprise design does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly being designed” (Giachetti 2010) [emphasis in original]. Giachetti calls this new discipline “enterprise engineering.” We consider the enterprise engineering set of practices to be equivalent to what we call enterprise systems engineering (ESE) in this article.
The body of knowledge for enterprise engineering is evolving under such titles as enterprise engineering, business engineering, and enterprise architecture . . . . Many systems and software engineering principles are applicable to enterprise engineering, but enterprise engineering’s unique complexities require additional principles…. Enterprise engineering’s intent is to deliver a targeted level of enterprise performance in terms of shareholder value or customer satisfaction . . . . Enterprise engineering methods include modeling; simulation; total quality management; change management; and bottleneck, cost, workflow, and value-added analysis. (Joannou 2007)
Supersystem Constructs
System of Systems (SoS)
The phrase "system of systems” (SoS) is commonly used, but there is no widespread agreement on its exact meaning, nor on how it can be distinguished from a conventional system. A system is generally understood to be a collection of elements that interact in such a manner that it exhibits behavior that the elements themselves cannot exhibit. Each element (or component) of the system can be regarded as a system in its own right. Therefore, the phrase “system of systems” can technically be used for any system and, as such, would be a superfluous term. However, the meaning of this phrase has been examined in detail by (Maier 1998, 267-284), and his definition has been adopted by some people (AFSAB 2005). Maier provides this definition:
A SoS is an assemblage of components which individually may be regarded as systems, and which possess two additional properties:
- Operational Independence of the Components: If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own; and
- Managerial Independence of the Components: The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems. (Maier 1998, 267-284)
Maier goes on further saying that “the commonly cited characteristics of systems-of-systems (complexity of the component systems and geographic distribution) are not the appropriate taxonomic classifiers” (Maier 1998, 267-284). Four kinds of SoS have been defined (Dahmann, Lane, and Rebovich 2008).
For further details on SoS, see the Systems Engineering Guide for SoS developed by the US Department of Defense (DoD) (DUS(AT) 2008). Also, see the Systems of Systems (SoS) knowledge area.
Federation of Systems (FoS)
Different from the SoS concept, but related to it in several ways, is the concept called “federation of systems” (FoS). This concept might apply when there is a very limited amount of centralized control and authority (Sage and Cuppan 2001, 325-345; Sage and Rouse 2009). Each system in an FoS is very strongly in control of its own destiny, but “chooses” to participate in the FoS for its own good and the good of the “country,” so to speak. It is a coalition of the willing. An FoS is generally characterized by significant autonomy, heterogeneity, and geographic distribution or dispersion (Krygiel 1999). Krygiel defined a taxonomy of systems showing the relationships among conventional systems, SoSs, and FOSs.
This taxonomy has three dimensions: autonomy, heterogeneity, and dispersion. A FoS would have a larger value on each of these three dimensions than a non-federated SoS. An “Enterprise System,” as described above, could be considered to be an FoS if it rates highly on these three dimensions. However, it is possible for an enterprise to have components that are not highly autonomous, that are relatively homogeneous, and are geographically close together. Therefore, it would be incorrect to say that an enterprise is necessarily the same as an FoS.
Dove points out that in order for a large enterprise to survive in the twenty-first century, it must be more agile and robust (Dove 1999 and 2001). Handy (1992, 59-67) describes a federalist approach called “New Federalism” which identifies the need for structuring of loosely coupled organizations to help them adapt to the rapid changes inherent in the Information Age. This leads to the need for virtual organizations where alliances can be quickly formed to handle the challenges of newly identified threats and a rapidly changing marketplace (Handy 1995, 2-8). Handy sets out to define a number of federalist political principles that could be applicable to an FoS. Handy’s principles have been tailored to the domain of systems engineering (SE) and management by Sage and Cuppan (2001, 325-345):
- Subsidiarity,
- Interdependence,
- Uniform and standardized way of doing business,
- Separation of powers,
- Dual citizenship, and
- Scales of SE.
Scales of SE
According to Maier’s definition, not every enterprise would be called a SoS since the systems within the enterprise do not usually meet the criteria of operational and managerial independence. In fact, one of the key purposes of an enterprise is to explicitly establish operational dependence between systems that the enterprise owns and/or operates in order to maximize the efficiency and effectiveness of the enterprise as a whole. Therefore, it is more proper to treat an enterprise system and an SoS as different types of things, with different properties and characteristics. This distinction is illustrated in the figure below, where three corresponding categories of SE are shown (DeRosa 2005; Swarz et al. 2006).
It is true that an enterprise can be treated as a system itself and is comprised of many systems within the enterprise, but this discussion will reserve the term SoS to those systems that meet the criteria of operational and managerial independence. This distinction was also used within the MITRE Corporation in their ESE Office (Rebovich and White 2011).
Relationships between Enterprise and SoS
An enterprise may require a particular operational capability that is brought into being by connecting together a chain of systems that together achieve that capability. Any one of these systems in the chain cannot by itself provide this capability. The desired capability is the emergent property of this chain of systems. This chain of systems is sometimes called an SoS. However, the enterprise that requires this capability rarely has direct control over all the systems necessary to provide this full capability. This situation is illustrated in the figure below (Martin 2010).
Enterprise E1 (in the example above) has full control over SoS2, but not full control over SoS1. TSE can be applied to the individual systems (S1, S2, …, S53) shown within each enterprise, but needs to be augmented with additional activities to handle SoS and enterprise kinds of issues.
There is a general issue regarding dealing with enterprises in this situation: there are at least two enterprises related to any particular SoS. First, there is the enterprise of builders/developers comprising projects and programs, which have to be organized appropriately and adopt special types of architectural principles. Second, there is the enterprise of users (those who use the products and service provided by the first enterprise), which has to exercise its own sort of agility. How the first enterprise designs systems to allow the second to operate is the core issue.
References
Works Cited
AFSAB. 2005. Report on System-of-Systems Engineering for Air Force Capability Development. Washington, DC: US Air Force Scientific Advisory Board (AFSAB), US Air Force. SAB-TR-05-04.
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." CROSSTALK: The Journal of Defense Software Engineering. 21 (11): 4–9.
DeRosa, J.K. 2005. "Enterprise Systems Engineering." Presented at Air Force Association, Industry Day, Day 1, August 4, 2005, Danvers, MA, USA.
Dove, R. 2001. Response Ability: The Language, Structure, and Culture of the Agile Organization. New York, NY, USA: John Wiley & Sons.
Dove, R. 1999. "Knowledge Management, Response Ability, and the Agile Enterprise," in Paradigm Shift International [database online]. Accessed September 6, 2011. Available: http://www.parshift.com/docs/KmRaAeX.htm.
DUS(AT). 2008. Systems Engineering Guide for Systems of Systems, version 1.0. Washington, DC, USA: Deputy Under Secretary of Defense for Acquisition and Technology (DUS(AT)) / US Department of Defense (DoD). Accessed September 6, 2011. Available: http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf.
Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.
Handy, C. 1995. "Trust and the Virtual Organization." Harvard Business Review. 73 (3): 2-8.
Handy, C. 1992. "Balancing Corporate Power: A New Federalist Paper." Harvard Business Review. 70 (6): 59-67.
Joannou, P. 2007. "Enterprise, Systems, and Software—The Need for Integration." Computer. 40 (5): 103-105.
Krygiel, A.J. 1999. Behind the Wizard's Curtain: An Integration Environment for a System of Systems. Arlington, VA, USA: C4ISR Cooperative Research Program (CCRP).
Lawson, H. 2010. A Journey Through the Systems Landscape. Kings College, UK: College Publications.
Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE). 1 (4): 267-84.
Martin, J.N. 2010. "An Enterprise Systems Engineering Framework." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 2010, Chicago, IL, USA.
McCarter, B.G., and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects," in Systems of systems engineering: Principles and applications, edited by M. Jamshidi. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group. p. 71-105.
OGC (Office of Government Commerce). 2010. Guidelines for Managing Programmes: Understanding programmes and programme management. London, UK: The Stationery Office.
Ross, J.W., P. Weill, and D. Robertson. 2006. Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Boston, MA, USA: Harvard Business Review Press.
Rouse, W.B. 2009. "Engineering the Enterprise as a System," in Handbook of systems engineering and management, 2nd ed., edited by A.P. Sage and W.B. Rouse. New York, NY, USA: Wiley and Sons, Inc.
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." The Bridge, National Academy of Engineering. 38 (1): 17-25.
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." Systems Engineering. 8 (2): 138-50.
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." in Transdiciplinarity: Recreating Integrated Knowledge, edited by M.A. Somerville and D. Rappaport. Oxford, UK: EOLSS Publishers. p. 158-169.
Sage, A., and C. Cuppan. 2001. "On the Systems Engineering and Management of Systems of Systems and Federations of Systems." Information-Knowledge-Systems Management Journal. 2 (4): 325-345.
Sage, A.P., and W.B. Rouse (eds). 2009. Handbook of System Engineering and Management, 2nd ed. New York, NY, USA: John Wiley & Sons.
Swarz, R.S., J.K. DeRosa, and G. Rebovich. 2006. "An Enterprise Systems Engineering Model." Proceedings of the INCOSE International Symposium, July 9-13, 2006, Orlando, FL, USA.
von Bertalanffy, L. 1968. General System Theory: Foundations, Development, Applications, revised ed. New York, NY, USA: Braziller.
Weinberg, G., and D. Weinberg. 1988. General Principles of Systems Design. New York, NY: Dorset House Publishing Company.
White, B.E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA.
Primary References
Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.
Joannou, P. 2007. "Enterprise, Systems, and Software—The Need for Integration." Computer. 40 (5): 103-105.
Rouse, W.B. 2009. "Engineering the Enterprise as a System," in Handbook of systems engineering and management, 2nd ed., edited by A.P. Sage and W.B. Rouse. New York, NY, USA: Wiley and Sons, Inc.
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." Systems Engineering. 8 (2): 138-50.
Additional References
Arnold, S., and H. Lawson. 2004. "Viewing Systems From a Business Management Perspective." Systems Engineering. 7 (3): 229.
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." Systems Engineering. 4 (2): 118-33.
Nightingale, D., and D. Rhodes. 2004. "Enterprise systems architecting: Emerging art and science within engineering systems." Presented at Engineering Systems Symposium, Massachusetts Institute of Technology (MIT), 29-31 March, 2004, Boston, MA, USA.
Rebovich, G. 2006. "Systems Thinking for the Enterprise: New & Emerging Perspectives." Presented at IEEE/SMC International Conference on System of Systems Engineering, April 2006, Los Angeles, CA, USA.
Rechtin, E. 1999. Systems Architecting of Organizations: Why Eagles can't Swim. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.
Ring, J. 2004. "Intelligent Enterprises." INCOSE INSIGHT. 6 (2).
Ring, J. 2004. "Seeing an Enterprise as a System." INCOSE INSIGHT. 6(2).
Valerdi, R., D. Nightingale, and C. Blackburn. 2009. "Enterprises as Systems: Context, Boundaries, and Practical Implications." Information-Knowledge-Systems Management Journal. 7 (4): 377-399.