Difference between revisions of "Enterprise Systems Engineering Key Concepts"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(159 intermediate revisions by 13 users not shown)
Line 1: Line 1:
−
The purpose of Traditional [[Systems Engineering (glossary)|Systems Engineering]] [[Acronyms|(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 (glossary)]] “single” [[System (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009).  [[Enterprise Systems Engineering (ESE) (glossary)]] [[Acronyms|ESE]] expands beyond this traditional basis to “consider the full range of SE services increasingly needed in a modern [[Organization (glossary)]] where information-intensive systems are becoming central [[Element (glossary)|elements]] of the organization’s [[Business (glossary)|business]] strategy.” (Carlock and Fenton 2001, 242-261)  The traditional role of Systems Engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[Context (glossary)]] of government [[Acquisition (glossary)]] of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control system).
+
----
 +
'''''Lead Authors:''''' ''James Martin, Bud Lawson, Alan Faisandier''
 +
----
 +
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, {{Term|complex (glossary)}} “single” {{Term|system (glossary)}} (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009).  {{Term|Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering}} (ESE) expands beyond this traditional basis to “consider the full range of SE services increasingly needed in a modern {{Term|organization (glossary)|organization}} where information-intensive systems are becoming central elements of the organization’s {{Term|business (glossary)|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 {{Term|context (glossary)|context}} of government {{Term|acquisition (glossary)|acquisition}} of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control systems).
  
−
ESE encompasses this traditional role in system acquisition, but also incorporates [[Enterprise (glossary)]] 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)
+
ESE encompasses this traditional role in system acquisition, but also incorporates {{Term|enterprise (glossary)|enterprise}} strategic {{Term|Plan (glossary)|plan}}ning and enterprise investment analysis (along with others as described below). 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==
 
==Closing the Gap==
−
The MITRE Corporation has done significant development of ESE practices.
+
ESE practices have undergone significant development recently.
 +
 
 
<BLOCKQUOTE>
 
<BLOCKQUOTE>
−
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).
+
''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)
 
</BLOCKQUOTE>
 
</BLOCKQUOTE>
−
(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 (glossary)]] 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
 
−
*[[Capability (glossary)|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.
+
Rebovich (2006) says there are “new and emerging modes of thought that are increasingly being recognized as essential to successful systems engineering in enterprises.” For example, in addition to the TSE {{Term|Process (glossary)|process}} areas, MITRE has included the following process areas in their ESE process (DeRosa 2005) to close the gap between ESE and PSE:
 +
*strategic technical planning,
 +
*enterprise architecture,
 +
*capabilities-based planning analysis,
 +
*technology planning, and
 +
*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. These business processes are described in the article called [[Related Business Activities]]. The TSE processes are well documented in many sources, especially in the ISO/IEC/IEEE 15288 standard (2015).
 
   
 
   
−
[[File:ESE-F13.png|700px|Enterprise SE Process Areas in the Context of the Entire Enterprise]]
+
[[File:ESE-F13.png|thumb|center|700px|'''Figure 1. Enterprise SE Process Areas in the Context of the Entire Enterprise (DeRosa 2006).''' Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved. All other rights are reserved by the copyright owner.]]
−
 
 
−
Figure 1. Enterprise SE Process Areas in the Context of the Entire Enterprise (Source: (DeRosa 2006), Used with Permission)
 
  
−
SE is viewed by many organizations and depicted in many process definitions as bounded by the beginning and end of a system development [[Project (glossary)]]. 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 (glossary)|life cycle]].” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on [[Operational (glossary)]] purpose. Elliott and Deasley (Elliott and Deasley 2007) discuss the differences between development phase SE and in-service SE.
+
SE is viewed by many organizations and depicted in many process definitions as bounded by the beginning and end of a system development {{Term|Project (glossary)|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 {{Term|Life Cycle (glossary)|life cycle}}.” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on {{Term|operational (glossary)|operational}} purpose. 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 (glossary)]]. Outcome spaces are characterized by a set of desired capabilities that help meet enterprise objectives, as opposed to definitive “user [[Requirement (glossary)|requirements]]” based on near-term needs. Enterprise capabilities must be [[Robustness (glossary)|robust]] enough to handle unknown [[Threat (glossary)|threats]] and situations in the future. A detailed description of previous MITRE views on ESE can be found in (Rebovich and White 2011).
+
In contrast to TSE, the ESE discipline 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 {{Term|portfolio (glossary)|portfolio}}. Outcome spaces are characterized by a set of desired capabilities that help meet enterprise objectives, as opposed to definitive “user {{Term|Requirement (glossary)|requirements}}” based on near-term needs. Enterprise capabilities must be {{Term|Robustness (glossary)|robust}} enough to handle unknown {{Term|Threat (glossary)|threats}} and situations in the future. A detailed description of previous MITRE views on ESE can be found in a work by Rebovich and White (2011).
  
 
==Role of Requirements in ESE==
 
