The Enterprise as a System
- 1 Introduction
- 2 Enabling the Enterprise
- 3 Enterprise Engineering
- 4 Supersystem Constructs
- 5 Relationships between Enterprise and SoS
- 6 References
- 7 SEBoK Discussion
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.
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 (CASE), refer to White (2009, 1-16) and to McCarter and White (2009, 71-105).
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)
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 and management by Sage and Cuppan (2001, 325-345):
- Uniform and standardized way of doing business
- Separation of powers
- Dual citizenship
- Scales of SE
Scales of SE
According to Maier’s definition, an enterprise would not necessarily 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 and 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.
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.
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." International Journal of Operations & Production Management 1 (17).
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.
Rother, M. 2009. "Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results." New York, NY, USA: McGraw-Hill.
Rother, M. and J. Shook. 1999. "Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA." Cambridge, MA, USA: Lean Enterprise Institute.
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.
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.
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.
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.
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