Enterprise Systems Engineering Background

---

Lead Authors: James Martin, Dick Fairley, Bud Lawson, Contributing Author: Alan Faisandier

---

This article provides a common context for the succeeding topics in the knowledge area.

Capabilities in the Enterprise

The enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems or system elements. Since there could possibly be several organizations involved in this enterprise venture, each organization could be responsible for particular systems or perhaps for certain kinds of elements. Each organization brings their own organizational capability with them and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are illustrated below.

Figure 1. Individual Competence Leads to Organizational, System & Operational Capability. (SEBoK Original)

Organizational capabilities are addressed in the article on Systems Engineering Organizational Strategy, and individual competencies are addressed in the article on Enabling Individuals as they relate to the principles, theories, and practices of organizational behavior.

Organizational Capabilities and Competencies

The word "capability" is used in systems engineering (SE) in the sense of “the ability to do something useful under a particular set of conditions.” This article discusses three different kinds of capabilities: organizational capability, system capability, and operational capability. It uses the word “competence” to refer to the ability of people relative to the SE task. Individual competence, (sometimes called "competency"), contributes to, but is not the sole determinant of, organizational capability. This competence is translated to organizational capabilities through the work practices that are adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance enterprise operational capability in response to stakeholder’s concerns about a problem situation.

Enterprise stakeholders are the ultimate arbiters of value for the system to be delivered. Organizational, system, and operational capabilities cannot be designed, improved, and implemented independently. The key to understanding the dependencies between capabilities is through architecture modeling and analysis as part of the activities described in the article called Enterprise Capability Management. “Capability engineering” is an emerging discipline that could enhance the effectiveness of enterprise systems engineering (ESE), which is further discussed in the article on Systems of Systems (SoS).

Organizational Design

The competencies of individuals are important to the overall organizational capability as discussed in the article on Enabling Individuals. The organizational capability is also a function of how the people, teams, projects, and businesses are organized. The organizational design should specify the roles, authorities, responsibilities, and accountabilities (RARA) of the organizational units to ensure the most efficient and effective operations. Effectiveness of enterprise operations is certainly driven by management principles, concepts, and approaches, but it is also largely driven by its leadership principles, concepts, and approaches. These factors are discussed in the article on Systems Engineering Organizational Strategy that discusses how to organize for effective performance of SE.

Organizational structure is tightly tied to creating value for the enterprise’s various stakeholders. Since the enterprise is made up of various elements including people, processes, technologies, and assets, the organizational structure of the people and the allocation of responsibilities for executing portions of the value stream is a “design decision” for the enterprise and hence is a key element of properly performing ESE. Organizational design is increasingly influenced by the portfolio of products and services and the degree of coupling between them. This organizational design will be based on organizational design patterns and their tradeoffs, as discussed in the article on Systems Engineering Organizational Strategy. Browning (2009) discusses one approach for modeling and analysis of an organization.

Operational Capabilities & Operational Services

As you can see in this figure, operational capabilities provide operational services that are enabled by system capabilities. These system capabilities are inherent in the system that is conceived, developed, created and/or operated by an enterprise. ESE concentrates its efforts on maximizing operational value for various stakeholders, some of whom may be interested in the improvement of some problem situation.

ESE, however, addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. This opportunity might involve lowering of operating costs, increasing market share, decreasing deployment risk, reducing time to market, and any number of other enterprise goals. The importance of addressing opportunity potentials should not be underestimated in the execution of ESE practices.

This article focuses on the operational capabilities of an enterprise and the contribution of these capabilities to operational value (as perceived by the stakeholders). Notice that the organization or enterprise can deal with either the system as a whole or with only one (or a few) of its elements. These elements are not necessarily hard items, like hardware and software, but can also include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, beliefs, and so on.

Services vs. Products vs. Enterprises

A service system is a collection of items (or entities) that perform the operations, administration, management and provisioning (OAM&P) of resources that together provide the opportunities to co-create value by both the service provider and the service consumer.

A collection of services is not necessarily a service system. In fact, this collection of services is often merely a product system that is one of the resources being OAM&P'ed by the service system. A product system can be composed of hardware, software, personnel (see note 1), facilities, data, materials, techniques, and even services. Each of these product system elements can be "engineered."

Note 1. Even personnel are engineered in the sense that their roles and responsibilities are specified precisely and trade-offs are made about which functions are performed by these people versus by hardware or software. People are "produced" in the sense that untrained people are trained to perform their allocated system functions, unknowledgeable people are educated to find or create the information they need to do their assigned task, and uninformed people are taught how to get access to the data they need, and how to extract relevant information from that data.

It is important to understand the difference between the services "enabled" by a service system versus the services that are the elements of a service system entity. See the Service Systems Engineering article for more information about services and how they are engineered.

Likewise, a collection of services is not necessarily an enterprise system. An enterprise may be composed of service systems, along with product systems, as well as policies, procedures, properties, knowledge, financial capital, intellectual capital, and so on. An enterprise might even contain sub-enterprises. Enterprise SE must do the engineering not only across the enterprise itself, but may also get involved in the engineering of the service systems and products systems that the enterprise depends on in order to achieve its goals.

