View source for Enterprise Systems Engineering Process Activities

==Systems Engineering Role in Transforming the Enterprise==
===Enabling Systematic Enterprise Change===
The [[Systems Engineering (glossary)]] [[Acronyms|(SE)]] [[Process (glossary)]] as applied to the [[Enterprise (glossary)]] as a whole could be used as the “means for producing change in the enterprise … [where the] … Seven Levels of change in an [[Organization (glossary)|organization]] [are defined] as [[Effectiveness (glossary)|effectiveness]], efficiency, improving, cutting, copying, differentiating and achieving the impossible.”  (McCaughin and DeRosa 2006).  The essential nature of [[Enterprise Systems Engineering (ESE) (glossary)]] [[Acronyms|(ESE)]] is that it “determines the balance between [[Complexity (glossary)|complexity]] (see also [[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).  They provide a reasonably good definition for an enterprise that captures well this notion of balance:
<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.''
</BLOCKQUOTE>

===Effectiveness vs. Efficiency===
Ackoff tells us that:
<BLOCKQUOTE>
Data, information, knowledge and understanding enable us to increase efficiency, not effectiveness. The [[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''.

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>

===Enterprise Management Process Areas===
The “System and [[Program (glossary)]] Management” process area is dropped from the matrix (see Table 1 in [[Enterprise Systems Engineering Key Concepts]]) since, in an enterprise, this process area is not directly applicable. Instead, this is the responsibility of the Programs within the Enterprise. This process area is replaced with the following four process areas (which, altogether, are the key elements of the Enterprise Management process that oversees the “SE” of the enterprise as a whole):
*Strategic Technical Planning
*Capability-Based Planning Analysis
*Technology and Standards Planning
*Enterprise Evaluation and Assessment

==Strategic Technical Planning==
The purpose of strategic technical planning 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 transdisciplinary technical principles and practices from psychology, sociology, organizational change management, etc. This process uses the roadmaps developed during technology and standards planning. It then maps these technologies and standards against the [[Capability (glossary)|capabilities]] roadmap to determine potential alignment and synergy. Furthermore, lack of alignment and synergy is identified as a [[Risk (glossary)]] to avoid or an [[Opportunity (glossary)]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].

==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 [[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 [[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 [[Business (glossary)]] capability roadmaps [[Acronyms|(BCRMs)]] are related the [[Operational (glossary)]] 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 (glossary)]] 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 SE competency, see the [[ Enabling Individuals to Perform Systems Engineering ]] article.)

[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]

==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 Cycle (glossary)|life cycles]] for the systems in the enterprise’s current and projected future [[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==
The purpose of enterprise evaluation and assessment [[Acronyms|(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 (glossary)]] program as the means for collecting data for use in the evaluation and assessment of the enterprise. These [[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 [[Robustness (glossary)]] and [[Agility (glossary)]] 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:
<BLOCKQUOTE>
must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|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 (glossary)|control]] [[Acronyms|(C2)]] capability representations
*Developmental versions available for assessment
*Minimal infrastructure
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities
*In-line, continuous performance monitoring and selective forensics (Roberts 2006).
</BLOCKQUOTE>
[[Enterprise Architecture (glossary)]] [[Acronyms|(EA)]] can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a [[Model (glossary)]] to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The [[Structure (glossary)]] and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process in (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 [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown in (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 (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. In other words, EA can be viewed as either the “noun” (i.e., things) or the “verb” (i.e., actions). The literature uses these terms in both senses and it is not always clear in each case which sense is intended.

==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:
<BLOCKQUOTE>
a systemic weakness in [[Risk Management (glossary)|risk management]] as undertaken on most [[Project (glossary)|projects]]. The standard risk process is limited to dealing only with uncertainties that might have negative impact ([[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>
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 [[Acronyms|(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:Wiki_CR_Placeholder.png|thumb|center|400px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Source available at http://www.taylorandfrancis.com/books/details/9781420073294/]]

==Enterprise Architecture and Requirements==
EA goes above and beyond the technical components of [[Product (glossary)]] systems to include additional items such as strategic goals and objectives, operators and [[User (glossary)|users]], organizations and other [[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 [[Acronyms|(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, Laszlo, 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 2007) is expanding its scope to include requirements on architecture frameworks (to be published in 2012).

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 [[Acronyms|(FEAF)]](CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(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 15704 2000; ISO/IEC 10746 1998; NATO 2004; 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
#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'' : 3-9. 

Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'',  Berlin & Heidelberg, Germany: Springer-Verlag. 

CIO Council. 1999. "Federal Enterprise Architecture Framework (FEAF), Version 1.1" Washington, DC, USA: Federal Chief Information Officers Council. http://www.cio.gov/documents_details.cfm/uid/1F432311-2170-9AD7-F2053C10765E0E1C/structure/Enterprise%20Architecture/category/Enterprise%20Architecture Accessed on September 7, 2011.

DoD. 2010. "DoD architecture framework (DoDAF)". version 2.0. Washington, DC: U.S. 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: Rick Doctor & Partners; Marcel Dekker, Inc. 

ISO 15704. 2000. ''"Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies."'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. 

ISO/IEC 42010. 2007. ''"Systems and Software Engineering — Recommended Practice for Architectural Description of Software-Intensive Systems."'' Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007. 

ISO/IEC 10746. 1998. ''"Information Technology — Open Distributed Processing — Reference Model: Architecture."'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 10746:1998. 

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. 

Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods. PhD., George Mason University. 

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

Martin, J.N., 2003a. "An Integrated Tool Suite for the NOAA Observing System Architecture." Paper presented at 13th Annual International Council on Systems Engineering (INCOSE) International Symposium, Arlington, VA, USA. 

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

McCaughin, K., and J.K. DeRosa. 2006. "Process in Enterprise Systems Engineering." Paper presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-13 July, 2006, Orlando, FL, USA. 

MOD. 2010. "Ministry of Defence Architecture Framework (MODAF)." version 1.2.004 UK: U.K. Ministry of Defence. http://www.mod.uk/NR/rdonlyres/04B5FB3F-8BBC-4A39-96D8-AFA05E500E4A/0/20100602MODAFDownload12004.pdf Accessed September 8, 2011.

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

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. http://www.opengroup.org/togaf Accessed on September 2, 2011. 

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

White, B.E. 2006. "Enterprise Opportunity and Risk." Paper presented at 16th Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-13 July, 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-92.

===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]]." Paper presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA. 

Rebovich, G., and B.E. White, eds. 2011. ''"[[Enterprise Systems Engineering: Advances in the Theory and Practice]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group, Auerbach.

===Additional References===

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

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. 
----
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center>

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

{{DISQUS}}

[[Category: Part 4]][[Category:Topic]]
[[Category:Enterprise Systems Engineering]]