==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).
 
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 (glossary)]] priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:
+
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, {{Term|governance (glossary)|governance}} priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:
 +
 
 
<BLOCKQUOTE>
 
<BLOCKQUOTE>
−
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 (glossary)|complexity]] and non-determinism in an enterprise. ESE must account for the concerns, interests and objectives of these agents (DeRosa 2006).
+
''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 {{Term|Complexity (glossary)|complexity}} and non-determinism in an enterprise. ESE must account for the concerns, interests and objectives of these agents.'' (Swarz, DeRosa, and Rebovich 2006) (See also [[Complexity]])
 
</BLOCKQUOTE>
 
</BLOCKQUOTE>
  
−
==Extensions Beyond Traditional SE==
+
Whereas TSE focuses on output-based methodologies (e.g., functional analysis and object-oriented analysis), ESE is obligated to emphasize outcomes (e.g., business analysis and mission needs analysis), especially those related to the enterprise goals and key mission needs.
−
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.
+
 
 +
==Enterprise Entities and Relationships==
 +
An enterprise “system” has different entities and relationships than you might find in a product/service system (see note 1). These can be usefully grouped into two categories: asset items and conceptual items. An example of an asset is hardware and software. Examples of conceptual items are things like analysis, financial elements, markets, policies, process, and strategy.
 +
 
 +
:<I>Note 1. 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 {{Term|Data Center (glossary)|data center}}, data warehouse, and other such facilities and equipment used across one or more organizations.</I>
 +
 
 +
Products and services are sometimes treated as “assets” as shown in the figure below (Troux 2010). This categorization of enterprise items comes from the semantic model (i.e., metamodel) used in the Troux Architect modeling tool for characterization and analysis of an enterprise architecture. Other enterprise entities of interest are things like information, knowledge, skills, finances, policies, process, strategy, markets, and resources, but these are categorized as "concept" items (in this particular schema). Further details on how to use this metamodel's entities and relationships are provided by Reese (2010).
 +
 
 +
{|
 +
|+'''Table 1. Asset Domain and Concept Domain Categories for Enterprise Entities.''' (Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.
 +
!Asset Domains
 +
!Concept Domains
 +
|-
 +
|Application and Software Domain
 +
Data Domain
 +
Document Domain
 +
Infrastructure and Hardware Domain
 +
IT Product Domain
 +
IT Service Domain
 +
Location Domain
 +
Organization Domain
 +
Product and Service Domain
 +
Services Portfolio Management Domain
 +
|Analysis Domain
 +
Financial Domain
 +
General Domain
 +
Information Domain
 +
IT Architecture Domain
 +
Knowledge and Skill Domain
 +
Market Domain
 +
Policy Domain
 +
Process Domain
 +
Resource Domain
 +
Strategy Domain
 +
Timeline Domain
 +
Transition Domain
 +
|}
 +
 
 +
The application/software and infrastructure/hardware domains are likely the most familiar to systems engineers (as illustrated in the figure below). 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 be 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.
 +
 
 +
[[File:ESE-F15.png|thumb|center|800px|'''Figure 2. Example of Enterprise Entities & Relationships (Troux 2010).''' Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.]]
 +
 
 +
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. The examples give above are from the Troux Semantics metamodel used in the Troux Architect {{Term|Modeling Tool (glossary)|modeling tool}} for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (sometimes called “schemas”). See Reese (2010) for more details on how to use the metamodel shown in the figure above.
 +
 
 +
==Enterprise Architecture Frameworks & Methodologies==
 +
Enterprise architecture frameworks are collections of standardized viewpoints, views, and models that can be used when developing architectural descriptions of the enterprise. These architecture descriptions can be informal, based on simple graphics and tables, or formal, based on more rigorous modeling tools and methods. ISO/IEC 42010 (2011) specifies how to create architecture descriptions.  
  
−
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 (glossary)]] views are emphasized, as well.
+
These frameworks relate to descriptive models of an enterprise, with conventions agreed in particular communities. There are various frameworks and methodologies available that assist in the development of an {{Term|Enterprise Architecture (glossary)|enterprise architecture}}.  
  
