Difference between revisions of "Enterprise Systems Engineering Process Activities"
(Byline) |
|||
| (46 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
| + | ---- | ||
| + | '''''Lead Authors:''''' ''James Martin, Bud Lawson, Alan Faisandier'' | ||
| + | ---- | ||
| + | The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise. | ||
==Systems Engineering Role in Transforming the Enterprise== | ==Systems Engineering Role in Transforming the Enterprise== | ||
===Enabling Systematic Enterprise Change=== | ===Enabling Systematic Enterprise Change=== | ||
| − | The | + | The {{Term|Systems Engineering (glossary)|systems engineering}} (SE) process as applied to the {{Term|enterprise (glossary)|enterprise}} as a whole could be used as the “means for producing change in the enterprise … [where the] … Seven Levels of change in an {{Term|Organization (glossary)|organization}} [are defined] as {{Term|Effectiveness (glossary)|effectiveness}}, efficiency, improving, cutting, copying, differentiating and achieving the impossible” (McCaughin and DeRosa 2006). The essential nature of {{Term|Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering}} (ESE) is that it “determines the balance between {{Term|Complexity (glossary)|complexity}} and order and in turn the balance between effectiveness and efficiency. When viewed as the fundamental mechanism for change, it goes beyond efficiency and drives adaptation of the enterprise” (McCaughin and DeRosa 2006). McCaughin and DeRosa (2006) provide a reasonably good definition for an enterprise that captures this notion of balance: |
<BLOCKQUOTE> | <BLOCKQUOTE> | ||
| − | ''Enterprise: People, processes and technology interacting with other people, processes and technology, serving some combination of their own objectives, those of their individual organizations and those of the enterprise as a whole.'' | + | ''Enterprise: People, processes and technology interacting with other people, processes and technology, serving some combination of their own objectives, those of their individual organizations and those of the enterprise as a whole.'' </BLOCKQUOTE> |
| − | ===Balancing Effectiveness | + | ===Balancing Effectiveness versus Efficiency=== |
Ackoff tells us that: | Ackoff tells us that: | ||
| − | + | <BLOCKQUOTE> | |
| − | Data, information, knowledge and understanding enable us to increase efficiency, not effectiveness. The | + | ''Data, information, knowledge and understanding enable us to increase efficiency, not effectiveness. The {{Term|Value (glossary)|value}} of the objective pursued is not relevant in determining efficiency, but it is relevant in determining effectiveness. Effectiveness is evaluated efficiency. It is efficiency multiplied by value. '''Intelligence''' is the '''ability to increase efficiency'''; '''wisdom''' is the '''ability to increase effectiveness'''.'' |
| + | </BLOCKQUOTE> | ||
| − | The difference between efficiency and effectiveness is reflected in the difference between development and growth. Growth does not require an increase in value; development does. Therefore, development requires an increase in '''wisdom as well as understanding, knowledge and information'''.'' ((Ackoff 1989, 3-9), emphasis added) | + | <BLOCKQUOTE> |
| + | ''The difference between efficiency and effectiveness is reflected in the difference between development and growth. Growth does not require an increase in value; development does. Therefore, development requires an increase in '''wisdom as well as understanding, knowledge and information'''.'' ((Ackoff 1989, 3-9), emphasis added) | ||
</BLOCKQUOTE> | </BLOCKQUOTE> | ||
| Line 20: | Line 26: | ||
Value stream analysis is one way of treating the enterprise as a system. It provides insights regarding where in the sequence of enterprise activities value is added as it moves towards the final delivery to customer or user (Rother and Shook 1999). It relates each step to the costs entailed in that step in terms of resource consumption (i.e., money, time, energy, and materials). In addition to direct costs, there may also be indirect costs due to overhead factors or infrastructure elements. This activity commonly involves drawing a flowchart of the value stream for the enterprise as illustrated in the figure below. | Value stream analysis is one way of treating the enterprise as a system. It provides insights regarding where in the sequence of enterprise activities value is added as it moves towards the final delivery to customer or user (Rother and Shook 1999). It relates each step to the costs entailed in that step in terms of resource consumption (i.e., money, time, energy, and materials). In addition to direct costs, there may also be indirect costs due to overhead factors or infrastructure elements. This activity commonly involves drawing a flowchart of the value stream for the enterprise as illustrated in the figure below. | ||
| − | [[File:ESE-F06.png|thumb|center|600px|Figure 1. Value Stream Example (Source: http://en.wikipedia.org/wiki/Value_stream_mapping Accessed September 6, 2010. US EPA Lean and Environment Toolkit, Public Domain)]] | + | [[File:ESE-F06.png|thumb|center|600px|'''Figure 1. Value Stream Example.''' (Source: http://en.wikipedia.org/wiki/Value_stream_mapping Accessed September 6, 2010. US EPA Lean and Environment Toolkit, Public Domain.)]] |
| − | Analysis of this value stream diagram can highlight unnecessary space, excessive distance traveled, processing inefficiencies, and so on. Value stream mapping is associated with so-called “ | + | Analysis of this value stream diagram can highlight unnecessary space, excessive distance traveled, processing inefficiencies, and so on. Value stream mapping is associated with so-called “{{Term|Lean Systems Engineering (LSE) (glossary)|lean}} enterprise” initiatives. At Toyota, where the technique originated, it is known as “material and information mapping” (Rother 2009). Various value stream mapping tools are available (Hines and Rich 1997). |
==Enterprise Management Process Areas== | ==Enterprise Management Process Areas== | ||
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities: | Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities: | ||
| − | + | #Strategic technical planning, | |
| − | + | #Capability-based planning analysis, | |
| − | + | #Technology and standards planning, and | |
| − | + | #Enterprise evaluation and assessment. | |
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity. | The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity. | ||
| − | [[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|Figure 2. Enterprise Systems Engineering Process Activities ( | + | [[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]] |
===Strategic Technical Planning=== | ===Strategic Technical Planning=== | ||
| − | The purpose of | + | The purpose of strategic technical planning (STP) is to establish the overall technical strategy for the enterprise. It creates the balance between the adoption of standards (see also [[Systems Engineering Standards]]) and the use of new technologies, along with consideration of the people aspects driven by the relevant trans-disciplinary technical principles and practices from psychology, sociology, organizational change management, etc. |
| − | This process uses the roadmaps developed during | + | This process uses the roadmaps developed during technology and standards planning (TSP). It then maps these technologies and standards against the {{Term|Capability (glossary)|capabilities}} roadmap to determine potential alignment and synergy. Furthermore, lack of alignment and synergy is identified as a {{Term|Risk (glossary)|risk}} to avoid or an {{Term|Opportunity (glossary)|opportunity}} to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and {{Term|Project (glossary)|projects}}. |
| − | One reason that STP and TSP are separate processes is that they are often done by different groups in the enterprise and they involve different skill sets. TSP is often done by the technology and science groups. TSP is done closer to (if not in) the chief architect and budget planning groups. Sometimes the great technology proposed by TSP just doesn’t line up with the capabilities needed in the requisite | + | One reason that STP and TSP are separate processes is that they are often done by different groups in the enterprise and they involve different skill sets. TSP is often done by the technology and science groups. TSP is done closer to (if not in) the chief architect and budget planning groups. Sometimes the great technology proposed by TSP just doesn’t line up with the capabilities needed in the requisite time frame. STP does this balancing between technology push and capability pull. |
===Capability-Based Planning Analysis=== | ===Capability-Based Planning Analysis=== | ||
| − | The purpose of ''Capability-based Planning Analysis'' is to translate the enterprise vision and goals into a set of current and future capabilities that helps achieve those goals. Current | + | The purpose of ''Capability-based Planning Analysis'' is to translate the enterprise vision and goals into a set of current and future capabilities that helps achieve those goals. Current {{Term|Mission (glossary)|missions}} are analyzed to determine their suitability in supporting the enterprise goals. Potential future missions are examined to determine how they can help achieve the vision. Current and projected capabilities are assessed to identify capability gaps that prevent the vision and technical strategy from being achieved. These capability gaps are then used to assess program, project, and system {{Term|Opportunity (glossary)|opportunities}} that should be pursued by the enterprise. This is defined in terms of success criteria of what the enterprise is desired to achieve. |
| − | There are different types of capabilities, as shown in the figure below. It is common practice to describe capabilities in the form of capability hierarchies and capability roadmaps. Technology roadmaps (discussed below under Technology Planning) are usually related to the system capabilities while | + | There are different types of capabilities, as shown in the figure below. It is common practice to describe capabilities in the form of capability hierarchies and capability roadmaps. Technology roadmaps (discussed below under Technology Planning) are usually related to the system capabilities while business capability roadmaps (BCRMs) are related to the {{Term|operational (glossary)|operational}} capabilities of the enterprise as a whole (ref: Business-Capability Mapping: Staying Ahead of the Joneses, http://msdn.microsoft.com/en-us/library/bb402954.aspx). The BCRM development is usually done as part of enterprise strategic planning, which is one level higher than, and a key driver for, the strategic technical planning activity described above. |
| − | In some domains there may be | + | In some domains there may be {{Term|competency (glossary)|competency}} roadmaps dealing with the organizational capabilities, with perhaps the desired competency levels of individuals mapped out in terms of the jobs or roles used in the enterprise or perhaps in terms of the knowledge and skills required for certain activities. (For more information on systems engineering competency, see the [[Enabling Individuals]] article.) |
| − | [[File:ESE-F02.png|thumb|center|800px|Figure 3. Organizational, System & Operational Capabilities ( | + | [[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]] |
===Technology and Standards Planning=== | ===Technology and Standards Planning=== | ||
The purpose of ''Technology Planning'' is to characterize technology trends in the commercial marketplace and the research community. This activity covers not just trend identification and analysis, but also technology development and transition of technology into programs and projects. It identifies current, and predicts future, technology readiness levels for the key technologies of interest. Using this information, it defines technology roadmaps. This activity helps establish the technical strategy and implementation guidance in the strategic technical plan. The business capabilities roadmap (BCRM) from the strategic planning activity is used to identify which technologies can contribute to achieved targeted levels of performance improvements. | The purpose of ''Technology Planning'' is to characterize technology trends in the commercial marketplace and the research community. This activity covers not just trend identification and analysis, but also technology development and transition of technology into programs and projects. It identifies current, and predicts future, technology readiness levels for the key technologies of interest. Using this information, it defines technology roadmaps. This activity helps establish the technical strategy and implementation guidance in the strategic technical plan. The business capabilities roadmap (BCRM) from the strategic planning activity is used to identify which technologies can contribute to achieved targeted levels of performance improvements. | ||
| − | The purpose of ''Standards Planning'' is to assess technical standards to determine how they inhibit or enhance the incorporation of new technologies into systems development projects. The future of key standards is forecast to determine where they are headed and the alignment of these new standards with the | + | The purpose of ''Standards Planning'' is to assess technical standards to determine how they inhibit or enhance the incorporation of new technologies into systems development projects. The future of key standards is forecast to determine where they are headed and the alignment of these new standards with the {{Term|Life Cycle (glossary)|life cycles}} for the systems in the enterprise’s current and projected future {{Term|Portfolio (glossary)|portfolios}}. The needs for new or updated standards are defined and resources are identified that can address these needs. Standardization activities that can support development of new or updated standards are identified (See also [[Systems Engineering Standards]]). |
===Enterprise Evaluation and Assessment=== | ===Enterprise Evaluation and Assessment=== | ||
| − | The purpose of | + | The purpose of enterprise evaluation and assessment (EE&A) is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions. |
| − | This process establishes a | + | This process establishes a {{Term|measurement (glossary)|measurement}} program as the means for collecting data for use in the evaluation and assessment of the enterprise. These {{Term|Measure (glossary)|measures}} help determine whether the strategy and its implementation are working as intended. Measures are projected into the future as the basis for determining discrepancies between what is observed and what had been predicted to occur. This process helps to identify risks and opportunities, diagnose problems, and prescribe appropriate actions. Sensitivity analysis is performed to determine the degree of {{Term|robustness (glossary)|robustness}} and {{Term|agility (glossary)|agility}} of the enterprise. |
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area: | Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area: | ||
| + | <BLOCKQUOTE>''must de-emphasize the utility of comparing detailed {{Term|Metric (glossary)|metrics}} against specific individual {{Term|Requirement (glossary)|requirement}} {{Term|Value (glossary)|values}}, whether the metrics are derived from measurement, {{Term|Simulation (glossary)|simulation}} or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled.''</BLOCKQUOTE> | ||
| + | Key characteristics of this activity are the following: | ||
<BLOCKQUOTE> | <BLOCKQUOTE> | ||
| − | + | *Multi-scale analysis, | |
| − | *Multi-scale analysis | + | *Early and continuous operational involvement, |
| − | *Early and continuous operational involvement | + | *Lightweight command and control (C2) capability representations, |
| − | *Lightweight command and control | + | *Developmental versions available for assessment, |
| − | *Developmental versions available for assessment | + | *Minimal infrastructure, |
| − | *Minimal infrastructure | + | *Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and |
| − | *Flexible modeling and simulation | + | *In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE> |
| − | *In-line, continuous performance monitoring and selective forensics. | ||
| − | (Roberts 2006)</BLOCKQUOTE> | ||
| − | + | {{Term|Enterprise Architecture (glossary)|Enterprise architecture}} (EA) can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a {{Term|model (glossary)|model}} to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The {{Term|structure (glossary)|structure}} and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process presented by Martin (2005), the architecture should be driven by the “business questions” to be addressed by the architecture). | |
| − | The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the elements that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency | + | The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the elements that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency (NOAA) EA shown by Martin (2003a and 2003b). The measures are shown, in this example, as success factors, key performance indicators, and information needs in the business strategy layer of the {{Term|Architecture (glossary)|architecture}}. |
EA can be viewed as either the set of artifacts developed as “views” of the enterprise, or as a set of activities that create, use, and maintain these artifacts. The literature uses these terms in both senses and it is not always clear in each case which sense is intended. | EA can be viewed as either the set of artifacts developed as “views” of the enterprise, or as a set of activities that create, use, and maintain these artifacts. The literature uses these terms in both senses and it is not always clear in each case which sense is intended. | ||
| Line 83: | Line 89: | ||
The management activities dealing with opportunities (as opposed to just risk) are included in ESE. According to White (2006), the “greatest enterprise risk may be in not pursuing enterprise opportunities.” Hillson believes there is: | The management activities dealing with opportunities (as opposed to just risk) are included in ESE. According to White (2006), the “greatest enterprise risk may be in not pursuing enterprise opportunities.” Hillson believes there is: | ||
<BLOCKQUOTE> | <BLOCKQUOTE> | ||
| − | ''a systemic weakness in | + | ''a systemic weakness in {{Term|Risk Management (glossary)|risk management}} as undertaken on most {{Term|Project (glossary)|projects}}. The standard risk process is limited to dealing only with uncertainties that might have negative impact ({{Term|Threat (glossary)|threats}}). This means that risk management as currently practiced is failing to address around half of the potential uncertainties—the ones with positive impact (opportunities).'' (Hillson 2004) |
</BLOCKQUOTE> | </BLOCKQUOTE> | ||
| − | White claims that “in systems engineering at an enterprise scale the focus should be on opportunity, and that enterprise risk should be viewed more as something that threatens the pursuit of enterprise opportunities” (White 2006). The figure below (Rebovich and White 2011, chapter 5) shows the relative importance of opportunity and risk at the different scales of an individual system, a system of systems | + | White claims that “in systems engineering at an enterprise scale the focus should be on opportunity, and that enterprise risk should be viewed more as something that threatens the pursuit of enterprise opportunities” (White 2006). The figure below (Rebovich and White 2011, chapter 5) shows the relative importance of opportunity and risk at the different scales of an individual system, a system of systems (SoS), and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management. |
| − | [[File:ESE-F21.png|thumb|center|500px| | + | [[File:ESE-F21.png|thumb|center|500px|'''Figure 4. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (White 2006).''' MITRE Approved for Public Release; Distribution Unlimited. Unique Tracking #05-1262.]] |
===Enterprise Architecture and Requirements=== | ===Enterprise Architecture and Requirements=== | ||
| − | EA goes above and beyond the technical components of | + | EA goes above and beyond the technical components of {{Term|product (glossary)|product}} systems to include additional items such as strategic goals and objectives, operators and {{Term|User (glossary)|users}}, organizations and other {{Term|Stakeholder (glossary)|stakeholders}}, funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer (CIO), and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Nemes, and Schmidt 2003). |
| − | Architecture descriptions following the guidelines of an architecture framework have been used to standardize the views and models used in architecting efforts (Zachman 1987 and 1992; Spewak 1992). Architecture descriptions have also been developed using a business-question based approach (Martin 2003b; Martin 2006). The standard on Architecture Description Practices (ISO/IEC 42010 2011) has expanded its scope to include requirements on architecture frameworks. | + | Architecture descriptions following the guidelines of an architecture framework have been used to standardize the views and models used in architecting efforts (Zachman 1987 and 1992; Spewak 1992). Architecture descriptions have also been developed using a business-question based approach (Martin 2003b; Martin 2006). The standard on Architecture Description Practices (ISO/IEC 42010) (ISO/IEC 2011) has expanded its scope to include requirements on architecture frameworks. |
| − | Government agencies have been increasingly turning to SE to solve some of their agency-level (i.e., enterprise) problems. This has sometimes led to the use of an architecture-based investment process, especially for information technology procurements. This approach imposes a requirement for linking business strategies to the development of EAs. The Federal Enterprise Architecture Framework | + | Government agencies have been increasingly turning to SE to solve some of their agency-level (i.e., enterprise) problems. This has sometimes led to the use of an architecture-based investment process, especially for information technology procurements. This approach imposes a requirement for linking business strategies to the development of EAs. The Federal Enterprise Architecture Framework (FEAF) (CIO Council 1999) and the DoD Architecture Framework (DoDAF) (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 2000; ISO/IEC 1998; NATO 2004; TOGAF 2009; MOD 2010; TRAK 2010). |
==ESE Process Elements== | ==ESE Process Elements== | ||
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows: | As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows: | ||
| − | #Strategic Technical Planning | + | #Strategic Technical Planning, |
| − | #Capability-Based Planning Analysis | + | #Capability-Based Planning Analysis, |
| − | #Technology and Standards Planning | + | #Technology and Standards Planning, |
| − | #Enterprise Evaluation and Assessment | + | #Enterprise Evaluation and Assessment, |
| − | #Opportunity and Risk Assessment and Management | + | #Opportunity and Risk Assessment and Management, |
| − | #Enterprise Architecture and Conceptual Design | + | #Enterprise Architecture and Conceptual Design, |
| − | #Enterprise Requirements Definition and Management | + | #Enterprise Requirements Definition and Management, |
| − | #Program and Project Detailed Design and Implementation | + | #Program and Project Detailed Design and Implementation, |
| − | #Program Integration and Interfaces | + | #Program Integration and Interfaces, |
| − | #Program Validation and Verification | + | #Program Validation and Verification, |
| − | #Portfolio and Program Deployment and Post Deployment | + | #Portfolio and Program Deployment and Post Deployment, and |
| − | #Portfolio and Program Life Cycle Support | + | #Portfolio and Program Life Cycle Support. |
The first seven of these elements were described in some detail above. The others are more self-evident and are not discussed in this article. | The first seven of these elements were described in some detail above. The others are more self-evident and are not discussed in this article. | ||
| − | + | ||
==References== | ==References== | ||
===Works Cited=== | ===Works Cited=== | ||
| − | Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis | + | Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis''. 16 (1): 3-9. |
| − | Bernus, P., L. Nemes, and G. Schmidt | + | Bernus, P., L. Nemes, and G. Schmidt (eds.). 2003. ''Handbook on Enterprise Architecture''. Berlin and Heidelberg, Germany: Springer-Verlag. |
| − | CIO Council. 1999. | + | CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF), Version 1.1''. Washington, DC, USA: Federal Chief Information Officers Council. |
| − | DoD. 2010. | + | DoD. 2010. ''DoD architecture framework (DoDAF)'', version 2.0. Washington, DC: US Department of Defense (DoD). |
| − | Giachetti, R.E. 2010. '' | + | Giachetti, R.E. 2010. ''[[Design of Enterprise Systems: Theory, Architecture, and Methods]]''. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group. |
| − | Hillson, D. 2004. '' | + | Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk''. Petersfield, Hampshire, UK; New York, NY, USA: Rick Doctor & Partners; Marcel Dekker, Inc. |
| − | Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management | + | Hines, P., and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management''. 1 (17): 46-64. |
| − | ISO | + | ISO. 2000. ISO 15704:2000, ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO). |
| − | ISO/IEC | + | ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and software engineering - Architecture description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010. |
| − | ISO/IEC | + | ISO/IEC. 1998. ISO/IEC 10746:1998, ''Information Technology — Open Distributed Processing — Reference Model: Architecture.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). |
| − | Martin, J.N. | + | Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 2010, Chicago, IL, USA. |
| − | Martin, J.N. | + | Martin, J.N. 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." PhD dissertation. Fairfax, VA, USA: George Mason University. |
| − | Martin, J.N. | + | 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. |
| − | Martin, J.N. | + | Martin, J.N. 2003a. "An Integrated Tool Suite for the NOAA Observing System Architecture." Presented at 13th Annual International Council on Systems Engineering (INCOSE) International Symposium, 2003, Arlington, VA, USA. |
| − | Martin, J.N. | + | Martin, J.N. 2003b. "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. |
| − | McCaughin, K., and J.K. DeRosa. 2006. "Process in Enterprise Systems Engineering." | + | McCaughin, K., and J.K. DeRosa. 2006. "Process in Enterprise Systems Engineering." Presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA. |
| − | MOD. 2010. | + | MOD. 2010. ''Ministry of Defence Architecture Framework (MODAF)'', version 1.2.004. London, England, UK: UK Ministry of Defence. Accessed September 8, 2011. Available: http://www.mod.uk/NR/rdonlyres/04B5FB3F-8BBC-4A39-96D8-AFA05E500E4A/0/20100602MODAFDownload12004.pdf. |
| − | NATO. 2010. | + | NATO. 2010. ''NATO Architecture Framework (NAF)'', version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. |
| − | Rebovich, G., and B.E. White | + | Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]]''. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group, Auerbach. |
| − | Roberts, J.L. 2006. "Enterprise Analysis and Assessment." | + | Roberts, J.L. 2006. "Enterprise Analysis and Assessment." Presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA. |
| − | Rother, M. 2009. '' | + | Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results''. New York, NY, USA: McGraw-Hill. |
| − | Rother, M. and J. Shook. 1999. | + | Rother, M., and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA''. Cambridge, MA, USA: Lean Enterprise Institute. |
| − | Spewak, S.H. 1992. '' | + | Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology''. New York, NY, USA: Wiley and Sons, Inc. |
| − | TOGAF. 2009. "The Open Group Architecture Framework | + | TOGAF. 2009. "The Open Group Architecture Framework," version 9. Accessed September 2, 2011. Available: http://www.opengroup.org/togaf. |
| − | TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html | + | TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available: http://trak.sourceforge.net/index.html. |
| − | White, B.E. 2006. "Enterprise Opportunity and Risk." | + | White, B.E. 2006. "Enterprise Opportunity and Risk." Presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2010, Orlando, FL, USA. |
| − | Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal | + | 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 | + | Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal''. 26 (3): 276-292. |
===Primary References=== | ===Primary References=== | ||
| − | Giachetti, R.E. 2010. '' | + | Giachetti, R.E. 2010. ''[[Design of Enterprise Systems: Theory, Architecture, and Methods]]''. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group. |
| − | Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." | + | Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 2010, Chicago, IL, USA. |
| − | Rebovich, G., and B.E. White | + | Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]]''. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group, Auerbach. |
===Additional References=== | ===Additional References=== | ||
| − | DeRosa, J.K. 2005. | + | DeRosa, J.K. 2005. "Enterprise Systems Engineering." Presented at Air Force Association, Industry Day, Day 1, August 4, 2005, Danvers, MA, USA. |
| + | |||
| + | Holt, J., and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage, England, UK: Institution of Engineering and Technology (IET). | ||
| + | |||
| + | Kaplan, R., and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action''. Cambridge, MA, USA: Harvard Business School Press. | ||
| − | + | McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture''. New York, NY, USA: Prentice Hall. | |
| − | + | Swarz, R.S., J.K. DeRosa, and G. Rebovich. 2006. "An Enterprise Systems Engineering Model." INCOSE Symposium Proceedings, July 9-13, 2006, Orlando, FL, USA. | |
| − | |||
---- | ---- | ||
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center> | <center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center> | ||
| − | + | <center>'''SEBoK v. 2.1, released 31 October 2019'''</center> | |
| − | |||
[[Category: Part 4]][[Category:Topic]] | [[Category: Part 4]][[Category:Topic]] | ||
[[Category:Enterprise Systems Engineering]] | [[Category:Enterprise Systems Engineering]] | ||
| − | |||
Revision as of 03:04, 26 October 2019
Lead Authors: James Martin, Bud Lawson, Alan Faisandier
The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.
Systems Engineering Role in Transforming the Enterprise
Enabling Systematic Enterprise Change
The systems engineering (SE) process as applied to the enterprise as a whole could be used as the “means for producing change in the enterprise … [where the] … Seven Levels of change in an organization [are defined] as effectiveness, efficiency, improving, cutting, copying, differentiating and achieving the impossible” (McCaughin and DeRosa 2006). The essential nature of enterprise systems engineering (ESE) is that it “determines the balance between complexity and order and in turn the balance between effectiveness and efficiency. When viewed as the fundamental mechanism for change, it goes beyond efficiency and drives adaptation of the enterprise” (McCaughin and DeRosa 2006). McCaughin and DeRosa (2006) provide a reasonably good definition for an enterprise that captures this notion of balance:
Enterprise: People, processes and technology interacting with other people, processes and technology, serving some combination of their own objectives, those of their individual organizations and those of the enterprise as a whole.
Balancing Effectiveness versus Efficiency
Ackoff tells us that:
Data, information, knowledge and understanding enable us to increase efficiency, not effectiveness. The value of the objective pursued is not relevant in determining efficiency, but it is relevant in determining effectiveness. Effectiveness is evaluated efficiency. It is efficiency multiplied by value. Intelligence is the ability to increase efficiency; wisdom is the ability to increase effectiveness.
The difference between efficiency and effectiveness is reflected in the difference between development and growth. Growth does not require an increase in value; development does. Therefore, development requires an increase in wisdom as well as understanding, knowledge and information. ((Ackoff 1989, 3-9), emphasis added)
ESE has a key role to play in establishing the right balance between effectiveness and efficiency in enterprise operations and management. Value stream analysis is one technique, among others, that can help ESE determine where inefficiencies exist or ineffective results are being achieved.
Value Stream Analysis
Value stream analysis is one way of treating the enterprise as a system. It provides insights regarding where in the sequence of enterprise activities value is added as it moves towards the final delivery to customer or user (Rother and Shook 1999). It relates each step to the costs entailed in that step in terms of resource consumption (i.e., money, time, energy, and materials). In addition to direct costs, there may also be indirect costs due to overhead factors or infrastructure elements. This activity commonly involves drawing a flowchart of the value stream for the enterprise as illustrated in the figure below.
Analysis of this value stream diagram can highlight unnecessary space, excessive distance traveled, processing inefficiencies, and so on. Value stream mapping is associated with so-called “lean enterprise” initiatives. At Toyota, where the technique originated, it is known as “material and information mapping” (Rother 2009). Various value stream mapping tools are available (Hines and Rich 1997).
Enterprise Management Process Areas
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:
- Strategic technical planning,
- Capability-based planning analysis,
- Technology and standards planning, and
- Enterprise evaluation and assessment.
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.
Strategic Technical Planning
The purpose of strategic technical planning (STP) is to establish the overall technical strategy for the enterprise. It creates the balance between the adoption of standards (see also Systems Engineering Standards) and the use of new technologies, along with consideration of the people aspects driven by the relevant trans-disciplinary technical principles and practices from psychology, sociology, organizational change management, etc.
This process uses the roadmaps developed during technology and standards planning (TSP). It then maps these technologies and standards against the capabilities roadmap to determine potential alignment and synergy. Furthermore, lack of alignment and synergy is identified as a risk to avoid or an opportunity to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and projects.
One reason that STP and TSP are separate processes is that they are often done by different groups in the enterprise and they involve different skill sets. TSP is often done by the technology and science groups. TSP is done closer to (if not in) the chief architect and budget planning groups. Sometimes the great technology proposed by TSP just doesn’t line up with the capabilities needed in the requisite time frame. STP does this balancing between technology push and capability pull.
Capability-Based Planning Analysis
The purpose of Capability-based Planning Analysis is to translate the enterprise vision and goals into a set of current and future capabilities that helps achieve those goals. Current missions are analyzed to determine their suitability in supporting the enterprise goals. Potential future missions are examined to determine how they can help achieve the vision. Current and projected capabilities are assessed to identify capability gaps that prevent the vision and technical strategy from being achieved. These capability gaps are then used to assess program, project, and system opportunities that should be pursued by the enterprise. This is defined in terms of success criteria of what the enterprise is desired to achieve.
There are different types of capabilities, as shown in the figure below. It is common practice to describe capabilities in the form of capability hierarchies and capability roadmaps. Technology roadmaps (discussed below under Technology Planning) are usually related to the system capabilities while business capability roadmaps (BCRMs) are related to the operational capabilities of the enterprise as a whole (ref: Business-Capability Mapping: Staying Ahead of the Joneses, http://msdn.microsoft.com/en-us/library/bb402954.aspx). The BCRM development is usually done as part of enterprise strategic planning, which is one level higher than, and a key driver for, the strategic technical planning activity described above.
In some domains there may be competency roadmaps dealing with the organizational capabilities, with perhaps the desired competency levels of individuals mapped out in terms of the jobs or roles used in the enterprise or perhaps in terms of the knowledge and skills required for certain activities. (For more information on systems engineering competency, see the Enabling Individuals article.)
Technology and Standards Planning
The purpose of Technology Planning is to characterize technology trends in the commercial marketplace and the research community. This activity covers not just trend identification and analysis, but also technology development and transition of technology into programs and projects. It identifies current, and predicts future, technology readiness levels for the key technologies of interest. Using this information, it defines technology roadmaps. This activity helps establish the technical strategy and implementation guidance in the strategic technical plan. The business capabilities roadmap (BCRM) from the strategic planning activity is used to identify which technologies can contribute to achieved targeted levels of performance improvements.
The purpose of Standards Planning is to assess technical standards to determine how they inhibit or enhance the incorporation of new technologies into systems development projects. The future of key standards is forecast to determine where they are headed and the alignment of these new standards with the life cycles for the systems in the enterprise’s current and projected future portfolios. The needs for new or updated standards are defined and resources are identified that can address these needs. Standardization activities that can support development of new or updated standards are identified (See also Systems Engineering Standards).
Enterprise Evaluation and Assessment
The purpose of enterprise evaluation and assessment (EE&A) is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.
This process establishes a measurement program as the means for collecting data for use in the evaluation and assessment of the enterprise. These measures help determine whether the strategy and its implementation are working as intended. Measures are projected into the future as the basis for determining discrepancies between what is observed and what had been predicted to occur. This process helps to identify risks and opportunities, diagnose problems, and prescribe appropriate actions. Sensitivity analysis is performed to determine the degree of robustness and agility of the enterprise.
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:
must de-emphasize the utility of comparing detailed metrics against specific individual requirement values, whether the metrics are derived from measurement, simulation or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled.
Key characteristics of this activity are the following:
- Multi-scale analysis,
- Early and continuous operational involvement,
- Lightweight command and control (C2) capability representations,
- Developmental versions available for assessment,
- Minimal infrastructure,
- Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and
- In-line, continuous performance monitoring and selective forensics. (Roberts 2006)
Enterprise architecture (EA) can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The structure and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process presented by Martin (2005), the architecture should be driven by the “business questions” to be addressed by the architecture).
The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the elements that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency (NOAA) EA shown by Martin (2003a and 2003b). The measures are shown, in this example, as success factors, key performance indicators, and information needs in the business strategy layer of the architecture.
EA can be viewed as either the set of artifacts developed as “views” of the enterprise, or as a set of activities that create, use, and maintain these artifacts. The literature uses these terms in both senses and it is not always clear in each case which sense is intended.
Enterprise Portfolio Considerations
Opportunity Assessment and Management
The management activities dealing with opportunities (as opposed to just risk) are included in ESE. According to White (2006), the “greatest enterprise risk may be in not pursuing enterprise opportunities.” Hillson believes there is:
a systemic weakness in risk management as undertaken on most projects. The standard risk process is limited to dealing only with uncertainties that might have negative impact (threats). This means that risk management as currently practiced is failing to address around half of the potential uncertainties—the ones with positive impact (opportunities). (Hillson 2004)
White claims that “in systems engineering at an enterprise scale the focus should be on opportunity, and that enterprise risk should be viewed more as something that threatens the pursuit of enterprise opportunities” (White 2006). The figure below (Rebovich and White 2011, chapter 5) shows the relative importance of opportunity and risk at the different scales of an individual system, a system of systems (SoS), and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.
Enterprise Architecture and Requirements
EA goes above and beyond the technical components of product systems to include additional items such as strategic goals and objectives, operators and users, organizations and other stakeholders, funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer (CIO), and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Nemes, and Schmidt 2003).
Architecture descriptions following the guidelines of an architecture framework have been used to standardize the views and models used in architecting efforts (Zachman 1987 and 1992; Spewak 1992). Architecture descriptions have also been developed using a business-question based approach (Martin 2003b; Martin 2006). The standard on Architecture Description Practices (ISO/IEC 42010) (ISO/IEC 2011) has expanded its scope to include requirements on architecture frameworks.
Government agencies have been increasingly turning to SE to solve some of their agency-level (i.e., enterprise) problems. This has sometimes led to the use of an architecture-based investment process, especially for information technology procurements. This approach imposes a requirement for linking business strategies to the development of EAs. The Federal Enterprise Architecture Framework (FEAF) (CIO Council 1999) and the DoD Architecture Framework (DoDAF) (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 2000; ISO/IEC 1998; NATO 2004; TOGAF 2009; MOD 2010; TRAK 2010).
ESE Process Elements
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:
- Strategic Technical Planning,
- Capability-Based Planning Analysis,
- Technology and Standards Planning,
- Enterprise Evaluation and Assessment,
- Opportunity and Risk Assessment and Management,
- Enterprise Architecture and Conceptual Design,
- Enterprise Requirements Definition and Management,
- Program and Project Detailed Design and Implementation,
- Program Integration and Interfaces,
- Program Validation and Verification,
- Portfolio and Program Deployment and Post Deployment, and
- Portfolio and Program Life Cycle Support.
The first seven of these elements were described in some detail above. The others are more self-evident and are not discussed in this article.
References
Works Cited
Ackoff, R.L. 1989. "From Data to Wisdom." Journal of Applied Systems Analysis. 16 (1): 3-9.
Bernus, P., L. Nemes, and G. Schmidt (eds.). 2003. Handbook on Enterprise Architecture. Berlin and Heidelberg, Germany: Springer-Verlag.
CIO Council. 1999. Federal Enterprise Architecture Framework (FEAF), Version 1.1. Washington, DC, USA: Federal Chief Information Officers Council.
DoD. 2010. DoD architecture framework (DoDAF), version 2.0. Washington, DC: US Department of Defense (DoD).
Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.
Hillson, D. 2004. Effective Opportunity Management for Projects: Exploiting Positive Risk. Petersfield, Hampshire, UK; New York, NY, USA: Rick Doctor & Partners; Marcel Dekker, Inc.
Hines, P., and N. Rich. 1997. "The Seven Value Stream Mapping Tools." International Journal of Operations & Production Management. 1 (17): 46-64.
ISO. 2000. ISO 15704:2000, Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies. Geneva, Switzerland: International Organization for Standardization (ISO).
ISO/IEC/IEEE. 2011. Systems and software engineering - Architecture description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.
ISO/IEC. 1998. ISO/IEC 10746:1998, Information Technology — Open Distributed Processing — Reference Model: Architecture. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC).
Martin, J.N. 2010. "An Enterprise Systems Engineering Framework." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 2010, Chicago, IL, USA.
Martin, J.N. 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." PhD dissertation. Fairfax, VA, USA: George Mason University.
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.
Martin, J.N. 2003a. "An Integrated Tool Suite for the NOAA Observing System Architecture." Presented at 13th Annual International Council on Systems Engineering (INCOSE) International Symposium, 2003, Arlington, VA, USA.
Martin, J.N. 2003b. "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.
McCaughin, K., and J.K. DeRosa. 2006. "Process in Enterprise Systems Engineering." Presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA.
MOD. 2010. Ministry of Defence Architecture Framework (MODAF), version 1.2.004. London, England, UK: UK Ministry of Defence. Accessed September 8, 2011. Available: http://www.mod.uk/NR/rdonlyres/04B5FB3F-8BBC-4A39-96D8-AFA05E500E4A/0/20100602MODAFDownload12004.pdf.
NATO. 2010. NATO Architecture Framework (NAF), version 3.1. Brussels, Belgium: North Atlantic Treaty Organization.
Rebovich, G., and B.E. White (eds.). 2011. Enterprise Systems Engineering: Advances in the Theory and Practice. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group, Auerbach.
Roberts, J.L. 2006. "Enterprise Analysis and Assessment." Presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2006, Orlando, FL, USA.
Rother, M. 2009. Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results. New York, NY, USA: McGraw-Hill.
Rother, M., and J. Shook. 1999. Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA. Cambridge, MA, USA: Lean Enterprise Institute.
Spewak, S.H. 1992. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology. New York, NY, USA: Wiley and Sons, Inc.
TOGAF. 2009. "The Open Group Architecture Framework," version 9. Accessed September 2, 2011. Available: http://www.opengroup.org/togaf.
TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available: http://trak.sourceforge.net/index.html.
White, B.E. 2006. "Enterprise Opportunity and Risk." Presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-13, 2010, Orlando, FL, USA.
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-292.
Primary References
Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.
Martin, J.N. 2010. "An Enterprise Systems Engineering Framework." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 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 & Francis Group, Auerbach.
Additional References
DeRosa, J.K. 2005. "Enterprise Systems Engineering." Presented at Air Force Association, Industry Day, Day 1, August 4, 2005, Danvers, MA, USA.
Holt, J., and S. Perry. 2010. Modelling enterprise architectures. Stevenage, England, UK: Institution of Engineering and Technology (IET).
Kaplan, R., and D. Norton. 1996. The Balanced Scorecard: Translating Strategy into Action. Cambridge, MA, USA: Harvard Business School Press.
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. A Practical Guide to Enterprise Architecture. New York, NY, USA: Prentice Hall.
Swarz, R.S., J.K. DeRosa, and G. Rebovich. 2006. "An Enterprise Systems Engineering Model." INCOSE Symposium Proceedings, July 9-13, 2006, Orlando, FL, USA.