Enterprise Components

The above depictions of enterprise-related things do not show the components of an enterprise. The components of an enterprise when it is viewed as a “system” are different than the components of a product or service system (which is the focus of most literature on systems engineering). The figure below shows the typical kinds of components (shown here as “domains”) in an enterprise (Troux 2010) that could be utilized in achieving the desired enterprise operational capability as shown in Figure 1. It is this operational capability that drives ultimate value for the enterprise’s customers and other stakeholders. Further discussion on enterprise components is provided by Reese (2010) and Lawson (2010, chap. 8).

Figure 2. Categories of Enterprise Components (Troux Technologies, 2010). Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.

The application/software and infrastructure/hardware domains (shown above) are likely the most familiar to systems engineers. The application/software domain contains things like the deployed software itself plus applications, modules, servers, patches, functions, and messages. The infrastructure/hardware domain contains things like the hardware itself plus networks and different kinds of hardware like computing hardware, cabinets, and network devices. There might different subtypes of computing hardware like computers, servers, desktops, laptops, and mainframes.

This particular "semantic model" had its origins in the area of information technology (IT) management but has been successfully expanded beyond the IT domain (Martin 2003 and 2005). You can see from this elaboration of these domains that an enterprise architecture "schema" can be quite extensive in the kinds of things it can model. The less technical domains would be things like policy, market, strategy, transition, financial, knowledge and skill, and analysis. In a typical enterprise architecture schema like this there could be over a hundred types of modeling objects grouped into these domains.

Various tools used in modeling the enterprise are described at http://www.enterprise-architecture.info/EA_Tools.htm (IEAD 2011). The TOGAF metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html) used in The Open Group Architecture Framework (TOGAF) is another useful depiction of the various modeling entities involved in modeling the enterprise (TOGAF 2009).

Scope of Enterprise SE

Computer and communications technologies make it easier to integrate activities across the enterprise, but this does not necessarily make the enterprise more effective and efficient. To enable this to happen, one needs to look at the whole enterprise as a system, rather than as a collection of functions connected solely by information systems and shared facilities.

Essential Challenges

Enterprises face strategic challenges that are essential to address in order to ensure that the enterprise will succeed (Rouse 2009):

• Growth: Increasing impact, perhaps in saturated/declining “markets”,
• Value: Enhancing relationships of processes to benefits and costs,
• Focus: Pursuing opportunities and avoiding diversions,
• Change: Competing creatively while maintaining continuity,
• Future: Investing in inherently unpredictable outcomes,
• Knowledge: Transforming information to insights to programs, and
• Time: Carefully allocating the organization’s scarcest resource.

To address these challenges, one recognizes that the central source of value in the enterprise is in its people. “Understanding and supporting the interests of an enterprise’s diverse stakeholders — and finding the ‘sweet spot’ among the many competing interests — is a central aspect of discerning the work of the enterprise as a system and creating mechanisms to enhance this work” (Rouse 2009).

Enterprise Transformation

Enterprises are constantly transforming, whether at the individual level (wherein individuals alter their work practices) or at the enterprise level (large-scale planned strategic changes) (Srinivasan 2010). These changes are a response on the part of the enterprise to evolving opportunities and emerging threats. It is not merely a matter of doing work better, but doing different work, which is often a more important result. Value is created through the execution of business processes. However, not all processes necessarily contribute to overall value (Rouse 2005, 138-150). It is important to focus on process and how they contribute to the overall value stream.

After gaining a good understanding of business processes, the next main concern is how best to deploy and manage the enterprise’s human, financial, and physical assets. The key challenge in transforming an enterprise is, in the midst of all this change, continuing to satisfice key stakeholders (see note 2).

Note 2. “Satisfice” means to decide on and pursue a course of action satisfying the minimum requirements to achieve a goal. For the enterprise as a whole, it is often impossible to completely satisfy all stakeholders given their competing and conflicting concerns and interests. Therefore, the concept of “satisficing” is a very important element in the execution of ESE practices. It has less stringent criteria than the concept of "satisfaction," which is commonly used in product/service systems engineering.

Systems engineers have to respond to an increased recognition of the ‘connectedness’ of products and systems, brought about by a number of trends, for example: the capability of (mainly digital) technology, working across multiple systems, to transform businesses and operational systems; the need to create systems in families to increase product diversity and reuse technology, in order to reduce development and operating costs; and the need to build systems which can be brought together flexibly in operations, even if such co-operation was not foreseen at the time of development.

There has also been an increase in collaborative systems development activities, often spanning national boundaries. This has proceeded alongside a growth in the development of what might be called meta-systems, that is systems comprising parts which would previously have been considered as complex in their own right a generation ago, now conceived of and developed as a whole, and thus requiring fresh approaches, of the adaption of old ones.

Tackling these issues requires an approach that transcends the technical and process domain. ESE needs to address integration at the organizational and value chain level.

Transformation Context

Enterprise transformation occurs in the external context of the economy and markets as shown in the figure below (Rouse 2009). The “market” for the enterprise can be thought of as the context in which the enterprise operates. Of course, in the public sector, the enterprise’s “market” is commonly known as its “constituency.”

Figure 3. Context for Enterprise Transformation (Rouse 2009). Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

The term “intraprise” is used here to denote the many systems internal to the enterprise. This includes "information systems such as... ERP [enterprise resource planning] systems, as well as social and cultural systems. More specifically, work assignments are pursued via work processes and yield work products, incurring costs" (Rouse 2009). The social and cultural aspects of an enterprise are addressed further in the article called Enabling Businesses and Enterprises.

Modeling the Enterprise

Models of the enterprise can serve as the basis for understanding the enterprise in its context of markets and economies. The figure below shows the various drivers (or inputs) of an enterprise and its potential outcomes (or outputs) (Rouse 2009). Enterprise architecture can be a key enabler for modeling and can serve as a basis for transformation (Vernadat 1996; Bernus, Laszlo, and Schmidt 2003; Nightingale and Rhodes 2004). Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010) (See also Representing Systems with Models). For a good review of the subject see Lillehagen and Krogstie (2008).

Figure 4. Drivers and Outcomes for the Enterprise (Rouse 2009). Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

In Pursuit of Value

Based on his theory of enterprise transformation, Rouse (2005, 279-295) has identified four alternative perspectives that tend to drive the need for transformation:

1. Value Opportunities: The lure of greater success via market and/or technology opportunities prompts transformation initiatives.
2. Value Threats: The danger of anticipated failure due to market and/or technology threats prompts transformation initiatives.
3. Value Competition: Other players’ transformation initiatives prompt recognition that transformation is necessary to continued success.
4. Value Crises: Steadily declining market performance, cash flow problems, etc., prompt recognition that transformation is necessary for the enterprise to survive.

Work processes can be enhanced, streamlined, eliminated, and invented to help in the pursuit of enhanced value. These process changes should be aligned with enterprise strategy to maximize value produced by the enterprise (Hammer and Champy 1993). As shown below, there are many entities involved in helping the enterprise create value for society, participating organizations, and other stakeholders.

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

References

Works Cited

Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations," in Handbook of Systems Engineering and Management, 2nd ed., edited by A.P. Sage and W.B. Rouse. New York, NY: Wiley and Sons, Inc.

Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.

Hammer, M., and J. Champy. 1993. Reengineering the Corporation: A Manifesto for Business Revolution. New York, NY: Harper Business, HarperCollins Publishers.

IEAD. 2011. "Enterprise Architecture Tools." Institute for Enterprise Architecture Developments. Accessed September 12, 2012. Available: http://www.enterprise-architecture.info/EA_Tools.htm.

Lawson, H. 2010. A Journey Through the Systems Landscape. Kings College, UK: College Publications.

Lillehagen, F., and J. Krogstie. 2008. "Chapter 4: State of the Art of Enterprise Modelling," in Active Knowledge Management of Enterprises. New York, NY, USA: Springer.

Martin, J.N. 2003. "On the Use of Knowledge Modeling Tools and Techniques to Characterize the NOAA Observing System Architecture." Presented at 13th Annual International Council on Systems Engineering (INCOSE) International Symposium, 2003, Arlington, VA, USA.

Martin, J.N. 2005. "Using an Enterprise Architecture to Assess the Societal Benefits of Earth Science Research." Presented at 15th Annual International Council on Systems Engineering (INCOSE) International Symposium, 2005, Rochester, NY, USA.

Miller, J., and S. Page. 2007. Complex Adaptive Systems: An Introduction to Computational Models of Social Life. Princeton, NJ, USA: Princeton University Press.

Reese, R.J. 2010. Troux Enterprise Architecture Solutions. Birmingham, UK: Packt Publishing Ltd.

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

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: Wiley and Sons, Inc.

Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria.

TOGAF 2009. "The Open Group Architecture Framework," version 9. The Open Architecture Group. Accessed September 2, 2011. Available: http://www.opengroup.org/togaf.

Troux. 2010. Metamodeling and modeling with Troux Semantics, version 9. Austin, TX, USA: Troux Technologies.

White, B.E. 2009. "Complex Adaptive Systems Engineering (CASE)." Presented at IEEE Systems Conference, March 23-26, 2009, Vancouver, Canada.

Primary References

Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.

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: Wiley and Sons, Inc.

Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria.

White, B.E. 2009. "Complex Adaptive Systems Engineering (CASE)." Presented at IEEE Systems Conference, March 23-26, 2009, Vancouver, Canada.

Additional References

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.

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.

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.

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, USA: 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, April 9-12, 2007, Honolulu, HI, USA.

---

< Previous Article | Parent Article | Next Article > SEBoK v. 2.5, released 15 October 2021