Enterprise Systems Engineering Key Concepts
The purpose of Traditional Systems Engineering (TSE) is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, complex “single” system (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). enterprise systems engineering (ese) (ESE) expands beyond this traditional basis to “consider the full range of SE services increasingly needed in a modern organization where information-intensive systems are becoming central elements of the organization’s business strategy.” (Carlock and Fenton 2001, 242-261) The traditional role of Systems Engineering (SE) is heavily involved in system acquisition and implementation, especially in the context of government acquisition of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control system).
ESE encompasses this traditional role in system acquisition, but also incorporates enterprise strategic planning and enterprise investment analysis. These two additional roles for SE at the enterprise level are “shared with the organization’s senior line management, and tend to be more entrepreneurial, business-driven, and economic in nature in comparison to the more technical nature of classical systems engineering.” (Carlock and Fenton 2001, 242-261)
Closing the Gap
The MITRE Corporation has done significant development of ESE practices.
Today the watchword is enterprise systems engineering, reflecting a growing recognition that an “enterprise” may comprise many organizations from different parts of government, from the private and public sectors, and, in some cases, from other nations. (MITRE 2004)
(Rebovich 2006) says there are “new and emerging modes of thought that are increasingly being recognized as essential to successful systems engineering in enterprises.” In addition to the TSE process areas, MITRE has included the following process areas in their ESE process (DeRosa 2005) to close the gap between ESE and product SE:
- Strategic Technical Planning
- Enterprise Architecture
- Capabilities-Based Planning Analysis
- Technology Planning
- Enterprise Analysis and Assessment
These ESE processes are shown in the context of the entire enterprise in the figure below (DeRosa 2006). The ESE processes are shown in the middle with business processes on the left and TSE processes on the right.
SE is viewed by many organizations and depicted in many process definitions as bounded by the beginning and end of a system development project . In MITRE this restricted definition was referred to as TSE. Many have taken a wider view seeking to apply SE to the “whole system” and “whole life cycle.” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on operational purpose. Elliott and Deasley (Elliott and Deasley 2007) discuss the differences between development phase SE and in-service SE.
In contrast to TSE, ESE is more like a “regimen” (Kuras and White 2005) that is responsible for identifying “outcome spaces,” shaping the development environment, coupling development to operations, and rewarding results rather than perceived promises (DeRosa 2005). ESE must continually characterize the operational environmental and the results of enterprise or SoS interventions to stimulate further actions within and among various systems in the enterprise portfolio . Outcome spaces are characterized by a set of desired capabilities that help meet enterprise objectives, as opposed to definitive “user requirements” based on near-term needs. Enterprise capabilities must be robust enough to handle unknown threats and situations in the future. A detailed description of previous MITRE views on ESE can be found in (Rebovich and White 2011).
Role of Requirements in ESE
TSE typically translates user needs into system requirements that drive the design of the system elements. The system requirements must be “frozen” long enough for the system components to be designed, developed, tested, built, and delivered to the end users (which can sometimes take years, and in the case of very large, complicated systems like spacecraft and fighter jets, more than a decade).
ESE, on the other hand, must account for the fact that the enterprise must be driven not by requirements (that rarely can even be defined, let alone made stable) but instead by continually changing organizational visions, goals, governance priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:
Ackoff has characterized an enterprise as a “purposeful system” composed of agents who choose both their goals and the means for accomplishing those goals. The variety of people, organizations, and their strategies is what creates the inherent complexity and non-determinism in an enterprise. ESE must account for the concerns, interests and objectives of these agents. (Swarz et al. 2006) (See also Complexity)
Extensions Beyond Traditional SE
These considerations were taken into account when extending the process areas for ESE. The acquisition-oriented SE concept areas in the Friedman-Sage framework (Friedman and Sage 2004, 84-96) were extended to cover the strategic and investment-oriented ESE activities described above. Four new process areas were added to the list as shown in the table below. Additions or changes are shown in italics.
To emphasize the fact that an enterprise is dealing with many systems within its portfolio of systems, the word “enterprise” is used in the first two process areas dealing with requirements and architecture . Portfolio and program views are emphasized, as well.
The word “program” is used to replace “system” since the programs are the system “elements” of the enterprise when you treat the Enterprise as a system. Projects are like “subsystems” of these programs. It is really the life cycle of the programs that is supported by enterprise management, while the Programs themselves are responsible for managing and supporting the life cycles of their particular systems. The word “portfolio” is used to emphasize the collections of Programs within the enterprise that must also be managed as a group.
Enterprise Entities and Relationships
An enterprise “system” has different entities and relationships than you might find in a product/service system (see note 5). Products and services are usually treated as “assets” as shown in the figure below (Troux 2010). Other enterprise entities of interest are things like information, knowledge, skills, finances, policies, process, strategy, markets, and resources.
Note 5. An “enterprise system” should not be confused with the enterprise “perceived as a system.” An enterprise system is a product (or service) system used across the enterprise, such as payroll, financial accounting, or enterprise resource planning applications, and consolidated data center, data warehouse, and other such facilities and equipment used across one or more organizations.
The figure below shows examples of entities for applications, software, infrastructure and hardware in the asset domains of an enterprise along with typical entities for the analysis domain such as risk , constraints, findings, recommendations, factors, and trends. Also shown here are the relevant relationships between such entities. This is from the Troux Semantics metamodel used in the Troux Architect modeling tool for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (or sometimes called “schemas”).
Enterprise Architecture Frameworks & Methodologies
There are various frameworks and methodologies available that assist in the development of an enterprise architecture . Some of these are described below.
TRAK Framework
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011).
DODAF Framework
The figure below shows the metamodel for the United States Department of Defense (DoD) Architecture framework (DoD 2010).
TOGAF Framework
Some frameworks (like The Open Group Architecture Framework (TOGAF)) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).
Zachman Framework
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “stakeholder concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, networks, people, time, and motivation. The rows represent the different stakeholder “perspectives”: contextual (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: scope (i.e., contextual), business model, system model, technology model, and detailed representations.
References
Works Cited
Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
Carlock, P. and R. Fenton. 2001. “System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations,” Systems Engineering Journal 4 (4): 242-261.
CIO Council 1999. "Federal Enterprise Architecture Framework (FEAF), Version 1.1" Washington, DC, USA: Federal Chief Information Officers Council. http://www.cio.gov/documents_details.cfm/uid/1F432311-2170-9AD7-F2053C10765E0E1C/structure/Enterprise%20Architecture/category/Enterprise%20Architecture Accessed on September 7, 2011.
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.
DoD. 2010. DoD Architecture Framework (DoDAF), version 2.0. Washington, DC: U.S. Department of Defense (DoD).
Elliott, C. and P. Deasley. 2007. "Creating Systems that Work--Principles of Engineering Systems for the 21st Century." (17). London, England, UK: Royal Academy of Engineering.
Friedman, G. and A.P. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." Systems Engineering 7 (1): 84-96.
Hall, A.D. 1989. "Metasystems Methodology: A New Synthesis and Unification." International series on systems science and engineering. 1st ed. Vol. 3. Oxford, UK: Pergamon Press.
Hitchins, D. 1993. "Putting Systems to Work." New York, NY, USA: John Wiley & Sons.
Kuras, M.L. and B. E. White. 2005. "Engineering Enterprises using Complex-Systems Engineering." Annotated presentation at 15th Annual International Council on Systems Engineering (INCOSE) International Symposium, 10-15 July, 2005, Rochester, NY, USA.
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.
MITRE. 2004. "MITRE 2004 Annual Report." McLean, VA, USA: MITRE Corporation.
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.
Rebovich, G. and B.E. White, eds. 2011. "Enterprise systems engineering: Advances in the theory and practice." Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.
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.
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf/ Accessed September 7, 2011.
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.
Troux. 2010. "Metamodeling and Modeling with Troux Semantics." Austin, TX, USA: Troux Technologies. Version 9, July 2010.
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." IBM Systems Journal 31 (3): 590-616.
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." IBM Systems Journal 26 (3): 276-92.
Primary References
Kuras, M.L., and B.E. White. 2005. "Engineering Enterprises Using Complex-Systems Engineering." Annotated presentation at 15th Annual International Council on Systems Engineering (INCOSE) International Symposium, 10-15 July, 2005, Rochester, NY, USA.
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.
Rebovich, G., and B.E. White, eds. 2011. "Enterprise Systems Engineering: Advances in the Theory and Practice." Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model.” INCOSE Symposium Proceedings.
Additional References
Gøtze, J, ed. Journal of Enterprise Architecture. https://www.aogea.org/journal.
Minoli, D. 2008. Enterprise Architecture A to Z: Frameworks, Business Process Modeling, SOA, and Infrastructure Technology. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group, An Auerbach Book.
Vernadat, F. B. 1996. "Enterprise Modelling and Integration - Principles and Applications." London, UK: Chapman and Hall.
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 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