−
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.
+
Urbaczewski and Mrdalj (2006) provide an overview and comparison of five prominent architectural frameworks, including:
 +
* the Zachman Framework for Enterprise Architecture (Zachman 1992),
 +
* the Department of Defense Architecture Framework (DoDAF) (DoD 2010),
 +
* the Federal Enterprise Architecture Framework (FEAF) (FEA 2001),  
 +
* the Treasury Enterprise Architecture Framework (TEAF) (US Treasury 2000),
 +
* and The Open Group Architectural Framework (TOGAF) (TOGAF 2009).
  
−
Table 1. Extension of TSE to ESE Process Areas (Source: (Martin 2010), Used with Permission)
+
==References==
  
−
[[File:ESE-TB.png|600px|Extension of TSE to ESE Process Areas]]
+
===Works Cited===
  
−
==Enterprise Entities and Relationships==
+
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Englewood Cliffs, NJ, USA: Prentice-Hall.
−
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.  
+
 
 +
Carlock, P., and R. Fenton. 2001. "System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations." ''Systems Engineering''. 4 (4): 242-261.
 +
 
 +
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)'', version 1.1. Washington, DC, USA: Federal Chief Information Officers Council.
  
−
:<I>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.</I>
+
DeRosa, J.K. 2005. "Enterprise Systems Engineering." Presented at Air Force Association, Industry Day, Day 1, August 4, 2005, Danvers, MA, USA.  
  
−
+
DoD. 2010. ''DoD Architecture Framework (DoDAF)'', version 2.0. Washington, DC: U.S. Department of Defense (DoD).
−
[[File:ESE-F14.png|500px|Asset Domain and Concept Domain Categories for Enterprise Entities]]
 
  
−
Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities (Source: (Troux 2010), Used with Permission)
+
Elliott, C., and P. Deasley. 2007. ''Creating Systems that Work--Principles of Engineering Systems for the 21st Century''. London, England, UK: Royal Academy of Engineering.
  
−
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 (glossary)]], [[Constraint (glossary)|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 (glossary)]] for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (or sometimes called “schemas”).
+
FEA. 2001. "Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001." Available: https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf.
  
−
+
Friedman, G., and A.P. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." ''Systems Engineering''. 7 (1): 84-96.  
−
[[File:ESE-F15.png|800px|Examples of Enterprise Entities & Relationships]]
 
  
−
Figure 3. Examples of Enterprise Entities & Relationships (Source: (Troux 2010), Used with Permission)
+
Hall, A.D. 1989. ''Metasystems Methodology: A New Synthesis and Unification'', 1st ed. Oxford, UK: Pergamon Press.
  
−
==Enterprise Architecture Frameworks & Methodologies==
+
Hitchins, D. 1993. ''Putting Systems to Work''. New York, NY, USA: John Wiley & Sons.  
−
There are various frameworks and methodologies available that assist in the development of an [[Enterprise Architecture (glossary)|enterprise architecture (glossary)]]. Some of these are described below.
 
  
−
===TRAK Framework===
+
ISO/IEC/IEEE. 2015.''Systems and Software Engineering - System Life Cycle Processes.''Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.  
−
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).  
 
  
−
+
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, July 10-15, 2005, Rochester, NY, USA.
−
[[File:ESE-F16.png|700px|TRAK Metamodel]]
 
  
−
Figure 4. TRAK Metamodel (Source: (TRAK 2011), Used with Permission)
+
MITRE. 2004. ''MITRE 2004 Annual Report". McLean, VA, USA: MITRE Corporation. ''
  
−
===DODAF Framework===
+
Rebovich, G. 2006. "Systems Thinking for the Enterprise: New & Emerging Perspectives." Presented at IEEE/SMC International Conference on System of Systems Engineering, April 2006, Los Angeles, CA, USA.  
−
The figure below shows the metamodel for the DOD Architecture framework (ref). There are several good books that explain how to use architecture frameworks and to do architecture modeling. (add references)
 
  
−
+
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.
−
[[File:ESE-F17.png|600px|DODAF Conceptual Data Model]]
 
  
−
Figure 5. DODAF Conceptual Data Model *Source: (DOD 2010), Released)
+
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions''. Birmingham, UK: Packt Publishing Ltd.
  
−
===TOGAF Framework===
+
Sage, A.P., and W.B. Rouse (eds). 2009. ''Handbook of System Engineering and Management'', 2nd ed. New York, NY, USA: John Wiley & Sons.
−
Some frameworks (like 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 FEAF) 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).
 
  
−
+
Swarz, R.S., J.K. DeRosa, and G. Rebovich. 2006. "[[An Enterprise Systems Engineering Model]]." Proceedings of the 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA.
−
[[File:ESE-F18.png|300px|TOGAF Methodology]]
 
  
−
Figure 6. TOGAF Methodology (Source: (TOGAF 2009), Used with Permission)
+
TOGAF. 2009. "The Open Group Architecture Framework," version 9. Accessed September 7, 2011. Available: http://www.opengroup.org/togaf/.
  
−
===Zachman Framework===
+
Troux. 2010. ''Metamodeling and modeling with Troux Semantics'', version 9. Austin, TX, USA: Troux Technologies.
−
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.
 
  
−
+
Urbaczewski, L., and S. Mrdalj. 2006. "A Comparison of Enterprise Architecture Frameworks." ''Issues in Information Systems''. 7 (2): 18-26.
−
[[File:ESE-F19.png|450px|Zachman Framework]]
 
  
−
Figure 7. Zachman Framework (Source: (Zachman 1992), Used with Permission)
+
US Treasury. 2000. ''Treasury Enterprise Architecture Framework,'' version 1. Washington, DC, USA: US Department of the Treasury Chief Information Officer Council.
  
−
==References==
+
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal''. 31 (3): 590-616.
  
−
===Citations===
+
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal''. 26 (3): 276-92.
−
# Blanchard, B. S., and W. J. Fabrycky. 2010. Systems engineering and analysis. Prentice-hall international series in industrial and systems engineering. 5th ed. Englewood Cliffs, NJ, USA: Prentice-Hall.
 
−
# Carlock, Paul and Robert Fenton. 2001. “System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations,” Systems Engineering Journal, Vol 4, No 4, 242-261.
 
−
# DeRosa, J. K. 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings.
 
−
# ———. 2005. “Enterprise Systems Engineering,” Air Force Association, Industry Day, Day 1, Danvers, MA, 4 August 2005, https://www.paulrevereafa.org/IndustryDay/05/presentations/index.asp
 
−
# 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. Vol. (n/a). London, England: 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.
 
−
# Hitchins, D. 1993. Putting systems to work. New York, NY: 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.
 
−
# Sage, A. P., and W. B. Rouse, eds. 2009. Handbook of system engineering and management. 2nd ed. New York, NY: John Wiley & Sons.
 
−
# TOGAF. 2009. The open group architecture framework. Version 9. http://www.opengroup.org/togaf/. Accessed July 2011.
 
−
# TRAK. 2011. TRAK enterprise architecture framework. http://trak.sourceforge.net/index.html. Accessed July 2011.
 
−
# Troux. 2010. Metamodeling and modeling with Troux Semantics. 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.  
 
−
# ———. 1987. A framework for information systems architectures. IBM Systems Journal 26 (3): 276-92.
 
  
 
===Primary References===
 
===Primary References===
−
DeRosa, J. K. 2006. “[[An Enterprise Systems Engineering Model]],” INCOSE Symposium Proceedings.
+
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, July 10-15, 2005, Rochester, NY, USA.  
  
−
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.  
+
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.
  
−
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.
+
Swarz, R.S., J.K. DeRosa, and G. Rebovich. 2006. "[[An Enterprise Systems Engineering Model]]." Proceedings of the 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA.
  
−
Rebovich, G., and B. E. White, eds. 2011. [[Enterprise Systems Engineering: Advances in the Theory and Practice]]. Boca Raton, FL, USA: CRC Press.
+
===Additional References===
  
−
===Additional References===
+
''Journal of Enterprise Architecture''. Available: http://www.globalaea.org/?page=JEAOverview.
−
# 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. Auerbach Publications.
+
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.  
 
  
 +
TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available: http://trak.sourceforge.net/index.html.
  
 +
Vernadat, F.B. 1996. ''Enterprise Modelling and Integration - Principles and Applications''. London, UK: Chapman and Hall.
 
----
 
----
−
====Article Discussion====
+
<center>[[Related Business Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Process Activities|Next Article >]]</center>
−
[[{{TALKPAGENAME}}|[Go to discussion page]]]
+
 
−
<center>[[Related Business Activities|<- Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Process Activities|Next Article ->]]</center>
+
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
  
−
==Signatures==
 
 
[[Category: Part 4]][[Category:Topic]]
 
[[Category: Part 4]][[Category:Topic]]
−
--[[User:Blawson|Blawson]] 20:44, 15 August 2011 (UTC)
+
[[Category:Enterprise Systems Engineering]]

Latest revision as of 21:47, 2 May 2024

Lead Authors: James Martin, Bud Lawson, Alan Faisandier

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, complexcomplex “single” systemsystem (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). Enterprise systems engineeringEnterprise systems engineering (ESE) expands beyond this traditional basis to “consider the full range of SE services increasingly needed in a modern organizationorganization where information-intensive systems are becoming central elements of the organization’s businessbusiness 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 contextcontext of government acquisitionacquisition of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control systems).

ESE encompasses this traditional role in system acquisition, but also incorporates enterpriseenterprise strategic planplanning and enterprise investment analysis (along with others as described below). 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

ESE practices have undergone significant development recently.

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.” For example, in addition to the TSE processprocess areas, MITRE has included the following process areas in their ESE process (DeRosa 2005) to close the gap between ESE and PSE:

  • strategic technical planning,
  • enterprise architecture,
  • capabilities-based planning analysis,
  • technology planning, and
  • 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. These business processes are described in the article called Related Business Activities. The TSE processes are well documented in many sources, especially in the ISO/IEC/IEEE 15288 standard (2015).

Figure 1. Enterprise SE Process Areas in the Context of the Entire Enterprise (DeRosa 2006). Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved. All other rights are reserved by the copyright owner.

SE is viewed by many organizations and depicted in many process definitions as bounded by the beginning and end of a system development projectproject. 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 cyclelife cycle.” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on operationaloperational purpose. Elliott and Deasley (2007) discuss the differences between development phase SE and in-service SE.

In contrast to TSE, the ESE discipline 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 portfolioportfolio. Outcome spaces are characterized by a set of desired capabilities that help meet enterprise objectives, as opposed to definitive “user requirementsrequirements” based on near-term needs. Enterprise capabilities must be robustrobust enough to handle unknown threatsthreats and situations in the future. A detailed description of previous MITRE views on ESE can be found in a work by 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, governancegovernance 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 complexitycomplexity and non-determinism in an enterprise. ESE must account for the concerns, interests and objectives of these agents. (Swarz, DeRosa, and Rebovich 2006) (See also Complexity)

Whereas TSE focuses on output-based methodologies (e.g., functional analysis and object-oriented analysis), ESE is obligated to emphasize outcomes (e.g., business analysis and mission needs analysis), especially those related to the enterprise goals and key mission needs.

Enterprise Entities and Relationships

An enterprise “system” has different entities and relationships than you might find in a product/service system (see note 1). These can be usefully grouped into two categories: asset items and conceptual items. An example of an asset is hardware and software. Examples of conceptual items are things like analysis, financial elements, markets, policies, process, and strategy.

Note 1. 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 centerdata center, data warehouse, and other such facilities and equipment used across one or more organizations.

Products and services are sometimes treated as “assets” as shown in the figure below (Troux 2010). This categorization of enterprise items comes from the semantic model (i.e., metamodel) used in the Troux Architect modeling tool for characterization and analysis of an enterprise architecture. Other enterprise entities of interest are things like information, knowledge, skills, finances, policies, process, strategy, markets, and resources, but these are categorized as "concept" items (in this particular schema). Further details on how to use this metamodel's entities and relationships are provided by Reese (2010).

Table 1. Asset Domain and Concept Domain Categories for Enterprise Entities. (Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.
Asset Domains Concept Domains
Application and Software Domain

Data Domain Document Domain Infrastructure and Hardware Domain IT Product Domain IT Service Domain Location Domain Organization Domain Product and Service Domain Services Portfolio Management Domain

Analysis Domain

Financial Domain General Domain Information Domain IT Architecture Domain Knowledge and Skill Domain Market Domain Policy Domain Process Domain Resource Domain Strategy Domain Timeline Domain Transition Domain

The application/software and infrastructure/hardware domains are likely the most familiar to systems engineers (as illustrated in the figure below). 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 be 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.

Figure 2. Example of Enterprise Entities & Relationships (Troux 2010). Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.

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. The examples give above are from the Troux Semantics metamodel used in the Troux Architect modeling toolmodeling tool for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (sometimes called “schemas”). See Reese (2010) for more details on how to use the metamodel shown in the figure above.

Enterprise Architecture Frameworks & Methodologies

Enterprise architecture frameworks are collections of standardized viewpoints, views, and models that can be used when developing architectural descriptions of the enterprise. These architecture descriptions can be informal, based on simple graphics and tables, or formal, based on more rigorous modeling tools and methods. ISO/IEC 42010 (2011) specifies how to create architecture descriptions.

These frameworks relate to descriptive models of an enterprise, with conventions agreed in particular communities. There are various frameworks and methodologies available that assist in the development of an enterprise architectureenterprise architecture.

Urbaczewski and Mrdalj (2006) provide an overview and comparison of five prominent architectural frameworks, including:

  • the Zachman Framework for Enterprise Architecture (Zachman 1992),
  • the Department of Defense Architecture Framework (DoDAF) (DoD 2010),
  • the Federal Enterprise Architecture Framework (FEAF) (FEA 2001),
  • the Treasury Enterprise Architecture Framework (TEAF) (US Treasury 2000),
  • and The Open Group Architectural Framework (TOGAF) (TOGAF 2009).

References

Works Cited

Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. 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. 4 (4): 242-261.

CIO Council. 1999. Federal Enterprise Architecture Framework (FEAF), version 1.1. Washington, DC, USA: Federal Chief Information Officers Council.

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

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. London, England, UK: Royal Academy of Engineering.

FEA. 2001. "Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001." Available: https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf.

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, 1st ed. Oxford, UK: Pergamon Press.

Hitchins, D. 1993. Putting Systems to Work. New York, NY, USA: John Wiley & Sons.

ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

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, July 10-15, 2005, Rochester, NY, USA.

MITRE. 2004. MITRE 2004 Annual Report". McLean, VA, USA: MITRE Corporation.

Rebovich, G. 2006. "Systems Thinking for the Enterprise: New & Emerging Perspectives." 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.

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

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." Proceedings of the 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA.

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

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

Urbaczewski, L., and S. Mrdalj. 2006. "A Comparison of Enterprise Architecture Frameworks." Issues in Information Systems. 7 (2): 18-26.

US Treasury. 2000. Treasury Enterprise Architecture Framework, version 1. Washington, DC, USA: US Department of the Treasury Chief Information Officer Council.

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, July 10-15, 2005, Rochester, NY, 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." Proceedings of the 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA.

Additional References

Journal of Enterprise Architecture. Available: http://www.globalaea.org/?page=JEAOverview.

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.

TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available: http://trak.sourceforge.net/index.html.

Vernadat, F.B. 1996. Enterprise Modelling and Integration - Principles and Applications. London, UK: Chapman and Hall.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&oldid=71066"