The Enterprise as a System

Introduction

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 4). 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 4. 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.

Figure 1. Organizations Manage Resources to Create Enterprise Value. (SEBoK Original)

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 & 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 transdisciplinarity (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).

Table 1. Executive Concerns and SE Enablers (Rouse 2009). Reprinted with permission of John Wiley & Sons Inc.

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 system-of-systems 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.
• 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 article called Systems of Systems (SoS).

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. An 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
• 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).

Figure 2. Different Groupings and Patterns Revealed at Different Scales (DeRosa 2005). Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved.

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).

Figure 3. Relationships Between an Enterprise and SoSs (Martin 2010). Reprinted with permission of The Aerospace Corporation.

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: U.S. Air Force Scientific Advisory Board (AFSAB), U.S. 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. November 2008.

DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.

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]. Questa, NM, USA. Available from http://www.parshift.com/docs/KmRaAeX.htm Accessed September 6, 2011.

DUS(AT). 2008. "Systems Engineering Guide for Systems of Systems, Version 1.0." Washington, D.C.: Deputy Under Secretary of Defense for Acquisition and Technology (DUS(AT))/U.S. Department of Defense (DoD) http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed September 6, 2011.

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 (May-June): 2-8.

Handy, C. 1992. "Balancing Corporate Power: A New Federalist Paper." Harvard Business Review 70 (6) (November/December): 59-67.

Joannou, P. 2007. "Enterprise, Systems, and Software — the Need for Integration." Computer, IEEE, May 2007.

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." Paper presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA.

McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. "Systems of systems engineering: Principles and applications." Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 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 A. P. Sage, W. B. Rouse. eds. "Handbook of systems engineering and management." 2nd ed. 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) (Spring 2008): 17-25.

Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation. Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 8 (2): 138-50.

Sage, A. P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In eds. M. A. Somerville, D. Rappaport "Transdiciplinarity: Recreating Integrated Knowledge." 158-169. Oxford, UK: EOLSS Publishers.

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) (December 2001): 325-45.

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,” INCOSE Symposium Proceedings.

von Bertalanffy, L. 1968. "General System Theory: Foundations, Development, Applications." Revised ed. New York, NY: 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." Paper 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, IEEE, May 2007.

Rouse, W. B. 2009. "Engineering the Enterprise as a System." In A. P. Sage, W. B. Rouse. eds. "Handbook of systems engineering and management." 2nd ed. New York, NY, USA: Wiley and Sons, Inc.

Rouse, W.B.. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 8 (2): 138-50.

Additional References

Arnold, S., and H. Lawson. 2004. "Viewing Systems From a Business Management Perspective." Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 4 (2): 118-33.

Nightingale, D., and D. Rhodes. 2004. "Enterprise systems architecting: Emerging art and science within engineering systems." Paper 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." Paper 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." INSIGHT, A Publication of the International Council on Systems Engineering (INCOSE) 6 (2) (January 2004).

Ring, J. 2004. "Seeing an Enterprise as a System." INSIGHT, A Publication of the International Council on Systems Engineering (INCOSE) 6 (2) (January 2004).

Valerdi, R., D. Nightingale, and C. Blackburn. 2009. "Enterprises as Systems: Context, Boundaries, and Practical Implications." Information-Knowledge-Systems Management Journal 7 (4) (December 2008): 377-99.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus