Enterprise Systems Engineering Background

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 (Figure Developed for BKCASE)

Organizational capabilities are addressed in the article on Systems Engineering Organizational Strategy, and individual competencies are addressed in the article on Enabling Individuals to Perform Systems Engineering 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 to Perform Systems Engineering. 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. This organizational design will be based on organizational design patterns and their tradeoffs, as discussed in the article on Systems Engineering Organizational Strategy.

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 4), facilities, data, materials, techniques, and even services. Each of these product system elements can be "engineered."

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

So, 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 list below shows the typical kinds of components (shown here as “domains”) in an enterprise (Reese 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 Lawson (2010, chap. 8).

1. Analysis Domain
2. Application and Software Domain
3. Data Domain
4. Document Domain
5. Financial Domain
6. General Domain
7. Information Domain
8. Infrastructure and Hardware Domain
9. IT Architecture Domain
10. IT Pattern Domain
11. IT Product Domain
12. IT Service Domain
13. Knowledge and Skill Domain
14. Location Domain
15. Market Domain
16. Organization Domain
17. Policy Domain
18. Process Domain
19. Product and Service Domain
20. Resource Domain
21. Services Portfolio Management Domain
22. Strategy Domain
23. Systems Domain
24. Transition Domain
25. Troux Archetype Domain

The application/software and infrastructure/hardware domains 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. 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 over a hundred types of modeling objects grouped into these domains.

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 (Rouse 2009) that are essential to address in order to ensure that the enterprise will succeed:

• 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
• 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 it contributes 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 1).

Note 1. “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.

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 2. Context for Enterprise Transformation (Rouse 2009) Reprinted with permission of John Wiley & Sons Inc.

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 to Perform Systems Engineering.

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 don’t) (Giachetti 2010) (See also Representing Systems with Models).

Figure 3. Drivers and Outcomes for the Enterprise (Rouse 2009) Reprinted with permission of John Wiley & Sons Inc.

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:

• Value Opportunities: The lure of greater success via market and/or technology opportunities prompts transformation initiatives.
• Value Threats: The danger of anticipated failure due to market and/or technology threats prompts transformation initiatives.
• Value Competition: Other players’ transformation initiatives prompt recognition that transformation is necessary to continued success.
• 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).

References

Works Cited

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.

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

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

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

Reese, Richard 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-50.

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. 2009. "Engineering the Enterprise as a System." In eds. A. P. Sage, W. B. Rouse. 2nd ed. "Handbook of systems engineering and management." New York, NY: Wiley and Sons, Inc.

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.

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

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.

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

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 eds. A. P. Sage, W. B. Rouse. 2nd ed. "Handbook of systems engineering and management." New York, NY: Wiley and Sons, Inc.

Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Paper 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)." IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.

Additional References

None.

---

< Previous Article | Parent Article | Next Article >

Comments from SEBok 0.5 Wiki

No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.

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