https://sebokwiki.org/w/api.php?action=feedcontributions&user=Janthony&feedformat=atom
SEBoK - User contributions [en]
2024-03-28T08:48:08Z
User contributions
MediaWiki 1.35.13
https://sebokwiki.org/w/index.php?title=Architecting_Approaches_for_Systems_of_Systems&diff=46921
Architecting Approaches for Systems of Systems
2012-11-28T21:22:42Z
<p>Janthony: /* Challenges in Architecting SoS */</p>
<hr />
<div>A key part of [[Systems Engineering (glossary)|systems engineering]] (SE) for [[System of Systems (SoS) (glossary)|system of systems]] (SoS) is the composition of systems to meet SoS needs. This may include simply interfacing systems and leveraging their existing functionality or it may require changing the systems functionality, performance or interfaces. These changes occur incrementally, as a SoS evolves over time to meet changing SoS objectives. System of Systems Engineering (SoSE) supports these changes by developing and evolving a technical framework that acts as an overlay to the systems of which the SoS is composed. This framework provides the ''architecture'' for the SoS. The SoS architecture defines how the systems work together to meet SoS objectives and considers the details of the individual systems and their impact the SoS performance or functionality. <br />
<br />
==The Role of System of Systems Architecting==<br />
An [[Architecture (glossary)|architecture]] is the structure of components, their relationships, and the principles and guidelines governing their design evolution over time (IEEE Std 610.12). <br />
<br />
In a SoS, the architecture is the technical framework for the systems comprising the SoS which designates how the systems will be employed by the users in an operational setting (sometimes called the [[Concept of Operations (ConOps) (glossary)|concept of operations]] (CONOPs or CONOPs), the internal and external relationships and dependencies among the constituent systems and their functions and, finally, the end-to-end functionality and data flow as well as communications among the systems.<br />
<br />
Because SoS largely comprise extant independent systems, these place constraints on the SoS architecture and may require that migration to a SoS architecture be incremental. Developing a SoS architecture requires consideration of technical feasibility for the constituent systems as well as the needs of the SoS itself. Architecture data for the constituent systems can also be important data for architecting the SoS. <br />
<br />
Maier (1998) provides a conceptual discussion on the impact of SoS characteristics on SoS architecting. Additionally, the US DoD SE Guide for SoS (2008) describes practical considerations in developing and evolving a SoS architecture as a core element of SoSE.<br />
<br />
==Challenges in Architecting SoS==<br />
In the case of a new system development, the systems engineer can begin with a fresh, unencumbered approach to architecture. However, in a SoS, the systems contributing to the SoS objectives are typically in place when the SoS is established and the SoS engineer needs to consider the current state and plans of the individual systems as important factors in developing an architecture for the SoS. This, along with the fact that constituent systems may be complex systems in their own right, leads to a set of challenges to architecting SoS.<br />
<br />
First, as noted above, the managerial and operational independence of constituent systems can pose major challenges for the SoS architecture. Because systems are likely to continue to face new functional requirements and the need for technology upgrades independent of the SoS, there is an advantage to a SoS architecture, which is loosely coupled; that is, it has limited impact on the individual systems, allowing for changes in functionality and technology in some systems without impact on others or on the SoS objectives. Dagli and Kilicay-Ergin (2009) have suggested that SoS architecting should be considered to be an evolutionary process.<br />
<br />
Secondly, the independence of the constituent systems also means that these systems are typically not designed to optimize SoS objectives. In the area of trust for example, a system may severely constrain access to services to provide a level of security and a SoS may depend on free exchange of those services. (Rebovich 2009) has articulated this difficulty as a fundamental problem of SoS:<br />
<br />
<blockquote>''From the single-system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders.''</blockquote><br />
<br />
Finally, as introduced in the article [[Emergence]], there are risks associated with unexpected or unintended behavior resulting from combining systems that have individually complex behavior. These become serious in cases which safety, for example, is threatened through unintended interactions among the functions provided by multiple constituent systems in a SoS.<br />
<br />
Finally, the development and implementation of a SoS architecture may be significantly constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses. In this case, approaches such as gateways and ''wrapping'' may be used to incorporate these systems into the SoS without making significant changes in the other systems.<br />
<br />
==Architecture Analysis==<br />
''Large-scale systems integration'' has grown in importance and correspondingly, there has been a growing interest in SoS concepts and strategies. The performance and functioning of groups of heterogeneous systems has become the focus of various applications including military, security, aerospace, distributed energy, healthcare, and disaster management systems (Lopez 2006; Wojcik and Hoffman 2006). There is an increasing interest in exploiting synergy between these independent systems to achieve the desired overall system performance (Azarnoush, et. al. 2006).<br />
<br />
Modeling and simulation is conducted to analyze architecture effectiveness and to verify architectural features. In the literature, researchers have addressed the issues of coordination and [[Interoperability (glossary)|interoperability]] in a SoS (Abel & Sukkarieh 2006; Sahin et. al. 2007). In order to study SoS characteristics and parameters, one needs to have realistic simulation frameworks properly designed for system of systems architecture. There are some attempts to develop simulation frameworks for multi-agent systems using Discrete Event Simulation (DEVS) tools (Zeigler, et. al. 2000a). In these research efforts, the major focus is given to DEVS architecture with JAVA. In (Mittall, 2000b), DEVS state machine approach is introduced. Finally, DEVS Modeling Language (DEVSML) is developed by using XML based JAVA in order to simulate systems in a net-centric way with relative ease. Sahin et. al. (2007) have recently introduced a discrete event XML based SoS simulation framework based on DEVS and JAVA.<br />
<br />
==The Open Approach to SoS Engineering==<br />
As noted above, one of the key challenges with SoS architecting is that the constituent systems of a SoS may not have been designed, developed and employed with regard to their role in the SoS, which constrains SoS architecture options. The degree to the architecture which ''overlays'' these constituent systems and supports the SoS end-to-end capabilities can be based on open standards; the SoS may be able to benefit from open architecture for future evolution.<br />
<br />
The critical challenge of moving from SoS, as a concept to the engineering of SoS, is the significant technological, human, and organizational differences in consideration system of systems engineering and management approaches (Wells and Sage 2008). A potential approach to engineering a SoS can be the ''open systems approach'' to SoSE (Azani 2009). The following open systems principles are listed by Azani (2009):<br />
*'''Open interface principle''' - Open systems have permeable boundaries that allow them to exchange mass, energy, and information with other systems;<br />
*'''Synergism principle''' – The notion that designates that the co-operative interaction between constituent systems has a greater effect in their combined efforts than the sum of their individual parts. Essentially, this is what gives rise to emergence;<br />
*'''Self-government principle''' - This implies that the SoS maintains and develops its internal order without interference from external sources. This could be through cybernetic control, homeostasis, or self-organization;<br />
*'''Emergence principle''' - In this case, this refers to the occurrence of novel and coherent structures, patterns, and properties during the self-organization of the SoS;<br />
*'''Conservation principle''' – This principle states that energy and mass (material) are conserved within the SoS;<br />
*'''Reconfiguration principle''' – This refers to the SoS reconfiguring and adapting itself to sustain itself against changes in its environment;<br />
*'''Symbiosis principle''' - The systems within the SoS have a symbiotic relationship to each other; more transparently, the successful development and sustainment of a SoS depends on symbiotic collaboration between the stakeholders of the systems of which it is comprised; and<br />
*'''Modularity principle''' - This holds that each level and each system is to some extent independent of others. In SoS design, the development of independent modular systems that interoperate with each other through standardized interfaces enables greater flexibility to promote better evolution of the SoS.<br />
<br />
Azani (2009) elaborates on the open systems development strategies and principles utilized by biotic SoS, discusses the implications of engineering of man-made SoS, and introduces an integrated SoS development methodology for the engineering and development of an adaptable, sustainable, and interoperable SoS based on open systems principles and strategies.<br />
<br />
Hitchens (2003, 107), on the other hand, discusses the principles of open systems rather differently in terms of their systems life cycles, as the seven principles that he addresses are system reactions, system cohesion, system adaptation, connected variety, limited variety, preferred patterns, and cyclic progression. This description takes a systems dynamics approach to show how open systems evolve; the description is applicable to natural and man-made systems.<br />
<br />
The enablers of openness include open standards and open specifications, which draw from consensus amongst a community of interest, and are published by, and freely available within, that community. An open specification must ensure that its detail-level is allows for it to be implementable by independent parties. Compliance with open standards is intended to ensure consistent results (Henshaw, et. al., 2011). This parallels the notion of open systems architecture, which is an open specification of the architecture of a system or system of systems for the purpose of acquiring specified capabilities. As a general feature of good design (for a system or system of systems), an open system architecture should allow for the quick and easy improvement and updating of the system capabilities, by adding or changing components. However, Henshaw et. al. (2011) also denote that open architecture represents a commercial challenge (rather than a technical one) and that establishing open architecture approaches to acquisition can be challenging, due to issues involving protection of intellectual property (IP) and commercial advantage.<br />
<br />
==Networks and Network Analysis==<br />
Because networks are such a common component of SoS, they warrant specific attention. In SoS that are based on an underlying network, communications and information exchange typically constitute a SoS in its own right. This enabling SoS requires architecting like any other SoS, which will be addressed in this section. In the case of an enabling network SoS, the ‘user’, the end-to-end functionality of the larger SoS and enabling network SoS is driven by these user needs. The relationship between SoSE concepts and network enablement, as well as the concepts of networks and network analysis that extend beyond information sharing, have been explored extensively by the defense community (Dickerson and Mavris 2009). For instance, during the U.S. Navy’s work on command, control, communications, computers, intelligence, surveillance, and reconnaissance (C4ISR) as part of a SoS (Owens 1996), the term network included organizational aspects of command and control (C2) structure as well as communications.<br />
<br />
Differences in the architecting of an enabling network SoS derive from the fact that these SoS are typically built on commercial technologies and architectures, which are changing rapidly in today’s dynamic technological environment. In addition, these enabling networks are often shared among SoS and hence may further constrain the overall SoS architecture. For example, many SoS (for cost and convenience) expect to operate over the internet, and therefore must consider characteristics of the internet in the expectations for performance and security provided by use of a shared enabling infrastructure.<br />
<br />
Enabling network SoS architecting is particularly well-served by the initial analysis that explores sensitivities through modeling, simulation, analysis, and/or laboratory experimentation and identifies scalability issues or divergent behavior (e.g., concerning requirements or usage assumptions, assumed network bandwidth, or others), beyond which performance starts to break down. This type of analysis provides a basis for network architecture decisions.<br />
<br />
In directed SoS, because of the top-down control, there is the option for creating a specialized network for the particular SoS. In the other types of SoS, if the constituents are already supported by some type of a network then the overall SoS networking approach typically needs to accommodate these since the constituent systems are likely to need to continue to use their current approach to support their original users.<br />
<br />
==Interoperability==<br />
[[Interoperability (glossary)|Interoperability]] within a SoS implies that each system can communicate and interact (control) with any other system regardless of their hardware and software characteristics or nature. This implies that each constituent member (and potential new members) of a SoS should be able to communicate with others without compatibility issues in the operating systems, communication hardware, and so on. For this purpose, a SoS needs a common language the SoS’s systems can speak. Challenges here are to work towards a common language for exchange of information and data among systems of a SoS. Examples of such system are XML (eXtensible Markup Language), as one potential candidate (Jamshidi, 2009a).<br />
<br />
However, interoperability must be achieved at many levels and not just at the data/network level. There are a number of frameworks that describe the levels of interoperability. From military applications, the NCOIC (Network Centric Operations Industry Consortium) Interoperability Framework (NCOIC 2008) covers three broad levels of interoperability, subdivided into further layers as indicated below: <br />
<br />
* Network Transport: <br />
** Physical Interoperability and <br />
** Connectivity and Network Interoperability; <br />
<br />
* Information Services: <br />
** Data/Object Model Interoperability, <br />
** Semantic/Information Interoperability, and <br />
** Knowledge/Awareness of Actions Interoperability; and <br />
<br />
* People, Processes and Applications: <br />
** Aligned Procedures, <br />
** Aligned Operations, <br />
** Harmonized Strategy/Doctrine, and <br />
** Political or Business Objectives. <br />
<br />
This spectrum of interoperability layers requires appropriate coherence at each layer consistent with the SoS shared goals.<br />
<br />
There exist interoperability frameworks in other fields of activity. An example is the European Interoperability Framework (European Commission 2004), which focuses on enabling business (particularly e-business) interoperability and has four levels within a political context:<br />
* Legal Interoperability, <br />
* Organizational Interoperability, <br />
* Semantic Interoperability, and <br />
* Technical Interoperability. <br />
<br />
The interoperability between the component systems of a SoS is a fundamental design consideration for SoS that may be managed through the application of standards.<br />
<br />
==Standards==<br />
[[Systems Engineering Standards|Standards]] of system of systems engineering is perhaps the greatest challenge facing SoSE community. The reason for this assertion is that in SoSE, many areas of systems engineering have yet to fully address other challenges of SoSE. It is a challenging to establish standards for SoS when the architecture, network centricity, control, modeling, simulation, etc. for SoS are yet to mature. Johnson (2009) has surveyed the literature on standards and specifies that currently, with exception of IT service, standards for SoSE is an area of that needs the consideration of organizations like NIST and ISO. This is perhaps the reason that there are currently no standards specifically written for SoS or SoSE products, processes, management, or other endeavors (Johnson 2009); however, there are many standards that address aspects of SoS management (such as ISO 20000 IT service management and the draft ISO 55000 Asset Management) and [[Interoperability (glossary)|Interoperability]].<br />
<br />
Much of the current work in SoS is being done in engineering and acquisition; in the area of engineering the concept of a universally agreed-upon set of guidelines for interoperability is important. These guidelines provide four levels of standardization: compatibility, interchangeability, commonality, and reference (Johnson 2009), which are relevant to the SoS environment through the creation of compatibility, similarity, measurement, and symbol and ontological standardization. As the various disciplines that are relevant to SoS mature, standards will be required to ensure that these four levels of the SoS standardization are met (Jamshidi 2009b).<br />
<br />
Interoperability is a key area for standardization. One effort to provide a semantic and syntactic interoperability standard, ''Levels of Information System Interoperability'', was developed by the US DoD C4ISR organization (DoD 1998). Overall, open standards are viewed as an effective way to reduce the risks associated with lack of interoperability in SoS. An open standard is a standard that is consensus-based amongst a community of interest and is published by and freely available within that community of interest (Henshaw et. al 2011). This has been emphasized in the software domain; for instance (Hall 2007), the suggested that the DoD adopt open IT standards and to influence these appropriately through participation in standards developing organizations and/or standards setting organizations in the area of information and communications technologies.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Abel, A. and Sukkarieh, S. 2006. "The Coordination of Multiple Autonomous Systems using Information Theoretic Political Science Voting Models." In the Proceedings of the IEEE International Conference on System of Systems Engineering, 24-26 April, Los Angeles.<br />
<br />
Azani, C. 2009. ''A Multi-criteria Decision Model for Migrating Legacy System Architectures into Open Systems and Systems-of-Systems Architectures.'' Washington, DC, USA:Defense Acquisition University.<br />
<br />
Azarnoush, H., B. Horan, P. Sridhar, Madni, A.M., and M. Jamshidi. 2006. "Towards optimization of a real-world robotic-sensor system of systems". In the Proceedings of the World Automation Congress (WAC), July 24-26. Budapest, Hungary.<br />
<br />
Cloutier, R.M., J. DiMario, and H.W. Polzer. 2009. "Net-Centricity and System of Systems". Chapter in (Jamshidi 2009a) <br />
<br />
Dagli, C.H. and Kilicay-Ergin, N. 2009, "System of Systems Architecting". Chapter in (Jamshidi 2009a)<br />
<br />
Dickerson, C.E. and D. Mavris. (2009) ''Architecture and Principles of Systems Engineering''. New York, NY, USA:CRC Press, Auerbach Publications.<br />
<br />
DoD. 1998. Levels of Information System Interoperability. Washington, DC, USA: C4IST Interoperability Working Group, US Department of Defense.<br />
<br />
Hall, J. 2007. Openness – An Important Principle For The Stewardship of DoD IT Standards. Assistant Deputy Under Secretary of Defense (LMR/LPS), and DoD Standards Executive, in ''DSPO Journal'' pg. 4-7, Mar/Jan. http://www.dsp.dla.mil/app_uil/content/newsletters/journal/DSPJ-01-07.pdf<br />
<br />
Henshaw, M. (ed.) ...et al. (2011) Assessment of open architectures within defence procurement issue 1: systems of systems approach community forum working group 1 - open systems and architectures. London: Crown owned copyright. (http://hdl.handle.net/2134/8828)<br />
<br />
Hitchins, D.K. 2003. ''Advanced Systems Thinking, Engineering and Management''. Norwood, MA, USA: ARTECH HOUSE, INC. (ISBN 1-58053-691-0).<br />
<br />
IEEE. 1990. Standard Glossary of Software Engineering Terminology, Std 610.12-1990. Washington, DC: Institute of Electrical & Electronics Engineers (IEEE). (ISBN 1-55937-067-X).<br />
<br />
Jamshidi, M. (ed.) 2009. ''Systems of Systems Engineering - Principles and Applications''. Boca Raton, FL, USA:CRC Press. (ISBN 978-1-4200-6588-6)<br />
<br />
Johnson M. 2009. "System of Systems Standards," in ''System of Systems Engineering - Innovations for the 21st Century''. Hoboken, NJ, USA: Wiley. <br />
<br />
Lopez D. 2006. "Lessons Learned From the Front Lines of the Aerospace." In the Proceedings of the IEEE International Conference on System of Systems Engineering, 24-26 April, Los Angeles, CA, US.<br />
<br />
Mittal, S. 2000. "DEVS Unified Process for Integrated Development and Testing of Service Oriented Architectures." Ph. D. Dissertation, Univ. Arizona.<br />
<br />
NCOIC. 2008. "NCOIC Interoperability Framework (NIF(R))". Available at: https://www.ncoic.org/technology/deliverables/nif/<br />
<br />
Owens, W.A. 1996. "The Emerging U.S. System-of-Systems." In The National Defense University, Institute of National Security Studies, Number 63, Washington D.C. February.<br />
<br />
Rebovich, Jr., G. 2009. ''Chapter 6: Enterprise System of Systems.'' ''Systems of Systems Engineering - Principles and Applications.'' Boca Raton, FL, USA: CRC Press, pg. 169. <br />
<br />
Sahin, F., M. Jamshidi, and P. Sridhar. 2007. "A Discrete Event XML based Simulation Framework for System of Systems Architectures." In the Proceedings of the IEEE International Conference on System of Systems, 16-18 April 2007, San Antonio, TX, US.<br />
<br />
U.S. Department of Defense, 2008, ''Systems Engineering Guide for Systems of Systems''. Version 1.0. August. Washington. DC<br />
<br />
Wells, G.D. and A.P. Sage. 2008. ''Engineering of a System of Systems.'' ''Systems of Systems Engineering - Principles and Applications.'' Boca Raton, FL, USA: CRC Press. <br />
<br />
Wojcik, L.A. and K.C. Hoffman. 2006. "Systems of Systems Engineering in the Enterprise Context: A Unifying Framework for Dynamics." In the Proceedings of the IEEE International Conference on System of Systems Engineering, 24-26 April 2006, Los Angeles, CA, US.<br />
<br />
Zachmann, J. 1987. A framework for information systems architecture. ''IBM SYSTEMS JOURNAL'', 26(3). <br />
<br />
Zeigler, B.P., T.G. Kim, and H. Praehofer. 2000. ''Theory of Modeling and Simulation''. New York, NY, USA: Academic Press, .<br />
<br />
===Primary References===<br />
<br />
Chen, D., G. Doumeingts, F. Vernadat. 2008. "[[Architectures for Enterprise Integration and Interoperability]]: Past, Present and Future." ''Comput.Ind''. 9;59(7):647-659. <br />
<br />
Maier, M.W. 1998. "[[Architecting Principles for Systems-of-Systems]]." ''Systems Engineering'' 1(4): 267-284.<br />
<br />
===Additional References===<br />
Dickerson, C.E., S.M. Soules, M.R. Sabins, and P.H. Charles. 2004. ''Using Architectures for Research, Development, and Acquisition''. Washington, DC: Office of the Assistant Secretary of The Navy (Research Development And Acquisition). ADA427961. Available at: http://handle.dtic.mil/100.2/ADA427961<br />
<br />
European Commission. 2010.Annex to the Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of Region, ''Towards interoperability for European public services.'' Available at: http://ec.eupora.eu/isa/strategy/doc/annex_ii_eif_en.pdf<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems, Theory, Architecture, and Methods''. Boca Raton, FL, USA: CRC Press, <br />
<br />
Rhodes, D.H., A.M. Ross, and D.J. Nightingale. 2010. ''Architecting the System of Systems Enterprise: Enabling Constructs and Methods from the Field of Engineering Systems''. Institute of Electrical and Electronics Engineers. <br />
<br />
MITRE. 2012. "Architectures Federation." In ''Systems Engineering Guide.'' MITRE Corporation. <br />
http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/engineering_info_intensive_enterprises/architectures_federation.html. Accessed 11 September 2012.<br />
<br />
Mittal, S. 2000a. "Extending DoDAF to Allow DEVS-Based Modeling and Simulation." Journal of Defense Modeling and Simulation (JDMS). 3(2).<br />
<br />
Valerdi R., Axelband E., Baehren T., Boehm B., Dorenbos D., et al. 2008. "A research agenda for systems of systems architecting". ''International Journal of System of Systems Engineering''. 1 (1-2): 171-188.<br />
<br />
Zeigler, B.P, D. Fulton, P. Hammonds, and J. NutaroJ. 2000. "Framework for M&S–Based System Development and Testing in a Net-Centric Environment." ''ITEA Journal of Test and Evaluation''. 26(3), 21-34.<br />
----<br />
<center>[[Systems of Systems (SoS)|< Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Socio-Technical Features of Systems of Systems|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Systems of Systems (SoS)]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46920
Enterprise Systems Engineering Process Activities
2012-11-28T21:20:49Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
''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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
''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'''.''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.''</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC. 2011. ''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:2011. <br />
<br />
ISO/IEC. 1998. ''Information Technology — Open Distributed Processing — Reference Model: Architecture.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 10746:1998. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46919
Enterprise Systems Engineering Process Activities
2012-11-28T21:18:55Z
<p>Janthony: /* Enterprise Architecture and Requirements */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
''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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
''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'''.''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.''</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46918
Enterprise Systems Engineering Process Activities
2012-11-28T21:16:33Z
<p>Janthony: /* Opportunity Assessment and Management */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
''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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
''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'''.''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.''</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; TOGAF 2009; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46917
Enterprise Systems Engineering Process Activities
2012-11-28T21:16:09Z
<p>Janthony: /* Enterprise Evaluation and Assessment */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
''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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
''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'''.''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.''</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; TOGAF 2009; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46916
Enterprise Systems Engineering Process Activities
2012-11-28T21:15:32Z
<p>Janthony: /* Systems Engineering Role in Transforming the Enterprise */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
''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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
''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'''.''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.”</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; TOGAF 2009; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=46915
Enterprise Systems Engineering Key Concepts
2012-11-28T21:14:24Z
<p>Janthony: /* Role of Requirements in ESE */</p>
<hr />
<div>The purpose of traditional systems engineering (TSE) is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[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 [[organization (glossary)|organization]] where information-intensive systems are becoming central elements of the organization’s [[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 [[context (glossary)|context]] of government [[acquisition (glossary)|acquisition]] of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control systems).<br />
<br />
ESE encompasses this traditional role in system acquisition, but also incorporates [[enterprise (glossary)|enterprise]] strategic [[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).<br />
<br />
==Closing the Gap==<br />
ESE practices have undergone significant development recently.<br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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 [[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:<br />
*strategic technical planning,<br />
*enterprise architecture,<br />
*capabilities-based planning analysis,<br />
*technology planning, and<br />
*enterprise analysis and assessment.<br />
<br />
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 15288 standard (2008).<br />
<br />
[[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.]]<br />
<br />
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)|project]]. In MITRE, this restricted definition was referred to as TSE. Many have taken a wider view seeking to apply SE to the “whole system” and “whole [[Life Cycle (glossary)|life cycle]].” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on [[operational (glossary)|operational]] purpose. Elliott and Deasley (2007) discuss the differences between development phase SE and in-service SE.<br />
<br />
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 [[portfolio (glossary)|portfolio]]. 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 a work by Rebovich and White (2011).<br />
<br />
==Role of Requirements in ESE==<br />
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).<br />
<br />
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)|governance]] priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:<br />
<br />
<BLOCKQUOTE><br />
''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.'' (Swarz et al. 2006) (See also [[Complexity]])<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
==Enterprise Entities and Relationships==<br />
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. <br />
<br />
:<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 [[Data Center (glossary)|data center]], data warehouse, and other such facilities and equipment used across one or more organizations.</I><br />
<br />
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).<br />
<br />
{|<br />
|+'''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.<br />
!Asset Domains<br />
!Concept Domains<br />
|-<br />
|Application and Software Domain<br />
Data Domain<br />
Document Domain<br />
Infrastructure and Hardware Domain<br />
IT Product Domain<br />
IT Service Domain<br />
Location Domain<br />
Organization Domain<br />
Product and Service Domain<br />
Services Portfolio Management Domain<br />
|Analysis Domain<br />
Financial Domain<br />
General Domain<br />
Information Domain<br />
IT Architecture Domain<br />
Knowledge and Skill Domain<br />
Market Domain<br />
Policy Domain<br />
Process Domain<br />
Resource Domain<br />
Strategy Domain<br />
Timeline Domain<br />
Transition Domain<br />
|}<br />
<br />
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.<br />
<br />
[[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.]]<br />
<br />
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 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.<br />
<br />
==Enterprise Architecture Frameworks & Methodologies==<br />
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 informal, based on more rigorous modeling tools and methods. ISO/IEC 42010 (2011) specifies how to create architecture descriptions. <br />
<br />
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 Architecture (glossary)|enterprise architecture]]. <br />
<br />
Urbaczewski and Mrdalj (2006) provide an overview and comparison of five prominent architectural frameworks, including:<br />
* the Zachman Framework for Enterprise Architecture (Zachman 1992), <br />
* the Department of Defense Architecture Framework (DoDAF) (DoD 2010), <br />
* the Federal Enterprise Architecture Framework (FEAF) (FEA 2001), <br />
* the Treasury Enterprise Architecture Framework (TEAF) (US Treasury 2000), <br />
* and The Open Group Architectural Framework (TOGAF) (TOGAF 2009).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Carlock, P. and R. Fenton. 2001. “System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations,” ''Systems Engineering, 4(4): 242-261.<br />
<br />
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.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
DoD. 2010. ''DoD Architecture Framework (DoDAF)'', version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Elliott, C. and P. Deasley. 2007. "Creating Systems that Work--Principles of Engineering Systems for the 21st Century." (17). London, England, UK: Royal Academy of Engineering.<br />
<br />
FEA. 2001. "Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001." Available at [https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf].<br />
<br />
Friedman, G. and A.P. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." ''Systems Engineering,'' 7(1): 84-96. <br />
<br />
Hall, A.D. 1989. ''"Metasystems Methodology: A New Synthesis and Unification."'' International series on systems science and engineering. 1st ed. Vol. 3. Oxford, UK: Pergamon Press. <br />
<br />
Hitchins, D. 1993. ''"Putting Systems to Work."'' New York, NY, USA: John Wiley & Sons. <br />
<br />
ISO/IEC 158288. 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
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. <br />
<br />
MITRE. 2004. "MITRE 2004 Annual Report." McLean, VA, USA: MITRE Corporation. <br />
<br />
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. <br />
<br />
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.<br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Sage, A P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf/ Accessed September 7, 2011.<br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
Urbaczewski, L. and S. Mrdalj. 2006. "A Comparison of Enterprise Architecture Frameworks." ''Issues in Information Systems.'' 7(2):18-26.<br />
<br />
US Treasury. 2000. ''Treasury Enterprise Architecture Framework.,'' version 1. Washington, DC, USA: US Department of the Treasury Chief Information Officer Council. July 2000.<br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal,'' 26(3): 276-92.<br />
<br />
===Primary References===<br />
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. <br />
<br />
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.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “[[An Enterprise Systems Engineering Model]].” INCOSE Symposium Proceedings.<br />
<br />
===Additional References===<br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture.'' https://www.aogea.org/journal.<br />
<br />
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.<br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available at: http://trak.sourceforge.net/index.html.<br />
<br />
Vernadat, F.B. 1996. ''Enterprise Modelling and Integration - Principles and Applications.'' London, UK: Chapman and Hall. <br />
----<br />
<center>[[Related Business Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Process Activities|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=46914
Enterprise Systems Engineering Key Concepts
2012-11-28T21:13:59Z
<p>Janthony: /* Closing the Gap */</p>
<hr />
<div>The purpose of traditional systems engineering (TSE) is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[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 [[organization (glossary)|organization]] where information-intensive systems are becoming central elements of the organization’s [[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 [[context (glossary)|context]] of government [[acquisition (glossary)|acquisition]] of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control systems).<br />
<br />
ESE encompasses this traditional role in system acquisition, but also incorporates [[enterprise (glossary)|enterprise]] strategic [[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).<br />
<br />
==Closing the Gap==<br />
ESE practices have undergone significant development recently.<br />
<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
<br />
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 [[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:<br />
*strategic technical planning,<br />
*enterprise architecture,<br />
*capabilities-based planning analysis,<br />
*technology planning, and<br />
*enterprise analysis and assessment.<br />
<br />
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 15288 standard (2008).<br />
<br />
[[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.]]<br />
<br />
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)|project]]. In MITRE, this restricted definition was referred to as TSE. Many have taken a wider view seeking to apply SE to the “whole system” and “whole [[Life Cycle (glossary)|life cycle]].” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on [[operational (glossary)|operational]] purpose. Elliott and Deasley (2007) discuss the differences between development phase SE and in-service SE.<br />
<br />
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 [[portfolio (glossary)|portfolio]]. 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 a work by Rebovich and White (2011).<br />
<br />
==Role of Requirements in ESE==<br />
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).<br />
<br />
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)|governance]] priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:<br />
<br />
<BLOCKQUOTE><br />
“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.” (Swarz et al. 2006) (See also [[Complexity]])<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
==Enterprise Entities and Relationships==<br />
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. <br />
<br />
:<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 [[Data Center (glossary)|data center]], data warehouse, and other such facilities and equipment used across one or more organizations.</I><br />
<br />
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).<br />
<br />
{|<br />
|+'''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.<br />
!Asset Domains<br />
!Concept Domains<br />
|-<br />
|Application and Software Domain<br />
Data Domain<br />
Document Domain<br />
Infrastructure and Hardware Domain<br />
IT Product Domain<br />
IT Service Domain<br />
Location Domain<br />
Organization Domain<br />
Product and Service Domain<br />
Services Portfolio Management Domain<br />
|Analysis Domain<br />
Financial Domain<br />
General Domain<br />
Information Domain<br />
IT Architecture Domain<br />
Knowledge and Skill Domain<br />
Market Domain<br />
Policy Domain<br />
Process Domain<br />
Resource Domain<br />
Strategy Domain<br />
Timeline Domain<br />
Transition Domain<br />
|}<br />
<br />
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.<br />
<br />
[[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.]]<br />
<br />
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 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.<br />
<br />
==Enterprise Architecture Frameworks & Methodologies==<br />
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 informal, based on more rigorous modeling tools and methods. ISO/IEC 42010 (2011) specifies how to create architecture descriptions. <br />
<br />
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 Architecture (glossary)|enterprise architecture]]. <br />
<br />
Urbaczewski and Mrdalj (2006) provide an overview and comparison of five prominent architectural frameworks, including:<br />
* the Zachman Framework for Enterprise Architecture (Zachman 1992), <br />
* the Department of Defense Architecture Framework (DoDAF) (DoD 2010), <br />
* the Federal Enterprise Architecture Framework (FEAF) (FEA 2001), <br />
* the Treasury Enterprise Architecture Framework (TEAF) (US Treasury 2000), <br />
* and The Open Group Architectural Framework (TOGAF) (TOGAF 2009).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Carlock, P. and R. Fenton. 2001. “System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations,” ''Systems Engineering, 4(4): 242-261.<br />
<br />
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.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
DoD. 2010. ''DoD Architecture Framework (DoDAF)'', version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Elliott, C. and P. Deasley. 2007. "Creating Systems that Work--Principles of Engineering Systems for the 21st Century." (17). London, England, UK: Royal Academy of Engineering.<br />
<br />
FEA. 2001. "Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001." Available at [https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf].<br />
<br />
Friedman, G. and A.P. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." ''Systems Engineering,'' 7(1): 84-96. <br />
<br />
Hall, A.D. 1989. ''"Metasystems Methodology: A New Synthesis and Unification."'' International series on systems science and engineering. 1st ed. Vol. 3. Oxford, UK: Pergamon Press. <br />
<br />
Hitchins, D. 1993. ''"Putting Systems to Work."'' New York, NY, USA: John Wiley & Sons. <br />
<br />
ISO/IEC 158288. 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
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. <br />
<br />
MITRE. 2004. "MITRE 2004 Annual Report." McLean, VA, USA: MITRE Corporation. <br />
<br />
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. <br />
<br />
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.<br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Sage, A P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf/ Accessed September 7, 2011.<br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
Urbaczewski, L. and S. Mrdalj. 2006. "A Comparison of Enterprise Architecture Frameworks." ''Issues in Information Systems.'' 7(2):18-26.<br />
<br />
US Treasury. 2000. ''Treasury Enterprise Architecture Framework.,'' version 1. Washington, DC, USA: US Department of the Treasury Chief Information Officer Council. July 2000.<br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal,'' 26(3): 276-92.<br />
<br />
===Primary References===<br />
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. <br />
<br />
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.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “[[An Enterprise Systems Engineering Model]].” INCOSE Symposium Proceedings.<br />
<br />
===Additional References===<br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture.'' https://www.aogea.org/journal.<br />
<br />
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.<br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available at: http://trak.sourceforge.net/index.html.<br />
<br />
Vernadat, F.B. 1996. ''Enterprise Modelling and Integration - Principles and Applications.'' London, UK: Chapman and Hall. <br />
----<br />
<center>[[Related Business Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Process Activities|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=46913
Related Business Activities
2012-11-28T21:13:22Z
<p>Janthony: /* Multi-Level Enterprises */</p>
<hr />
<div><br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) activities:<br />
*mission and strategic planning,<br />
*business processes and information Management,<br />
*performance management,<br />
*portfolio management,<br />
*resource allocation and budgeting, and<br />
*program and project management.<br />
<br />
==Introduction==<br />
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product systems engineering (PSE) (Martin 2010 and 2011). PSE is mainly involved at the project level and collaborates with project management activities, and gets somewhat involved in program management and the resource allocation and budgeting activities. On the other hand, ESE is heavily involved in the higher level activities from the program management level and up. Both ESE and PSE have key roles to play in the enterprise.<br />
<br />
[[File:ESE-F09.png|thumb|center|600px|'''Figure 1. Related Business Activities (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Shown in this manner, these business activities can be considered to be separate processes with a clear precedence in terms of which process drives other processes. TSE uses “[[Requirement (glossary)|requirements]]” to specify the essential features and functions of a system. An [[Enterprise (glossary)|enterprise]], on the other hand, typically uses goals and objectives to specify the fundamental characteristics of desired enterprise operational capabilities. The enterprise objectives and strategies are used in [[Portfolio Management (glossary)|portfolio management]] to discriminate between options and to select the appropriate balanced [[Portfolio (glossary)|portfolio]] of systems and other enterprise resources.<br />
<br />
The first three activities listed above are covered in [[Enabling Businesses and Enterprises]]. The other business management activities are described in more detail below in regards to how they relate to ESE.<br />
<br />
==Business Management Cycles==<br />
PDCA stands for "plan-do-check-act" and is a commonly used iterative management process as seen in the figure below. It is also known as the Deming circle or the Shewhart cycle after its two key proponents (Deming 1986; Shewhart 1939). ESE should use the PDCA cycle as one of its fundamental tenets. For example, after ESE develops the enterprise transformation plan, execution of the planned improvements are monitored (i.e., “checked” in the PDCA cycle) to ensure they achieve the targeted performance levels. If not, then action needs to be taken (i.e., “act” in the PDCA cycle) to correct the situation and re-planning may be required. ESE can also use the PDCA cycle in its support of the 'business as usual' efforts, such as the annual budgeting and business development planning activities.<br />
<br />
[[File:ESE-F10.png|thumb|250px|center|'''Figure 2. PDCA Cycle.''' (Source: http://en.wikipedia.org/wiki/PDCA. Accessed July 2010 from the Public Domain. Diagram by Karn G. Bulsuk (http://blog.bulsuk.com))]]<br />
<br />
It is also worth mentioning the utility of using Boyd's OODA loop (observe, orient, decide, and act) to augment PDCA. This could be accomplished by first using the OODA loop (http://en.wikipedia.org/wiki/OODA_loop), which is continuous in situation awareness, and then followed by using the PDCA approach, which is discrete, having goals, resources, usually time limits, etc. (Lawson 2010).<br />
<br />
==Portfolio Management==<br />
[[Program (glossary)| Program]] and [[Project (glossary)|project]] managers direct their activities as they relate to the systems under their control. Enterprise management, on the other hand, is involved in directing the portfolio of items that are necessary to achieving the enterprise goals and objectives. This can be accomplished by using Portfolio Management:<br />
<br />
<BLOCKQUOTE><br />
''Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals―while honoring constraints imposed by customers, strategic objectives, or external real-world factors.'' (http://en.wikipedia.org/wiki/Project_portfolio_management)</BLOCKQUOTE><br />
<br />
The enterprise may not actually own these portfolio items. They could rent or lease these items, or they could have permission to use them through licensing or assignment. The enterprise may only need part of a system (e.g., one bank of switching circuits in a system) or may need an entire [[System of Systems (SoS) (glossary)|system of systems]] (SoS) (e.g., switching systems, distribution systems, billing systems, provisioning systems, etc.). Notice that the portfolio items are not just those items related to the systems that [[Systems Engineering (glossary)|systems engineering]] (SE) deals with. These could also include platforms (like ships and oil drilling derricks), facilities (like warehouses and airports), land and rights of way (like railroad property easements and municipal covenants), and intellectual property (like patents and trademarks).<br />
<br />
The investment community has been using portfolio management for a long time to manage a set of investments to maximize return for a given level of acceptable [[risk (glossary)|risk]]. These techniques have also been applied to a portfolio of “projects” within the enterprise (Kaplan 2009). However, it should be noted that an enterprise is not merely a portfolio of projects. The enterprise portfolio consists of whatever systems, organizations, facilities, intellectual property, and other resources that are needed to help the enterprise achieve its goals and objectives.<br />
<br />
Portfolio management in the context of ESE is well addressed in the following article: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/enterprise_planning_management/portfolio_management.html (MITRE 2010).<br />
<br />
==Resource Allocation and Budgeting==<br />
The resource allocation and budgeting (RA&B) activity is driven by the portfolio management definition of the optimal set of portfolio elements. [[Capability (glossary)|Capability]] gaps are mapped to the elements of the portfolio, and resources are assigned to programs (or other organizational elements) based on the criticality of these gaps. Resources come in the form of people and facilities, policies and practices, money and energy, and platforms and infrastructure. Allocation of resources could also involve the distribution or assignment of corporate assets, like communication bandwidth, manufacturing floor space, computing power, intellectual property licenses, and so on. Resource allocation and budgeting is typically done on an annual basis, but more agile enterprises will make this a more continuous process. Some of the resource allocation decisions deal with base operational organizations that are not project related.<br />
<br />
It is sometimes the case that RA&B is part of portfolio management (PfM). But as can be seen in Figure 1, it is sometimes useful and practical to separate these two activities. PfM usually recommends changes to the enterprise portfolio, but RA&B takes these PfM considerations into mind along with inputs from the business process and information management and the performance management activities. Furthermore, PfM is usually an annual or biannual activity whereas RA&B is often done more frequently. RA&B may need to execute ''ad hoc'' when perturbations happen, such as funding cuts, schedule slips, performance targets missed, strategic goals changed, and so on.<br />
<br />
==Program and Project Management==<br />
Within the enterprise, TSE is typically applied inside a project to engineer a single system (or perhaps a small number of related systems). If there is a SoS or a large, [[complex (glossary)|complex]] individual system to be engineered, then this might be handled at the program level, but is sometimes handled at the project level, depending on the size and [[complexity (glossary)|complexity]] of the system of interest (See also [[Complexity]]). <br />
<br />
There are commonly three basic types of projects in an enterprise. A development project takes a conceptual notion of a system and turns this into a realizable design. A production project takes the realizable design for a system and turns this into physical copies (or instantiations). An operations “project” directly operates each system or supports the operation by others. (Base operations are sometimes called "line organizations" and are not typically called projects per se, but should nonetheless be considered as key elements to be considered when adjusting the enterprise portfolio.) The operations project can also be involved in maintaining the system or supporting maintenance by others. A program can have all three types of projects active simultaneously for the same system, as in this example:<br />
*Project A is developing System X version 3.<br />
*Project B is operating and maintaining System X version 2.<br />
*Project C is maintaining System X version 1 in a warehouse as a backup in case of emergencies.<br />
<br />
Project management uses TSE as a tool to ensure a well-structured project and to help identify and mitigate [[Cost (glossary)|cost]], schedule, and technical risks involved with system development and implementation. The project level is where the TSE process is most often employed (Martin 1997; ISO/IEC 2008; Wasson 2006; INCOSE 2010; Blanchard and Fabrycky 2010).<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
''The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this, a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.'' (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enterprise Governance==<br />
ESE is also concerned with the way in which organizations and embedded management and technical functions work together to achieve success at the enterprise level. Governance frameworks provide the essential additional structure and controls needed to both ‘steer a steady ship’ (during business as usual) and to ‘plot a course to a new place’ (during business transformation). <br />
<br />
Such frameworks can be designed by recognizing that there are enduring management concerns that need to be addressed and by applying the principle of economy. For example, a particular concern for most organizations is linking the control of projects to business drivers and objectives. This leads to a requirement for a governance body to both approve the initiation of projects, and to regularly review their progress, continuing relevance, and if necessary, mutual coherence in the light of developments inside and outside the enterprise. <br />
<br />
This might be achieved by delegating some or all of the roles; depending on circumstances, the enterprise might be driven towards top-down or a more collective, peer-to-peer approach—or even a combination of the two for different functions. Governance bodies and management roles can be engineered in this way against a common set of management concerns. Governance may also include the maintenance of common technical standards and their promulgation and use throughout relevant projects. See Bryant (2012) for more information on governance.<br />
<br />
==Multi-Level Enterprises==<br />
An enterprise does not always have full control over the ESE processes. In some cases, an enterprise may have no direct control over the resources necessary to make programs and projects successful. For example, the Internet Engineering Task Force (IETF) is responsible for the “smooth operation of the Internet,” yet it controls none of the requisite resources.<br />
<br />
<BLOCKQUOTE><br />
''The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. … The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year.'' (IETF 2010a)</BLOCKQUOTE><br />
<br />
The IETF has “influence” over these resources even though it does not have direct control: "The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues" (IETF 2010b).<br />
<br />
The ESE processes might be allocated between a “parent” enterprise and “children” enterprises, as shown in the figure below (Martin 2010). The parent enterprise, in this case, has no resources. These resources are owned by the subordinate child enterprises. Therefore, the parent enterprise does not implement the processes of resource allocation and budgeting, program management, and project management.<br />
<br />
The parent enterprise may have an explicit contract with the subordinate enterprises, or, as in some cases, there is merely a “working relationship” without the benefit of legal obligations. The parent enterprise will expect performance feedback from the lower level to ensure that it can meet its own objectives. Where the feedback indicates a deviation from the plan, the objectives can be adjusted or the portfolio is modified to compensate.<br />
<br />
[[File:ESE-F11.png|thumb|center|600px|'''Figure 3. Parent and Child Enterprise Relationships (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprises X, Y, and Z in the situation shown above will cooperate with each other to the extent that they honor the direction and guidance from the parent enterprise. These enterprises may not even be aware of each other, and, in this case, would be unwittingly cooperating with each other. The situation becomes more complex if each enterprise has its own set of strategic goals and objectives as shown in the figure below.<br />
<br />
[[File:ESE-F12.png|thumb|center|600px|'''Figure 4. Mission and Strategic Planning at All Levels of Cooperating Enterprises (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
These separate, sub-enterprise objectives will sometimes conflict with the objectives of the parent enterprise. Furthermore, each subordinate enterprise has its own strategic objectives that might conflict with those of its siblings. The situation shown here is not uncommon, and illustrates an enterprise of enterprises, so to speak. This highlights the need for the application of SE at the enterprise level to handle the complex interactions and understand the overall behavior of the enterprise as a whole. TSE practices can be used, to a certain extent, but these need to be expanded to incorporate additional tools and techniques.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Bryant, P., 2012. "Modelling Governance within Business Architecture using Topic Mapping." Paper presented at 22nd Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-12 July 2012, Rome, Italy.<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Deming, W.E. 1986. ''Out of the Crisis.'' Cambridge, MA, USA: MIT Press, MIT Center for Advance Engineering Study.<br />
<br />
IETF. 2010a. "Overview of the IETF." in Internet Engineering Task Force, Internet Society (ISOC) [database online]. 2010a Available from http://www.ietf.org/overview.html Accessed September 6, 2011. <br />
<br />
IETF. 2010b. "The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force (draft-hoffman-tao4677bix-10)". in Internet Engineering Task Force, Internet Society (ISOC) [database online]. http://www.ietf.org/tao.html#intro Accessed September 6, 2011. <br />
<br />
INCOSE. 2010. ''INCOSE systems engineering handbook, version 3.2.'' San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2. <br />
<br />
ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
Kaplan, J. 2009. ''Strategic IT portfolio management: Governing enterprise transformation.'' Waltham, Massachusetts,USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications<br />
<br />
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Paper presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
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.<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MITRE. 2012. "Enterprise Engineering." In ''Systems Engineering Guide.'' MITRE Corporation. http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Shewhart, W.A. 1939. ''Statistical Method from the Viewpoint of Quality Control.'' New York, NY, USA: Dover Publications.<br />
<br />
Wasson, C.S. 2006. ''System Analysis, Design and Development.'' Hoboken, NJ, USA: John Wiley and Sons Ltd.<br />
<br />
===Primary References===<br />
Martin, J.N. 2011. "[[Transforming the Enterprise Using a Systems Approach]]." Paper presented at 21st International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Paper presented at 20th International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA.<br />
<br />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Drucker, P.F. 1994. "The Theory of Business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Haeckel, S.H. 2003. "Leading on demand businesses–Executives as architects." ''IBM Systems Journal,'' 42(3): 405-13. <br />
<br />
Kaplan, R. and D. Norton. 1996. ''The balanced scorecard: Translating strategy into action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
Lissack, M.R. 2000. "Complexity Metaphors and the Management of a Knowledge Based Enterprise: An Exploration of Discovery." PhD Dissertation in Business Administration. Henley Management College. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
----<br />
<center>[[The Enterprise as a System|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Key Concepts|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=46912
Related Business Activities
2012-11-28T21:12:48Z
<p>Janthony: /* Program and Project Management */</p>
<hr />
<div><br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) activities:<br />
*mission and strategic planning,<br />
*business processes and information Management,<br />
*performance management,<br />
*portfolio management,<br />
*resource allocation and budgeting, and<br />
*program and project management.<br />
<br />
==Introduction==<br />
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product systems engineering (PSE) (Martin 2010 and 2011). PSE is mainly involved at the project level and collaborates with project management activities, and gets somewhat involved in program management and the resource allocation and budgeting activities. On the other hand, ESE is heavily involved in the higher level activities from the program management level and up. Both ESE and PSE have key roles to play in the enterprise.<br />
<br />
[[File:ESE-F09.png|thumb|center|600px|'''Figure 1. Related Business Activities (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Shown in this manner, these business activities can be considered to be separate processes with a clear precedence in terms of which process drives other processes. TSE uses “[[Requirement (glossary)|requirements]]” to specify the essential features and functions of a system. An [[Enterprise (glossary)|enterprise]], on the other hand, typically uses goals and objectives to specify the fundamental characteristics of desired enterprise operational capabilities. The enterprise objectives and strategies are used in [[Portfolio Management (glossary)|portfolio management]] to discriminate between options and to select the appropriate balanced [[Portfolio (glossary)|portfolio]] of systems and other enterprise resources.<br />
<br />
The first three activities listed above are covered in [[Enabling Businesses and Enterprises]]. The other business management activities are described in more detail below in regards to how they relate to ESE.<br />
<br />
==Business Management Cycles==<br />
PDCA stands for "plan-do-check-act" and is a commonly used iterative management process as seen in the figure below. It is also known as the Deming circle or the Shewhart cycle after its two key proponents (Deming 1986; Shewhart 1939). ESE should use the PDCA cycle as one of its fundamental tenets. For example, after ESE develops the enterprise transformation plan, execution of the planned improvements are monitored (i.e., “checked” in the PDCA cycle) to ensure they achieve the targeted performance levels. If not, then action needs to be taken (i.e., “act” in the PDCA cycle) to correct the situation and re-planning may be required. ESE can also use the PDCA cycle in its support of the 'business as usual' efforts, such as the annual budgeting and business development planning activities.<br />
<br />
[[File:ESE-F10.png|thumb|250px|center|'''Figure 2. PDCA Cycle.''' (Source: http://en.wikipedia.org/wiki/PDCA. Accessed July 2010 from the Public Domain. Diagram by Karn G. Bulsuk (http://blog.bulsuk.com))]]<br />
<br />
It is also worth mentioning the utility of using Boyd's OODA loop (observe, orient, decide, and act) to augment PDCA. This could be accomplished by first using the OODA loop (http://en.wikipedia.org/wiki/OODA_loop), which is continuous in situation awareness, and then followed by using the PDCA approach, which is discrete, having goals, resources, usually time limits, etc. (Lawson 2010).<br />
<br />
==Portfolio Management==<br />
[[Program (glossary)| Program]] and [[Project (glossary)|project]] managers direct their activities as they relate to the systems under their control. Enterprise management, on the other hand, is involved in directing the portfolio of items that are necessary to achieving the enterprise goals and objectives. This can be accomplished by using Portfolio Management:<br />
<br />
<BLOCKQUOTE><br />
''Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals―while honoring constraints imposed by customers, strategic objectives, or external real-world factors.'' (http://en.wikipedia.org/wiki/Project_portfolio_management)</BLOCKQUOTE><br />
<br />
The enterprise may not actually own these portfolio items. They could rent or lease these items, or they could have permission to use them through licensing or assignment. The enterprise may only need part of a system (e.g., one bank of switching circuits in a system) or may need an entire [[System of Systems (SoS) (glossary)|system of systems]] (SoS) (e.g., switching systems, distribution systems, billing systems, provisioning systems, etc.). Notice that the portfolio items are not just those items related to the systems that [[Systems Engineering (glossary)|systems engineering]] (SE) deals with. These could also include platforms (like ships and oil drilling derricks), facilities (like warehouses and airports), land and rights of way (like railroad property easements and municipal covenants), and intellectual property (like patents and trademarks).<br />
<br />
The investment community has been using portfolio management for a long time to manage a set of investments to maximize return for a given level of acceptable [[risk (glossary)|risk]]. These techniques have also been applied to a portfolio of “projects” within the enterprise (Kaplan 2009). However, it should be noted that an enterprise is not merely a portfolio of projects. The enterprise portfolio consists of whatever systems, organizations, facilities, intellectual property, and other resources that are needed to help the enterprise achieve its goals and objectives.<br />
<br />
Portfolio management in the context of ESE is well addressed in the following article: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/enterprise_planning_management/portfolio_management.html (MITRE 2010).<br />
<br />
==Resource Allocation and Budgeting==<br />
The resource allocation and budgeting (RA&B) activity is driven by the portfolio management definition of the optimal set of portfolio elements. [[Capability (glossary)|Capability]] gaps are mapped to the elements of the portfolio, and resources are assigned to programs (or other organizational elements) based on the criticality of these gaps. Resources come in the form of people and facilities, policies and practices, money and energy, and platforms and infrastructure. Allocation of resources could also involve the distribution or assignment of corporate assets, like communication bandwidth, manufacturing floor space, computing power, intellectual property licenses, and so on. Resource allocation and budgeting is typically done on an annual basis, but more agile enterprises will make this a more continuous process. Some of the resource allocation decisions deal with base operational organizations that are not project related.<br />
<br />
It is sometimes the case that RA&B is part of portfolio management (PfM). But as can be seen in Figure 1, it is sometimes useful and practical to separate these two activities. PfM usually recommends changes to the enterprise portfolio, but RA&B takes these PfM considerations into mind along with inputs from the business process and information management and the performance management activities. Furthermore, PfM is usually an annual or biannual activity whereas RA&B is often done more frequently. RA&B may need to execute ''ad hoc'' when perturbations happen, such as funding cuts, schedule slips, performance targets missed, strategic goals changed, and so on.<br />
<br />
==Program and Project Management==<br />
Within the enterprise, TSE is typically applied inside a project to engineer a single system (or perhaps a small number of related systems). If there is a SoS or a large, [[complex (glossary)|complex]] individual system to be engineered, then this might be handled at the program level, but is sometimes handled at the project level, depending on the size and [[complexity (glossary)|complexity]] of the system of interest (See also [[Complexity]]). <br />
<br />
There are commonly three basic types of projects in an enterprise. A development project takes a conceptual notion of a system and turns this into a realizable design. A production project takes the realizable design for a system and turns this into physical copies (or instantiations). An operations “project” directly operates each system or supports the operation by others. (Base operations are sometimes called "line organizations" and are not typically called projects per se, but should nonetheless be considered as key elements to be considered when adjusting the enterprise portfolio.) The operations project can also be involved in maintaining the system or supporting maintenance by others. A program can have all three types of projects active simultaneously for the same system, as in this example:<br />
*Project A is developing System X version 3.<br />
*Project B is operating and maintaining System X version 2.<br />
*Project C is maintaining System X version 1 in a warehouse as a backup in case of emergencies.<br />
<br />
Project management uses TSE as a tool to ensure a well-structured project and to help identify and mitigate [[Cost (glossary)|cost]], schedule, and technical risks involved with system development and implementation. The project level is where the TSE process is most often employed (Martin 1997; ISO/IEC 2008; Wasson 2006; INCOSE 2010; Blanchard and Fabrycky 2010).<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
''The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this, a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.'' (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enterprise Governance==<br />
ESE is also concerned with the way in which organizations and embedded management and technical functions work together to achieve success at the enterprise level. Governance frameworks provide the essential additional structure and controls needed to both ‘steer a steady ship’ (during business as usual) and to ‘plot a course to a new place’ (during business transformation). <br />
<br />
Such frameworks can be designed by recognizing that there are enduring management concerns that need to be addressed and by applying the principle of economy. For example, a particular concern for most organizations is linking the control of projects to business drivers and objectives. This leads to a requirement for a governance body to both approve the initiation of projects, and to regularly review their progress, continuing relevance, and if necessary, mutual coherence in the light of developments inside and outside the enterprise. <br />
<br />
This might be achieved by delegating some or all of the roles; depending on circumstances, the enterprise might be driven towards top-down or a more collective, peer-to-peer approach—or even a combination of the two for different functions. Governance bodies and management roles can be engineered in this way against a common set of management concerns. Governance may also include the maintenance of common technical standards and their promulgation and use throughout relevant projects. See Bryant (2012) for more information on governance.<br />
<br />
==Multi-Level Enterprises==<br />
An enterprise does not always have full control over the ESE processes. In some cases, an enterprise may have no direct control over the resources necessary to make programs and projects successful. For example, the Internet Engineering Task Force (IETF) is responsible for the “smooth operation of the Internet,” yet it controls none of the requisite resources.<br />
<br />
<BLOCKQUOTE><br />
“The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. … The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year.” (IETF 2010a)</BLOCKQUOTE><br />
<br />
The IETF has “influence” over these resources even though it does not have direct control: "The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues" (IETF 2010b).<br />
<br />
The ESE processes might be allocated between a “parent” enterprise and “children” enterprises, as shown in the figure below (Martin 2010). The parent enterprise, in this case, has no resources. These resources are owned by the subordinate child enterprises. Therefore, the parent enterprise does not implement the processes of resource allocation and budgeting, program management, and project management.<br />
<br />
The parent enterprise may have an explicit contract with the subordinate enterprises, or, as in some cases, there is merely a “working relationship” without the benefit of legal obligations. The parent enterprise will expect performance feedback from the lower level to ensure that it can meet its own objectives. Where the feedback indicates a deviation from the plan, the objectives can be adjusted or the portfolio is modified to compensate.<br />
<br />
[[File:ESE-F11.png|thumb|center|600px|'''Figure 3. Parent and Child Enterprise Relationships (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprises X, Y, and Z in the situation shown above will cooperate with each other to the extent that they honor the direction and guidance from the parent enterprise. These enterprises may not even be aware of each other, and, in this case, would be unwittingly cooperating with each other. The situation becomes more complex if each enterprise has its own set of strategic goals and objectives as shown in the figure below.<br />
<br />
[[File:ESE-F12.png|thumb|center|600px|'''Figure 4. Mission and Strategic Planning at All Levels of Cooperating Enterprises (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
These separate, sub-enterprise objectives will sometimes conflict with the objectives of the parent enterprise. Furthermore, each subordinate enterprise has its own strategic objectives that might conflict with those of its siblings. The situation shown here is not uncommon, and illustrates an enterprise of enterprises, so to speak. This highlights the need for the application of SE at the enterprise level to handle the complex interactions and understand the overall behavior of the enterprise as a whole. TSE practices can be used, to a certain extent, but these need to be expanded to incorporate additional tools and techniques.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Bryant, P., 2012. "Modelling Governance within Business Architecture using Topic Mapping." Paper presented at 22nd Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-12 July 2012, Rome, Italy.<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Deming, W.E. 1986. ''Out of the Crisis.'' Cambridge, MA, USA: MIT Press, MIT Center for Advance Engineering Study.<br />
<br />
IETF. 2010a. "Overview of the IETF." in Internet Engineering Task Force, Internet Society (ISOC) [database online]. 2010a Available from http://www.ietf.org/overview.html Accessed September 6, 2011. <br />
<br />
IETF. 2010b. "The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force (draft-hoffman-tao4677bix-10)". in Internet Engineering Task Force, Internet Society (ISOC) [database online]. http://www.ietf.org/tao.html#intro Accessed September 6, 2011. <br />
<br />
INCOSE. 2010. ''INCOSE systems engineering handbook, version 3.2.'' San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2. <br />
<br />
ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
Kaplan, J. 2009. ''Strategic IT portfolio management: Governing enterprise transformation.'' Waltham, Massachusetts,USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications<br />
<br />
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Paper presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
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.<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MITRE. 2012. "Enterprise Engineering." In ''Systems Engineering Guide.'' MITRE Corporation. http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Shewhart, W.A. 1939. ''Statistical Method from the Viewpoint of Quality Control.'' New York, NY, USA: Dover Publications.<br />
<br />
Wasson, C.S. 2006. ''System Analysis, Design and Development.'' Hoboken, NJ, USA: John Wiley and Sons Ltd.<br />
<br />
===Primary References===<br />
Martin, J.N. 2011. "[[Transforming the Enterprise Using a Systems Approach]]." Paper presented at 21st International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Paper presented at 20th International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA.<br />
<br />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Drucker, P.F. 1994. "The Theory of Business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Haeckel, S.H. 2003. "Leading on demand businesses–Executives as architects." ''IBM Systems Journal,'' 42(3): 405-13. <br />
<br />
Kaplan, R. and D. Norton. 1996. ''The balanced scorecard: Translating strategy into action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
Lissack, M.R. 2000. "Complexity Metaphors and the Management of a Knowledge Based Enterprise: An Exploration of Discovery." PhD Dissertation in Business Administration. Henley Management College. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
----<br />
<center>[[The Enterprise as a System|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Key Concepts|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=46911
Related Business Activities
2012-11-28T21:10:51Z
<p>Janthony: /* Portfolio Management */</p>
<hr />
<div><br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) activities:<br />
*mission and strategic planning,<br />
*business processes and information Management,<br />
*performance management,<br />
*portfolio management,<br />
*resource allocation and budgeting, and<br />
*program and project management.<br />
<br />
==Introduction==<br />
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product systems engineering (PSE) (Martin 2010 and 2011). PSE is mainly involved at the project level and collaborates with project management activities, and gets somewhat involved in program management and the resource allocation and budgeting activities. On the other hand, ESE is heavily involved in the higher level activities from the program management level and up. Both ESE and PSE have key roles to play in the enterprise.<br />
<br />
[[File:ESE-F09.png|thumb|center|600px|'''Figure 1. Related Business Activities (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Shown in this manner, these business activities can be considered to be separate processes with a clear precedence in terms of which process drives other processes. TSE uses “[[Requirement (glossary)|requirements]]” to specify the essential features and functions of a system. An [[Enterprise (glossary)|enterprise]], on the other hand, typically uses goals and objectives to specify the fundamental characteristics of desired enterprise operational capabilities. The enterprise objectives and strategies are used in [[Portfolio Management (glossary)|portfolio management]] to discriminate between options and to select the appropriate balanced [[Portfolio (glossary)|portfolio]] of systems and other enterprise resources.<br />
<br />
The first three activities listed above are covered in [[Enabling Businesses and Enterprises]]. The other business management activities are described in more detail below in regards to how they relate to ESE.<br />
<br />
==Business Management Cycles==<br />
PDCA stands for "plan-do-check-act" and is a commonly used iterative management process as seen in the figure below. It is also known as the Deming circle or the Shewhart cycle after its two key proponents (Deming 1986; Shewhart 1939). ESE should use the PDCA cycle as one of its fundamental tenets. For example, after ESE develops the enterprise transformation plan, execution of the planned improvements are monitored (i.e., “checked” in the PDCA cycle) to ensure they achieve the targeted performance levels. If not, then action needs to be taken (i.e., “act” in the PDCA cycle) to correct the situation and re-planning may be required. ESE can also use the PDCA cycle in its support of the 'business as usual' efforts, such as the annual budgeting and business development planning activities.<br />
<br />
[[File:ESE-F10.png|thumb|250px|center|'''Figure 2. PDCA Cycle.''' (Source: http://en.wikipedia.org/wiki/PDCA. Accessed July 2010 from the Public Domain. Diagram by Karn G. Bulsuk (http://blog.bulsuk.com))]]<br />
<br />
It is also worth mentioning the utility of using Boyd's OODA loop (observe, orient, decide, and act) to augment PDCA. This could be accomplished by first using the OODA loop (http://en.wikipedia.org/wiki/OODA_loop), which is continuous in situation awareness, and then followed by using the PDCA approach, which is discrete, having goals, resources, usually time limits, etc. (Lawson 2010).<br />
<br />
==Portfolio Management==<br />
[[Program (glossary)| Program]] and [[Project (glossary)|project]] managers direct their activities as they relate to the systems under their control. Enterprise management, on the other hand, is involved in directing the portfolio of items that are necessary to achieving the enterprise goals and objectives. This can be accomplished by using Portfolio Management:<br />
<br />
<BLOCKQUOTE><br />
''Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals―while honoring constraints imposed by customers, strategic objectives, or external real-world factors.'' (http://en.wikipedia.org/wiki/Project_portfolio_management)</BLOCKQUOTE><br />
<br />
The enterprise may not actually own these portfolio items. They could rent or lease these items, or they could have permission to use them through licensing or assignment. The enterprise may only need part of a system (e.g., one bank of switching circuits in a system) or may need an entire [[System of Systems (SoS) (glossary)|system of systems]] (SoS) (e.g., switching systems, distribution systems, billing systems, provisioning systems, etc.). Notice that the portfolio items are not just those items related to the systems that [[Systems Engineering (glossary)|systems engineering]] (SE) deals with. These could also include platforms (like ships and oil drilling derricks), facilities (like warehouses and airports), land and rights of way (like railroad property easements and municipal covenants), and intellectual property (like patents and trademarks).<br />
<br />
The investment community has been using portfolio management for a long time to manage a set of investments to maximize return for a given level of acceptable [[risk (glossary)|risk]]. These techniques have also been applied to a portfolio of “projects” within the enterprise (Kaplan 2009). However, it should be noted that an enterprise is not merely a portfolio of projects. The enterprise portfolio consists of whatever systems, organizations, facilities, intellectual property, and other resources that are needed to help the enterprise achieve its goals and objectives.<br />
<br />
Portfolio management in the context of ESE is well addressed in the following article: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/enterprise_planning_management/portfolio_management.html (MITRE 2010).<br />
<br />
==Resource Allocation and Budgeting==<br />
The resource allocation and budgeting (RA&B) activity is driven by the portfolio management definition of the optimal set of portfolio elements. [[Capability (glossary)|Capability]] gaps are mapped to the elements of the portfolio, and resources are assigned to programs (or other organizational elements) based on the criticality of these gaps. Resources come in the form of people and facilities, policies and practices, money and energy, and platforms and infrastructure. Allocation of resources could also involve the distribution or assignment of corporate assets, like communication bandwidth, manufacturing floor space, computing power, intellectual property licenses, and so on. Resource allocation and budgeting is typically done on an annual basis, but more agile enterprises will make this a more continuous process. Some of the resource allocation decisions deal with base operational organizations that are not project related.<br />
<br />
It is sometimes the case that RA&B is part of portfolio management (PfM). But as can be seen in Figure 1, it is sometimes useful and practical to separate these two activities. PfM usually recommends changes to the enterprise portfolio, but RA&B takes these PfM considerations into mind along with inputs from the business process and information management and the performance management activities. Furthermore, PfM is usually an annual or biannual activity whereas RA&B is often done more frequently. RA&B may need to execute ''ad hoc'' when perturbations happen, such as funding cuts, schedule slips, performance targets missed, strategic goals changed, and so on.<br />
<br />
==Program and Project Management==<br />
Within the enterprise, TSE is typically applied inside a project to engineer a single system (or perhaps a small number of related systems). If there is a SoS or a large, [[complex (glossary)|complex]] individual system to be engineered, then this might be handled at the program level, but is sometimes handled at the project level, depending on the size and [[complexity (glossary)|complexity]] of the system of interest (See also [[Complexity]]). <br />
<br />
There are commonly three basic types of projects in an enterprise. A development project takes a conceptual notion of a system and turns this into a realizable design. A production project takes the realizable design for a system and turns this into physical copies (or instantiations). An operations “project” directly operates each system or supports the operation by others. (Base operations are sometimes called "line organizations" and are not typically called projects per se, but should nonetheless be considered as key elements to be considered when adjusting the enterprise portfolio.) The operations project can also be involved in maintaining the system or supporting maintenance by others. A program can have all three types of projects active simultaneously for the same system, as in this example:<br />
*Project A is developing System X version 3.<br />
*Project B is operating and maintaining System X version 2.<br />
*Project C is maintaining System X version 1 in a warehouse as a backup in case of emergencies.<br />
<br />
Project management uses TSE as a tool to ensure a well-structured project and to help identify and mitigate [[Cost (glossary)|cost]], schedule, and technical risks involved with system development and implementation. The project level is where the TSE process is most often employed (Martin 1997; ISO/IEC 15288 2008; Wasson 2006; INCOSE 2010; Blanchard and Fabrycky 2010).<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
"The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this, a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives..."<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
"A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters." (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enterprise Governance==<br />
ESE is also concerned with the way in which organizations and embedded management and technical functions work together to achieve success at the enterprise level. Governance frameworks provide the essential additional structure and controls needed to both ‘steer a steady ship’ (during business as usual) and to ‘plot a course to a new place’ (during business transformation). <br />
<br />
Such frameworks can be designed by recognizing that there are enduring management concerns that need to be addressed and by applying the principle of economy. For example, a particular concern for most organizations is linking the control of projects to business drivers and objectives. This leads to a requirement for a governance body to both approve the initiation of projects, and to regularly review their progress, continuing relevance, and if necessary, mutual coherence in the light of developments inside and outside the enterprise. <br />
<br />
This might be achieved by delegating some or all of the roles; depending on circumstances, the enterprise might be driven towards top-down or a more collective, peer-to-peer approach—or even a combination of the two for different functions. Governance bodies and management roles can be engineered in this way against a common set of management concerns. Governance may also include the maintenance of common technical standards and their promulgation and use throughout relevant projects. See Bryant (2012) for more information on governance.<br />
<br />
==Multi-Level Enterprises==<br />
An enterprise does not always have full control over the ESE processes. In some cases, an enterprise may have no direct control over the resources necessary to make programs and projects successful. For example, the Internet Engineering Task Force (IETF) is responsible for the “smooth operation of the Internet,” yet it controls none of the requisite resources.<br />
<br />
<BLOCKQUOTE><br />
“The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. … The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year.” (IETF 2010a)</BLOCKQUOTE><br />
<br />
The IETF has “influence” over these resources even though it does not have direct control: "The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues" (IETF 2010b).<br />
<br />
The ESE processes might be allocated between a “parent” enterprise and “children” enterprises, as shown in the figure below (Martin 2010). The parent enterprise, in this case, has no resources. These resources are owned by the subordinate child enterprises. Therefore, the parent enterprise does not implement the processes of resource allocation and budgeting, program management, and project management.<br />
<br />
The parent enterprise may have an explicit contract with the subordinate enterprises, or, as in some cases, there is merely a “working relationship” without the benefit of legal obligations. The parent enterprise will expect performance feedback from the lower level to ensure that it can meet its own objectives. Where the feedback indicates a deviation from the plan, the objectives can be adjusted or the portfolio is modified to compensate.<br />
<br />
[[File:ESE-F11.png|thumb|center|600px|'''Figure 3. Parent and Child Enterprise Relationships (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprises X, Y, and Z in the situation shown above will cooperate with each other to the extent that they honor the direction and guidance from the parent enterprise. These enterprises may not even be aware of each other, and, in this case, would be unwittingly cooperating with each other. The situation becomes more complex if each enterprise has its own set of strategic goals and objectives as shown in the figure below.<br />
<br />
[[File:ESE-F12.png|thumb|center|600px|'''Figure 4. Mission and Strategic Planning at All Levels of Cooperating Enterprises (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
These separate, sub-enterprise objectives will sometimes conflict with the objectives of the parent enterprise. Furthermore, each subordinate enterprise has its own strategic objectives that might conflict with those of its siblings. The situation shown here is not uncommon, and illustrates an enterprise of enterprises, so to speak. This highlights the need for the application of SE at the enterprise level to handle the complex interactions and understand the overall behavior of the enterprise as a whole. TSE practices can be used, to a certain extent, but these need to be expanded to incorporate additional tools and techniques.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Bryant, P., 2012. "Modelling Governance within Business Architecture using Topic Mapping." Paper presented at 22nd Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-12 July 2012, Rome, Italy.<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Deming, W.E. 1986. ''Out of the Crisis.'' Cambridge, MA, USA: MIT Press, MIT Center for Advance Engineering Study.<br />
<br />
IETF. 2010a. "Overview of the IETF." in Internet Engineering Task Force, Internet Society (ISOC) [database online]. 2010a Available from http://www.ietf.org/overview.html Accessed September 6, 2011. <br />
<br />
IETF. 2010b. "The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force (draft-hoffman-tao4677bix-10)". in Internet Engineering Task Force, Internet Society (ISOC) [database online]. http://www.ietf.org/tao.html#intro Accessed September 6, 2011. <br />
<br />
INCOSE. 2010. ''INCOSE systems engineering handbook, version 3.2.'' San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2. <br />
<br />
ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
Kaplan, J. 2009. ''Strategic IT portfolio management: Governing enterprise transformation.'' Waltham, Massachusetts,USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications<br />
<br />
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Paper presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
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.<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MITRE. 2012. "Enterprise Engineering." In ''Systems Engineering Guide.'' MITRE Corporation. http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Shewhart, W.A. 1939. ''Statistical Method from the Viewpoint of Quality Control.'' New York, NY, USA: Dover Publications.<br />
<br />
Wasson, C.S. 2006. ''System Analysis, Design and Development.'' Hoboken, NJ, USA: John Wiley and Sons Ltd.<br />
<br />
===Primary References===<br />
Martin, J.N. 2011. "[[Transforming the Enterprise Using a Systems Approach]]." Paper presented at 21st International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Paper presented at 20th International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA.<br />
<br />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Drucker, P.F. 1994. "The Theory of Business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Haeckel, S.H. 2003. "Leading on demand businesses–Executives as architects." ''IBM Systems Journal,'' 42(3): 405-13. <br />
<br />
Kaplan, R. and D. Norton. 1996. ''The balanced scorecard: Translating strategy into action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
Lissack, M.R. 2000. "Complexity Metaphors and the Management of a Knowledge Based Enterprise: An Exploration of Discovery." PhD Dissertation in Business Administration. Henley Management College. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
----<br />
<center>[[The Enterprise as a System|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Key Concepts|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=The_Enterprise_as_a_System&diff=46910
The Enterprise as a System
2012-11-28T21:09:21Z
<p>Janthony: </p>
<hr />
<div>To enable more efficient and effective [[enterprise (glossary)]] transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than as a collection of functions connected solely by information systems and shared facilities (Rouse 2005 and 2009; Lawson 2010). What distinguishes the [[design (glossary)]] of enterprise systems from product systems is the inclusion of people as a [[component (glossary)]] of the system, not merely as a [[user (glossary)|user]]/operator of the system. <br />
<br />
<blockquote>''The term 'enterprise system' has taken on a narrow meaning of only the information system an organization uses. Research and [[Project (glossary)|project]] experience has taught us that to design a good enterprise system, we need to adopt a much broader understanding of enterprise systems. The greater view of enterprise systems is inclusive of the [[Process (glossary)|processes]] the system supports, the people who work in the system, and the information [and knowledge] content of the system.'' (Giachetti 2010) </blockquote><br />
<br />
It is worth noting that the concept of "service" systems also includes people in the system. The thoughts above do not take this into account, primarily since their perspectives come mainly from a product system experience. The practice of service systems engineering is relatively new and is an emerging discipline. For more information on this, see the articles on [[Service Systems Engineering]].<br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process. These elements in the enterprise can be treated as a "system" and the processes, methods, and tools ESE can be applied.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 1). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 1. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs, and Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
''The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...''<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
''A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.'' (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enabling the Enterprise==<br />
ESE, by virtue of its inherent trans-disciplinarity (Sage 2000, 158-169) in dealing with problems that are large in scale and scope, can better enable the enterprise to become more effective and efficient. The [[Complex (glossary)|complex]] nature of many enterprise problems and situations usually goes beyond the abilities of standard tools and techniques provided to business school graduates (See also [[Complexity]]). ESE can augment the standard business management methods using the tools and methods from the SE discipline to more robustly analyze and evaluate the enterprise as a holistic system. A more general viewpoint, or “view,” for dealing with the enterprise consisting of scale, granularity, mindset, and time frame is provided by White (2007) and by McCarter and White (2009, 71-105).<br />
<br />
ESE can provide the enablers to address the concerns of enterprise executives as shown in Table 1 (Rouse 2009). The methods for dealing with, and the special characteristics of, complex adaptive systems must be properly considered when adapting traditional systems engineering (TSE) practices for use at the enterprise level—many of which come out of the systems science and systems thinking domains (von Bertalanffy 1968; Weinberg and Weinberg 1988; Miller and Page 2007; Rouse 2008, 17-25). For an approach to [[Complex Adaptive System (CAS) (glossary)|complex adaptive systems (CAS)]] engineering, refer to White (2009, 1-16) and to McCarter and White (2009, 71-105).<br />
<br />
{|<br />
|+'''Table 1. Executive Concerns and SE Enablers (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.<br />
!Executive Concerns<br />
!SE Enablers<br />
|-<br />
|'''Identifying ends, means, and scope and candidate changes'''<br />
|System complexity analysis to compare "as is" and "to be" enterprises<br />
|-<br />
|'''Evaluating changes in terms of process behaviors and performance'''<br />
|Organizational simulation of process flows and relationships<br />
|-<br />
|'''Assessing economics in terms of investments, operating costs, and returns'''<br />
|Economic modeling in terms of cash flows, volatility, and options<br />
|-<br />
|'''Defining the new enterprise in terms of processes and their integration'''<br />
|Enterprise architecting in terms of workflow, processes, and levels of maturity<br />
|-<br />
|'''Designing a strategy to change the culture for selected changes'''<br />
|Organizational and cultural change via leadership, vision, strategy, and incentives<br />
|-<br />
|'''Developing transformation action plans in terms of what, when, and who'''<br />
|Implementation planning in terms of tasks, schedule, people, and information<br />
|}<br />
<br />
==Enterprise Engineering==<br />
Another distinction is that “enterprise [[design (glossary)|design]] does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly ''being designed''” (Giachetti 2010) [emphasis in original]. Giachetti calls this new discipline “enterprise engineering.” We consider the enterprise engineering set of practices to be equivalent to what we call [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) in this article. <br />
<br />
<BLOCKQUOTE><br />
''The body of knowledge for enterprise engineering is evolving under such titles as enterprise engineering, business engineering, and [[Enterprise Architecture (glossary)|enterprise architecture]]…. Many systems and software engineering principles are applicable to enterprise engineering, but enterprise engineering’s unique complexities require additional principles…. Enterprise engineering’s intent is to deliver a targeted level of enterprise performance in terms of shareholder value or customer satisfaction…. Enterprise engineering methods include modeling; simulation; total quality management; change management; and bottleneck, cost, workflow, and value-added analysis.'' (Joannou 2007)<br />
</BLOCKQUOTE><br />
<br />
==Supersystem Constructs==<br />
===System of Systems (SoS) ===<br />
The phrase "[[System of Systems (SoS) (glossary)|system of systems]]” (SoS) is commonly used, but there is no widespread agreement on its exact meaning, nor on how it can be distinguished from a conventional system. A system is generally understood to be a collection of elements that interact in such a manner that it exhibits behavior that the elements themselves cannot exhibit. Each element (or component) of the system can be regarded as a system in its own right. Therefore, the phrase “system of systems” can technically be used for any system and, as such, would be a superfluous term. However, the meaning of this phrase has been examined in detail by (Maier 1998, 267-284), and his definition has been adopted by some people (AFSAB 2005). Maier provides this definition:<br />
<br />
<BLOCKQUOTE><br />
A SoS is an assemblage of components which individually may be regarded as systems, and which possess two additional properties:<br />
*<B>Operational Independence of the Components:</B> If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own; and<br />
*<B>Managerial Independence of the Components:</B> The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems (Maier 1998, 267-284).<br />
</BLOCKQUOTE><br />
<br />
Maier goes on further saying that “the commonly cited characteristics of systems-of-systems ([[Complexity (glossary)|complexity]] of the component systems and geographic distribution) are not the appropriate taxonomic classifiers” (Maier 1998, 267-284). Four kinds of SoS have been defined (Dahmann, Lane, and Rebovich 2008).<br />
<br />
For further details on SoS, see the ''Systems Engineering Guide for SoS'' developed by the US Department of Defense (DoD) (DUS(AT) 2008). Also, see the [[Systems of Systems (SoS)]] knowledge area.<br />
<br />
===Federation of Systems (FoS)===<br />
Different from the SoS concept, but related to it in several ways, is the concept called “federation of systems” (FoS). This concept might apply when there is a very limited amount of centralized control and authority (Sage and Cuppan 2001, 325-345; Sage and Rouse 2009). Each system in an FoS is very strongly in control of its own destiny, but “chooses” to participate in the FOS for its own good and the good of the “country,” so to speak. It is a coalition of the willing. An FoS is generally characterized by significant autonomy, heterogeneity, and geographic distribution or dispersion (Krygiel 1999). Krygiel defined a taxonomy of systems showing the relationships among conventional systems, SoSs, and FOSs. <br />
<br />
This taxonomy has three dimensions: autonomy, heterogeneity, and dispersion. An FoS would have a larger value on each of these three dimensions than a non-federated SoS. An “Enterprise System,” as described above, could be considered to be an FoS if it rates highly on these three dimensions. However, it is possible for an enterprise to have components that are not highly autonomous, that are relatively homogeneous, and are geographically close together. Therefore, it would be incorrect to say that an enterprise is necessarily the same as an FoS.<br />
<br />
Dove points out that in order for a large enterprise to survive in the twenty-first century, it must be more [[Agile (glossary)|agile]] and [[Robustness (glossary)|robust]] (Dove 1999 and 2001). Handy (1992, 59-67) describes a federalist approach called “New Federalism” which identifies the need for structuring of [[Loose Coupling (glossary)|loosely coupled]] organizations to help them adapt to the rapid changes inherent in the Information Age. This leads to the need for virtual organizations where alliances can be quickly formed to handle the challenges of newly identified [[Threat (glossary)|threats]] and a rapidly changing marketplace (Handy 1995, 2-8). Handy sets out to define a number of federalist political principles that could be applicable to an FoS. Handy’s principles have been tailored to the domain of systems engineering (SE) and management by Sage and Cuppan (2001, 325-345):<br />
*Subsidiarity,<br />
*Interdependence,<br />
*Uniform and standardized way of doing business,<br />
*Separation of powers,<br />
*Dual citizenship, and<br />
*Scales of SE.<br />
<br />
===Scales of SE===<br />
According to Maier’s definition, not every enterprise would be called a SoS since the systems within the enterprise do not usually meet the criteria of operational and managerial independence. In fact, one of the key purposes of an enterprise is to explicitly establish operational dependence between systems that the enterprise owns and/or operates in order to maximize the efficiency and effectiveness of the enterprise as a whole. Therefore, it is more proper to treat an enterprise system and an SoS as different types of things, with different properties and characteristics. This distinction is illustrated in the figure below, where three corresponding categories of SE are shown (DeRosa 2005; Swarz et al. 2006).<br />
<br />
It is true that an enterprise can be treated as a system itself and is comprised of many systems within the enterprise, but this discussion will reserve the term SoS to those systems that meet the criteria of operational and managerial independence. This distinction was also used within the MITRE Corporation in their ESE Office (Rebovich and White 2011).<br />
<br />
[[File:ESE-F07.png|thumb|center|600px|'''Figure 2. Different Groupings and Patterns Revealed at Different Scales (DeRosa 2005).''' Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved. All other rights are reserved by the copyright owner.]]<br />
<br />
===Relationships between Enterprise and SoS===<br />
An enterprise may require a particular [[Operational Capability (glossary)|operational capability]] that is brought into being by connecting together a chain of systems that together achieve that [[Capability (glossary)|capability]]. Any one of these systems in the chain cannot by itself provide this capability. The desired capability is the emergent property of this chain of systems. This chain of systems is sometimes called an SoS. However, the enterprise that requires this capability rarely has direct control over all the systems necessary to provide this full capability. This situation is illustrated in the figure below (Martin 2010).<br />
<br />
[[File:ESE-F08.png|thumb|center|500px|'''Figure 3. Relationships Between an Enterprise and SoSs (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise E1 (in the example above) has full control over SoS2, but not full control over SoS1. TSE can be applied to the individual systems (S1, S2, …, S53) shown within each enterprise, but needs to be augmented with additional activities to handle SoS and enterprise kinds of issues.<br />
<br />
There is a general issue regarding dealing with enterprises in this situation: there are at least two enterprises related to any particular SoS. First, there is the enterprise of builders/developers comprising projects and programs, which have to be organized appropriately and adopt special types of architectural principles. Second, there is the enterprise of users (those who use the products and service provided by the first enterprise), which has to exercise its own sort of agility. How the first enterprise designs systems to allow the second to operate is the core issue.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
AFSAB. 2005. "Report on System-of-Systems Engineering for Air Force Capability Development." Washington, DC: U.S. Air Force Scientific Advisory Board (AFSAB), U.S. Air Force, SAB-TR-05-04.<br />
<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering''. November 2008.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Dove, R. 2001. ''Response Ability: The Language, Structure, and Culture of the Agile Organization.'' New York, NY, USA: John Wiley & Sons. <br />
<br />
Dove, R. 1999. "Knowledge Management, Response Ability, and the Agile Enterprise." in Paradigm Shift International [database online]. Questa, NM, USA. Available from http://www.parshift.com/docs/KmRaAeX.htm Accessed September 6, 2011.<br />
<br />
DUS(AT). 2008. ''Systems Engineering Guide for Systems of Systems, Version 1.0.'' Washington, D.C.: Deputy Under Secretary of Defense for Acquisition and Technology (DUS(AT))/U.S. Department of Defense (DoD) http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed September 6, 2011.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Handy, C. 1995. "Trust and the Virtual Organization." ''Harvard Business Review'' 73(3) (May-June): 2-8. <br />
<br />
Handy, C. 1992. "Balancing Corporate Power: A New Federalist Paper." ''Harvard Business Review 70'' (6) (November/December): 59-67.<br />
<br />
Joannou, P. 2007. "Enterprise, Systems, and Software — the Need for Integration." ''Computer'', IEEE, May 2007.<br />
<br />
Krygiel, A.J. 1999. "Behind the Wizard's Curtain: An Integration Environment for a System of Systems." Arlington, VA, USA: C4ISR Cooperative Research Program (CCRP).<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 1'' (4): 267-84.<br />
<br />
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.<br />
<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"ystems of systems engineering: Principles and applications.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105 <br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the enterprise as a system." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering,'' 38(1) (Spring 2008): 17-25. <br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation. ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE), 8(2): 138-50. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In eds. M. A. Somerville, D. Rappaport ''Transdiciplinarity: Recreating Integrated Knowledge.'' 158-169. Oxford, UK: EOLSS Publishers. <br />
<br />
Sage, A., and C. Cuppan. 2001. "On the Systems Engineering and Management of Systems of Systems and Federations of Systems." ''Information-Knowledge-Systems Management Journal,'' 2(4) (December 2001): 325-45.<br />
<br />
Sage, A.P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S. , J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings.<br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications.'' Revised ed. New York, NY: Braziller. <br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''General Principles of Systems Design.'' New York, NY: Dorset House Publishing Company. <br />
<br />
White, B. E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA.<br />
<br />
===Primary References===<br />
<br />
Giachetti, R.E. 2010. [[Design of Enterprise Systems: Theory, Architecture, and Methods]]. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Joannou, P. 2007. [[Enterprise, Systems, and Software—The Need for Integration]]. IEEE ''Computer'', May 2007.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE)'' 8(2): 138-50.<br />
<br />
===Additional References===<br />
<br />
Arnold, S. and H. Lawson. 2004. "Viewing Systems From a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Nightingale, D., and D. Rhodes. 2004. "Enterprise systems architecting: Emerging art and science within engineering systems." Paper presented at Engineering Systems Symposium, Massachusetts Institute of Technology (MIT), 29-31 March, 2004, Boston, MA, USA. <br />
<br />
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. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
Ring, J. 2004. "Intelligent Enterprises." INCOSE ''INSIGHT,'' 6(2) (January 2004). <br />
<br />
Ring, J. 2004. "Seeing an Enterprise as a System." 'INCOSE 'INSIGHT,'' 6(2) (January 2004). <br />
<br />
Valerdi, R., D. Nightingale, and C. Blackburn. 2009. "Enterprises as Systems: Context, Boundaries, and Practical Implications." ''Information-Knowledge-Systems Management Journal.'' 7(4) (December 2008): 377-99. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Background|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Related Business Activities|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Fundamentals_of_Services&diff=46909
Fundamentals of Services
2012-11-28T21:05:03Z
<p>Janthony: /* Service System Attributes */</p>
<hr />
<div>[[Service (glossary)|Services]] are activities that cause a transformation of the state of an entity (a person, product, [[Business (glossary)|business]], region, or nation) by mutually agreed terms between the service provider and the [[Customer (glossary)|customer]]. Individual services are relatively simple, although they may require customization and significant back-stage support (e.g., database, knowledge management, analysis, forecasting, etc.) to assure [[Quality (glossary)|quality]] and timely delivery. [[Product (glossary)|Product]] services are also relatively straightforward as product specifications, performance standards, quality control, installation guidelines, and maintenance procedures require good communication and understanding between providers and [[User (glossary)|users]]. Business services can be rather [[Complex (glossary)|complex]]; some may involve intensive negotiations, work [[Process (glossary)|process]] alignment, quality assurance, [[Team (glossary)|team]] collaboration, and service coproduction. Moreover, Chang (2010) states that: “Regional and National services are even more complex, as they may affect policy, custom regulations, export permits, local business practices, logistics, distribution, and other such issues" (see also [[Complexity]]).<br />
==Service Systems==<br />
The service and/or set of services developed and accessible to the customer (individual consumer or [[Enterprise (glossary)|enterprise]]) are enabled by a [[Service System (glossary)|service system]]. Service system [[Stakeholder (glossary)|stakeholders]] may interact to create a particular [[Service Value Chain (glossary)|service value chain]] to be delivered with a specific objective (Spohrer and Maglio 2010). Service system entities dynamically configure four types of resources: people, technology/[[Environment (glossary)|environment]] infrastructure, [[Organization (glossary)|organizations(glossary)]]/institutions, and shared information/symbolic knowledge. Service systems can be either formal or informal in nature. In the case of formal service systems, the interactions are contracted through service level agreements (SLA). Informal service systems can promise to reconfigure resources without a written contractual agreement; in the case of the emergency transports operations example discussed in the [[Service Systems Background]] article, there is no formal contractual agreement (i.e., SLA) between the user requesting the service and the agency providing the service other than a “promise” for a quick and efficient response. SLAs are written contracts between and among service system entities, as well as the legal [[System (glossary)|system]] for enforcing the contracts. The study of informal service systems contains the study of relationships (communications, interactions, and promises) between service systems and social systems, cultural norms and beliefs, as well as political systems that can maintain those relationships (Spohrer and Kwan 2008). The resources are either physical or non-physical and have rights or no rights. See Figure 1 below:<br />
<br />
[[File:SSE_FOS_Fig1_no_white_space.png|thumb|400px|center|'''Figure 1. Service System Resources (Spohrer 2011).''' Reprinted with permission of Dr. James C. Spohrer. All other rights are reserved by the copyright owner.]]<br />
<br />
==Service Value Chain==<br />
<br />
SLAs and policies specify the conditions under which services system entities reconfigure access rights to resources by mutually agreed [[Value (glossary)|value]] propositions. Current management frameworks typically focus on single service system entity interfaces. They neither use SLAs for managing the implementation and delivery of services nor do they recognize/support the fact that many services may be composed of lower-level services, involve third-party providers, and rely on possibly complex relationships and processes among participating businesses, information communications, and technologies (CoreGRID 2007). While SLAs are mapped to the respective customer requirements, policies are provider-specific means to express constraints and rules for their internal operations. These rules may be independent of any particular customer (Theilmann 2009). <br />
<br />
In service systems practice, we describe the service value chain in terms of links among the entities connected via the Network Centric operations of service systems. For instance, value could then be created and delivered in terms of [[E-Services (glossary)|e-services]], such as business-to-business (B2B), business to consumer (B2C), business to government (B2G), government-to-business (G2B), government-to-government (G2G), government-to-consumer (G2C), etc. The emerging service in this case interacts or “co-produces” with their customer via the World Wide Web as compared to the physical environment in which the traditional, or brick and mortar, service enterprises interact with their customers. <br />
<br />
The services sector requires information as input, involves the customer at the production/delivery stage, and employs mostly qualitative measures to assess its performance, i.e., technology-intensive services are “information-driven, customer centric, e-oriented, and productivity-focused" (Tien and Berg (2003); Hipel et al. 2007; Chesbrough 2011). Chang (2010) defines these features in this manner:<br />
<br />
*'''Information Driven:''' The creation, management, and sharing of information is crucial to the design, production, and delivery of services.<br />
*'''Customer Centric:''' Customers are generally the co-producer of the services, as in the case of self-service. Customers require a certain degree of self-adaptation or customization and customers must be satisfied with the rendered services.<br />
*'''E (electronics) Oriented:''' Services are becoming increasingly e-oriented. Thus, e-access, e-commerce, and e-customer management are crucial to [[E-Services (glossary)|e-services]].<br />
*'''Productivity Focused:''' Both efficiency and effectiveness are important in the design, delivery, and support of services.<br />
*'''Value Adding:''' Services need to provide some value for the target clients. For profit-seeking service companies, the value produced for customers assures the company's profitability. For non-profit service entities, the value produced for customers reinforces the quality of a service entity's policy.<br />
<br />
A service system is defined by its value co-creation chain in which stakeholders work in open collaboration to deliver consistently high quality service according to business goals, service goals, and customer goals. A value proposition can be viewed as a request from one service system to another to run an algorithm (the value proposition) from the perspectives of multiple stakeholders according to culturally determined value principles. The four primary stakeholder’s perspectives in regards to value are the customer, provider, authority, and the competitors. Figure 2 below depicts value calculations from multiple stakeholder perspectives.<br />
<br />
{|<br />
|+'''Table 1. Value Calculation from Different Stakeholders' Perspectives (Spohrer 2011).''' Reprinted with permission of Dr. James C. Spohrer. All other rights are reserved by the copyright owner.<br />
!Stakeholder Perspective (the players)<br />
!Measure Impacted<br />
!Pricing Decision<br />
!Basic Questions<br />
!Value Proposition Reasoning<br />
|-<br />
|1. Customer<br />
|Quality (Revenue)<br />
|Value Based<br />
|Should we? (offer it)<br />
|Model of customer: Do customers want it? Is there a market? How large? Growth rate?<br />
|-<br />
|2. Provider<br />
|Productivity (Profit, Mission, Continuous Improvement, Sustainability)<br />
|Cost Plus<br />
|Can we? (deliver it)<br />
|Model of self: Does it play to our strengths? Can we deliver it profitability to customers? Can we continue to improve?<br />
|-<br />
|3. Authority<br />
|Compliance (Taxes and Fines, Quality of Fire)<br />
|Regulated<br />
|May we? (offer and deliver it)<br />
|Model of authority: Is it legal? Does it compromise our integrity in any way? Does it create a moral hazard?<br />
|-<br />
|4. Competitor (Substitute)<br />
|Sustainable Innovation (Market Share)<br />
|Strategic<br />
|Will we? (invest to make it so)<br />
|Model of competitor: Does it put us ahead? Can we stay ahead? Does it differentiate us from the competition?<br />
|}<br />
<br />
From an engineering design point of view, the service and business goals are an entry point through which to analyze the business [[Architecture (glossary)|architectures]] (including organization and processes) needed, which in turn demand alignment between the [[Information Technology (glossary)|information technology]] (IT) [[Component (glossary)|components]] and technology architecture to achieve the goals. From a systems engineering perspective, the next step is to identify service system entities that could participate in the service delivery (people, organizations, technologies, processes, etc.).<br />
<br />
==Service System Entities==<br />
<br />
Spath and Fahnrich (2007) defined a service meta-model comprised of nine types of '''entities''': <br />
<br />
#'''Customers''': customer features, customer attitudes, and customer preferences;<br />
#'''Goals''': business goals, service goals, customer goals, and enterprise culture goals;<br />
#'''Inputs''': physical, human beings, information, knowledge, currency, and constraints;<br />
#'''Outputs''': physical, human beings, information, knowledge, currency, and waste;<br />
#'''Processes''': service provision, service operations, service support, customer relationships, planning and control, and call center management;<br />
#'''Human Enablers''': service providers, support providers, management, and owner organization (enterprise);<br />
#'''Physical Enablers''': owner organization (physical), buildings, equipment, furnishings, and location; <br />
#'''Informatics Enablers''': information, knowledge, procedures and processes, decision support, and skill acquisition; and<br />
#'''Environment''': political factors, economic factors, social factors, technological factors, environmental factors, legal factors (PESTEL), and physical factors.<br />
<br />
Thus, a service or service offering is created by the relationships among service system entities (including information flows) through business processes into strategic [[Capability (glossary)|capabilities]] that consistently provide superior value to the customer. If we were to represent the service as a network diagram (as in Figure 3 below), then the entities represent the nodes and the links represent the relationships between nodes. <br />
<br />
[[File:SSE_FOS_Fig3.png|thumb|600px|center|'''Figure 2. Service Systems Network Diagram.''' (SEBoK Original)]]<br />
<br />
==Service System Hierarchy==<br />
<br />
Systems are part of other systems which are often expressed by systems hierarchies (Skyttner 2010) to create a multilevel hierarchy, and thus the service system is composed of service system entities that interact through processes defined by governance and management rules to create different types of outcomes in the [[Context (glossary)|context]] of stakeholders with the purpose of providing improved customer interaction and value co-creation. Examples of service system entities are business enterprises, nations, or in the simplest form, a person (consumes and produces services). <br />
<br />
Using the hierarchical approach, Spohrer conceptualizes an ecosystem at the highest level in which a service system is an entity of its own. This concept is extended to create the service system hierarchy as described in Figure 4 below (Spohrer 2011; Maglio and Spohrer 2008; Maglio et al. 2010).<br />
<br />
[[File:SSE_FOS_Fig4.PNG|thumb|center|800px|'''Figure 3. Service System Conceptual Framework (Spohrer 2011).''' Reprinted with permission of Dr. James C. Spohrer. All other rights are reserved by the copyright owner.]]<br />
<br />
==Service System Attributes==<br />
<br />
The fundamental attributes of a service system include togetherness, structure, [[Behavior (glossary)|behavior]], and [[Emergence (glossary)|emergence]]. As mentioned earlier, today’s global economy is very competitive and a service system may be very competitive in a given environment at a given time (the business space). The service system’s trajectory should be well controlled as time goes by (Qiu 2009) since services are “real time in nature and are consumed at the time they are co-produced” (Tien and Berg 2003), that is, during service transactions. <br />
<br />
The service system should evolve and adapt to the conditions within the business space in a manner which ensures that the customized service behaves as expected. This adaptive behavior of service systems implies that their design must be truly trans-disciplinary:<br />
<br />
<blockquote>''They must include techniques from social science (i.e., sociology, psychology, and philosophy) and management (i.e., organization, economics, and entrepreneurship). As a consequence, Systems, Man, and Cybernetics (SMC) must expand their systems (i.e., holistic oriented), man (i.e., decision-oriented), and cybernetics methods to include and be integrated with those techniques that are beyond science and engineering.'' (Hipel et al. 2007)</blockquote><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Chang, C.M. 2010. ''Service Systems Management and Engineering, Creating Strategic Differentiation and Operational Excellence.'' New York, NY, USA: John Wiley & Sons, Inc. <br />
<br />
Chesbrough, H. 2011. ''Open Services Innovation: Rethinking Your Business to Grow and Compete in a New Era.'' San Francisco, CA, USA: Jossey-Bass.<br />
<br />
CoreGRID. 2007. "Using SLA for Resource Management and Scheduling - A Survey. Technical Report 0096." Jülich & Dortmund, Germany: European Research Network on Foundations, Software Infrastructures and Applications for large scale distributed, GRID and Peer-to-Peer Technologies, Institute on Resource Management and Scheduling, accessed June 4, 2011. Available at: http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0096.pdf. <br />
<br />
Hipel, K.W., M.M. Jamshidi, J.M. Tien, and C.C. White. 2007. "[[The Future of Systems, Man, and Cybernetics]]: Application Domains and research Methods." ''IEEE Transactions on Systems, Man, and Cybernetics-Part C: Applications and Reviews.'' 37(5): 726-743.<br />
<br />
Maglio, P., C. Kieliszewski, and J. Spohrer. 2010. ''Handbook of Service Science.'' New York, NY, USA: Springer Science amd Business Media.<br />
<br />
Maglio P. and J. Spohrer. 2008. "Fundamentals of Service Science." ''Journal of the Academy of Marketing Science'', 36(1): 18-20. <br />
<br />
Qiu, R. 2009. "Computational Thinking of Service Systems: Dynamics and Adaptiveness Modeling." ''Service Science'', 1(1): 42-55.<br />
<br />
Skyttner, L. 2006. ''General Systems Theory: Perspectives, Problems, Practice,'' 2nd ed. Singapore: World Scientific Publishing Company. <br />
<br />
Spath, D. and K.P. Fähnrich (eds.). 2007. ''[[Advances in Services Innovations]].'' Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
Spohrer, J.C. 2011. "[[Service Science]]: Progress & Directions." Presented at International Joint Conference on Service Science, 25-27 May 2011, Taipei, Taiwan.<br />
<br />
Spohrer, J. and S.K. Kwan. 2009. "Service Science, Management, Engineering, and Design (SSMED): An Emerging Discipline-Outline & References." ''International Journal of Information Systems in the Service Sector'', 1(3).<br />
<br />
Spohrer, J., and P.P Maglio. 2010. "Chapter 1: Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering'', edited by G. Salvendy and W. Karwowski. Hoboken, NJ: John Wiley & Sons. <br />
<br />
Theilmann, W. and L. Baresi. 2009. "Chapter: Multi-level SLAs for Harmonized Management in the Future Internet." In ''Towards the Future Internet- A European Research Perspective,'' edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
Tien, J.M. and D. Berg. 2003. "[[A Case for Service Systems Engineering]]." ''Journal of Systems Science and Systems Engineering'' 12(1): 13-38.<br />
<br />
Vargo, S.L. and M.A. Akaka. 2009. "Service-Dominant Logic as a Foundation for Service Science: Clarifications." ''Service Science'' 1(1): 32-41.<br />
<br />
===Primary References===<br />
<br />
Chang, C.M. 2010. ''[[Service Systems Management and Engineering]]: Creating Strategic Differentiation and Operational Excellence'' New York, NY, USA: John Wiley & Sons, Inc.<br />
<br />
Hipel, K.W., M.M. Jamshidi, J.M. Tien, and C.C. White. 2007. "[[The Future of Systems, Man, and Cybernetics]]: Application Domains and research Methods." ''IEEE Transactions on Systems, Man, and Cybernetics-Part C: Applications and Reviews'' 37(5): 726-743.<br />
<br />
Spath, D. and K.P. Fähnrich (eds.). 2007. ''[[Advances in Services Innovations]].'' Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
Spohrer, J.C. 2011. "[[Service Science: Progress & Directions]]." Presented at International Joint Conference on Service Science, 25-27 May 2011, Taipei, Taiwan.<br />
<br />
===Additional References===<br />
<br />
Chesbrough, H. 2011. ''Open Services Innovation: Rethinking Your Business to Grow and Compete in a New Era.'' San Francisco, CA, USA: Jossey-Bass.<br />
<br />
CoreGRID. 2007. "Using SLA for Resource Management and Scheduling - A Survey. Technical Report 0096." Jülich & Dortmund, Germany: European Research Network on Foundations, Software Infrastructures and Applications for large scale distributed, GRID and Peer-to-Peer Technologies, Institute on Resource Management and Scheduling, accessed June 4, 2011. Available at: http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0096.pdf. <br />
<br />
Maglio, P., C. Kieliszewski, and J. Spohrer. 2010. ''Handbook of Service Science.'' New York, NY, USA: Springer Science amd Business Media.<br />
<br />
Maglio P. and J. Spohrer. 2008. "Fundamentals of Service Science." ''Journal of the Academy of Marketing Science'', 36(1): 18-20. <br />
<br />
Qiu, R. 2009. "Computational Thinking of Service Systems: Dynamics and Adaptiveness Modeling." ''Service Science'', 1(1): 42-55.<br />
<br />
Skyttner, L. 2006. ''General Systems Theory: Perspectives, Problems, Practice,'' 2nd ed. Singapore: World Scientific Publishing Company. <br />
<br />
Spohrer, J. and S.K. Kwan. 2009. "Service Science, Management, Engineering, and Design (SSMED): An Emerging Discipline-Outline & References." ''International Journal of Information Systems in the Service Sector'', 1(3).<br />
<br />
Spohrer, J., and P.P Maglio. 2010. "Chapter 1: Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering'', edited by G. Salvendy and W. Karwowski. Hoboken, NJ: John Wiley & Sons.<br />
<br />
Theilmann, W. and L. Baresi. 2009. "Chapter: Multi-level SLAs for Harmonized Management in the Future Internet." In ''Towards the Future Internet- A European Research Perspective'', edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
Tien, J.M. and D. Berg. 2003. "A Case for Service Systems Engineering." ''Journal of Systems Science and Systems Engineering.'' 12(1): 13-38.<br />
<br />
Vargo, S.L. and M.A. Akaka. 2009. "Service-Dominant Logic as a Foundation for Service Science: Clarifications." ''Service Science.'' 1(1): 32-41.<br />
<br />
----<br />
<center>[[Service Systems Background|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Properties of Services|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Service_Systems_Background&diff=46908
Service Systems Background
2012-11-28T21:04:15Z
<p>Janthony: </p>
<hr />
<div>Economies are pre-disposed to follow a developmental progression that moves them from heavy proportional reliance on agriculture and mining toward the development of manufacturing, and finally toward more [[Service (glossary)|service]]-based economic activity. As reported by the Organization for Economic Co-Operation and Development (OECD) in its “Science, Technology, and Industry (STI) Forum” on The Service Economy: <br />
<br />
<blockquote>''The reason that we see a services economy today, and gather to talk about it and recognize its importance is because technology has allowed service industries to gain the operational leverage that manufacturing achieved 100 years ago. In addition to banks, health systems, telephone and telecommunications networks, and distribution and retailing firms are further examples of sectors that have been able to benefit from economies of scale. As a result, we are now living in a world where global-scale service companies exist for the first time, whereas we have seen global manufacturing companies for 50 years or more.'' (OECD 2000, 8)</blockquote><br />
<br />
==Evolution Toward Service-Based Economies==<br />
<br />
The typical industry example given of this progression toward services is the company International Business Machines (IBM). Even though IBM still produces hardware, they view their [[Business (glossary)|business]] as overwhelmingly service-oriented wherein hardware plays only an incidental role in their business solutions services; the fastest line of business growth within IBM has been the business-to-business (B2B) services: [[Information Technology (glossary)|information technology]] (IT); for example, [[Data Center (glossary)|data centers]] and [[Call Center (glossary)|call centers]]; [[Business Process Outsourcing (glossary)|business process outsourcing]]/re-engineering; systems integration; and organizational change. <br />
<br />
Business to government (B2G) is forecasted to have the fastest growth in the years to come (Spohrer 2011). For IBM, this trend started in 1989 with the launch of business recovery services; it accelerated with the acquisition of Price-Waterhouse Coopers Consultants in 2002 and culminated with the 2005 sale of the laptop (ThinkPad) manufacturing, their last major hardware operation.<br />
<br />
IBM exemplifies the services trend which has accelerated in the last 25-30 years and as of 2006, the services produced by private industry accounted for 67.8% of U.S. gross domestic product (GDP). The top sub-sectors included real estate, financial, healthcare, education, legal, banking, insurance, and investment. Production of goods accounted for 19.8% of GDP. The top [[Product (glossary)|product]] sub-sectors included manufacturing, construction, oil and gas, mining, and agriculture (Moran 2006).<br />
<br />
Beginning in the mid-1990s, the concept of a product-service system (PSS) started to evolve. PSSs have been adopted by businesses interested in using the model to bring not only added [[Value (glossary)|value]] to their existing offerings, but capital-intensive, environmentally favorable products to market (Mont and Tukker 2006).<br />
<br />
There are some definitional issues in any discussion of PSS, including the fact that services can sometimes be considered as products, and services invariably need physical products to support their provisioning or delivery (2006). A PSS is comprised of tangibles and intangibles (activities) in combination to fulfill specific customer [[Requirement (glossary)|requirements]], or ideally, to allow applications to be co-created [[Flexibility (glossary)|flexibly]] by linking [[Loose Coupling (glossary)|loosely-coupled]] agents, typically over a [[Network (glossary)|network]] (Domingue 2009). Research has shown that manufacturing firms are more amenable to producing "results" rather than solely products as specific artifacts and that end [[User (glossary)|users]] are more amenable to consuming such results (Cook 2004; Wild et al. 2007).<br />
<br />
The popularity of wikis, blogs, and social networking tools is strong evidence that "Enterprise 2.0" is already well under way; Andrew McAfee describes Enterprise 2.0 as "the use of emergent social software platforms within companies, or between companies and their partners or customers" (McAfee 2009). However, the integrated access to people, media, services, and things, provided by the Future Internet, will enable new styles of societal and economic interactions at unprecedented scales, flexibility, and quality. These applications will exploit the wisdom of crowds and allow for mass collaboration and value co-creation. <br />
<br />
The future internet will provide location independent, [[Interoperability (glossary)|interoperable]], [[Scalability (glossary)|scalable]], secure, and efficient access to a coordinated set of services (Tselentis et al. 2009), but such a broad vision demands a sound and well-defined approach for management and [[Governance (glossary)|governance]]. <br />
<br />
Current application service providers like Amazon, Facebook, Twitter, eBay, and Google must mediate between the business challenges enabled by network and IT convergence and customers ([[Enterprise (glossary)|enterprise]] or consumer) demanding new and more value-adding services enabled by social networks (TMFORUM 2008). The differences between IT and communications technologies are disappearing; internally-focused [[Process (glossary)|processes]] (back-stage processes) for operations optimization are now being strongly tied to the customer facing (front-stage) processes for value co-creation and delivery. <br />
<br />
In this scenario, the enterprise’s internal organization and employees are embedded in the [[Service Value Chain (glossary)|service value chain]] to benefit customers and [[Stakeholder (glossary)|stakeholders]]. In the service-dominant logic (S-DL) for marketing (Vargo and Lusch 2004), service is the application (through deeds, processes, and performances) of specialized operant resources (knowledge and skills) for the benefit of another entity or the entity itself. The emphasis is on the process of doing something for, and with, another entity in order to create value; a service system is thus a system of interacting and interdependent parts (people, technologies, and organizations) that is externally oriented to achieve and maintain a sustainable competitive advantage (IFM 2008; Maglio and Spohrer 2008). <br />
<br />
The future internet is expected to be more agile, scalable, secure, and reliable, demanding rapidly emerging applications/services with different requirements and implications for the Future Internet design that pose a significant set of problems and challenges, in particular, “the fragmentation of knowledge and the isolation of the specialist as well as the need to find new approaches to problems created by earlier ‘solution of problems’” (Skyttner 2006). The service systems engineering discipline may inform the discussion and offer potential multidisciplinary [[Environment (glossary)|environments]] and trans-disciplinary solutions. <br />
<br />
The internet has been successfully deployed for several decades due to its high flexibility in running over different kinds of physical media and in supporting different high-layer protocols and applications, including traditional file transfer, email, and client-server-based Web applications, among others.<br />
<br />
==Business Dependence on Service Systems==<br />
<br />
Most people and enterprises are heavily dependent on service interactions, including entertainment, communications, retail, education, healthcare, etc., brought about by emerging services, such as video on demand, web conferencing, time-shift services, place-shift and device-shift services, enterprise applications (e.g., enterprise resource planning (ERP), customer relationship management (CRM), manufacturing resource management (MRM), software configuration management (SCM), etc.), software as a service (SaaS), platform as a service (PaaS), cloud services, peer-to-peer (P2P) services, etc. A common denominator in the set of services mentioned is that applications are offered as services by the interaction of service system entities and thus they are service based applications (SBA). <br />
<br />
Thus, “A service based application is obtained by composing various service system entities to satisfy the desired functionality” (Andrikopoulos et al. 2010). SBAs are heavily dependent on web services development, such as Web services 2.0 (WS). Software systems engineering (SwSE) plays a very important role in a business dependent on a service system. However, another important role is played by human interfaces, organizational development and technology development; for instance, governance (rules & regulations) and technology research and development are required for future services in healthcare services, intelligent transportation services, environmental services, energy services, etc. to address societal challenges of the 21st century (sustainability, energy, etc.) as presented by Vest (2010) if we were to face those challenges as an ecosystem.<br />
<br />
==Service System Example==<br />
<br />
In an intelligent transport system-emergency transportation operation (ITS-ETO), the service goal is to provide safe evacuation, prompt medical care, and improved emergency management service. Typically, a traveler can request service through an emergency call or automated crash report feature, or a public safety officer on location can request service based on customer features and access rights. <br />
<br />
The ITS-ETO service system utilizes advances in communication and information systems (technology and information enabler) to access essential, real-time data about conditions on routes throughout the affected area and coordinate operational and logistical strategies in cooperation within all service entities (organization processes). In a critical emergency situation, when patient conditions are continuously changing, ITS can help identify the appropriate response and get the correct equipment (infrastructure enabler), such as a helicopter and emergency personnel (people enabler), to and from the scene quickly and safely. <br />
<br />
Efficient and reliable voice, data, and video communications (application enabler) further provide agencies with the ability to share information related to the status of the emergency, the operational conditions of the transportation facilities, and the location of emergency response resources to help communicate and coordinate operations and resources in real time. Advances in logistical and decision-making tools can enable commanders and dispatchers to implement strategies as conditions change (decision making). <br />
<br />
It is also critical to receive information on the environmental conditions (storm, hazardous materials, multi-vehicle crashes, etc.) and/or road closures when coordinating evacuations. The availability of real-time data about transportation conditions, coupled with decision-making tools, enables more effective responses and coordination of resources during emergencies. ITS-ETO also enhances the ability of transportation agencies to coordinate responses with other stakeholders/entities. <br />
<br />
As a result, increased data accuracy, timeliness, and automation leads to better use of resources, and reuse of exchanges, resulting in time and cost savings. Enhanced response and management leads to greater situational awareness and more effective reactions with the ability to identify and utilize the appropriate equipment, resulting in a more efficient response at the right time (output) (US DOT 2011). Figure 1 below lists the possible stakeholders in a service system.<br />
<br />
[[File:SSE_SSB_Fig1.png|thumb|800px|center|'''Figure 1. Service System Context Diagram.''' (SEBoK Original)]]<br />
<br />
As seen in the above example, the service activities are knowledge-intensive; well defined linkages (including access rights) and relationships among different entities give rise to the needed service systems interactions for the service system to be successful. As the world becomes more widely interconnected, and people become better educated, the services networks created by the interaction of the service systems will be accessible from anywhere, at any time, by anyone with the proper access rights. <br />
<br />
Knowledge agents are then humans creating new linkages of information to create new knowledge which “can later be embedded in other people, technology, shared information, and organizations." Thus, people can be considered as individual service systems with “finite [[Life Cycle (glossary)|life cycles]], identities (with associated histories and expectations), legal rights and authority to perform certain functions, perform multitasking as a way to increase individual productivity output in a finite time, and engage in division-of-labor with others to increase collective productive output in finite time” through service transactions enabled by their access rights (Spohrer and Kwan 2008).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Andrikopoulos, V., A. Bucchiarone, E. Di Nitto, R. Kazhamiakin, S. Lane, V. Mazza, and I. Richardson. 2010. "Chapter 8: Service Engineering." In ''Service Research Challenges and Solutions for the Future Internet S-Cube – Towards Engineering, Managing and Adapting Service-Based Systems'', edited by M. Papazoglou, K. Pohl, M. Parkin, and A. Metzger. Berlin Heidelberg, Germany: Springer-Verlag. 271-337.<br />
<br />
Cook, M. 2004. "Understanding The Potential Opportunities Provided by Service-Orientated Concepts to Improve Resource Productivity." In ''Design and Manufacture for Sustainable Development 2004'', edited by T. Bhamra, and B. Hon. Bury St. Edmonds, Suffolk, UK: Professional Engineering Publishing Limited. 123-134.<br />
<br />
Domingue, J., D. Fensel, J. Davies, R. González-Cabero, and C. Pedrinaci. 2009. "The Service Web: a Web of Billions of Services." In ''Towards the Future Internet- A European Research Perspective'', edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
IFM. 2008. ''[[Succeeding through Service Innovation]]: A service perspective for education, research, business and government.'' University of Cambridge Institute for Manufacturing (IfM) and International Business Machines Corporation (IBM) report. Cambridge Service Science, Management and Engineering Symposium, July 2007.<br />
<br />
Maglio P., and J. Spohrer 2008. "Fundamentals of Service Science." ''Journal of the Academy of Marketing Science 36'' (1): 18-20. DOI: 10.1007/s11747-007-0058-9.<br />
<br />
Mont, O., and A. Tukker. 2006. "Product-Service Systems." ''Journal of Cleaner Production'' 14: 1451-1454.<br />
<br />
Moran, M. 2006. ''Servicizing Solar Panels.'' Industry Course Report. Lund University International Master’s Programme in Environmental Studies and Sustainability Science Department (LUMES), Lund University, Sweden.<br />
<br />
McAfee, A. 2009. ''Enterprise 2.0: New Collaborative Tools for Your Organization's Toughest Challenges.'' Boston, MA: Harvard Business School Press.<br />
<br />
Organization for Economic Co-operation and Development (OECD). 2000. ''The Service Economy'', Science Technology Industry, Business and Industry Policy Forum Series, Paris, France: OECD. http://www.oecd.org/dataoecd/10/33/2090561.pdf <br />
<br />
Skyttner, L. 2006. ''General Systems Theory: Perspectives, Problems, Practice,'' 2nd ed. Singapore: World Scientific Publishing Company.<br />
<br />
Spohrer, J.C. 2011. "Service Science: Progress & Directions." Presented at the International Joint Conference on Service Science, May 25-27, Taipei, Taiwan.<br />
<br />
Spohrer, J. and S.K. Kwan. 2009. "Service Science, Management, Engineering, and Design (SSMED): An Emerging Discipline-Outline & References." ''International Journal of Information Systems in the Service Sector'' 1(3).<br />
<br />
TM Forum. 2008. "Service Delivery Framework (SDF) Overview, Release 2.0", Technical Report 139. Morristown, NJ: TeleManagement Forum.<br />
<br />
Tselentis, G., J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zahariadis (eds.). 2009. ''Towards the Future Internet- A European Research Perspective.'' Amsterdam, The Netherlands: IOS Press, <br />
<br />
US DOT. 2011. "Emergency Transportation Operations." Research and Innovative Technology Administration, last modified June 16, accessed June 23, 2011. http://www.its.dot.gov/eto/index.htm.<br />
<br />
Vargo, S.L. and R.F. Lusch. 2004. "The Four Service Marketing Myths – Remnants of a Goods-Based Manufacturing Model." ''Journal of Service Research'' 6: 324-335. <br />
<br />
Wild, P.J., J. Jupp, W. Kerley, C. Eckert, and P.J. Clarkson. 2007. "Towards A Framework for Profiling of Products and Services." Presented at 5th International Conference on Manufacturing Research (ICMR), September 11-13, Leicester, U.K.<br />
<br />
===Primary References===<br />
<br />
IFM. 2008. ''[[Succeeding through Service Innovation]]: A service perspective for education, research, business and government.'' University of Cambridge Institute for Manufacturing (IfM) and International Business Machines Corporation (IBM) report. Cambridge Service Science, Management and Engineering Symposium, July 2007.<br />
<br />
Organization for Economic Co-operation and Development (OECD). 2000. ''[[The Service Economy]]'', Science Technology Industry, Business and Industry Policy Forum Series, Paris, France: OECD. http://www.oecd.org/dataoecd/10/33/2090561.pdf.<br />
<br />
Vargo, S.L. and R.F. Lusch. 2004. "[[The Four Service Marketing Myths – Remnants of a Goods-Based Manufacturing Model]]." ''Journal of Service Research'' 6: 324-335.<br />
<br />
===Additional References===<br />
<br />
Andrikopoulos, V., A. Bucchiarone, E. Di Nitto, R. Kazhamiakin, S. Lane, V. Mazza, and I. Richardson. 2010. "Chapter 8: Service Engineering." In ''Service Research Challenges and Solutions for the Future Internet S-Cube – Towards Engineering, Managing and Adapting Service-Based Systems'', edited by M. Papazoglou, K. Pohl, M. Parkin, and A. Metzger. Berlin Heidelberg, Germany: Springer-Verlag. 271-337.<br />
<br />
Cook, M. 2004. "Chapter : Understanding The Potential Opportunities Provided by Service-Orientated Concepts to Improve Resource Productivity." In Design and Manufacture for Sustainable Development 2004, edited by T. Bhamra, and B. Hon. Bury St. Edmonds, Suffolk, UK: Professional Engineering Publishing Limited. 123-134.<br />
<br />
Domingue, J., D. Fensel, J. Davies, R. González-Cabero, and C. Pedrinaci. 2009. "The Service Web: a Web of Billions of Services." In ''Towards the Future Internet- A European Research Perspective.'' Tselentis, G., J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam (eds). The Netherlands: IOS Press.<br />
<br />
Maglio P., and J. Spohrer 2008. "Fundamentals of Service Science." Journal of the Academy of Marketing Science'' 36(1): 18-20.<br />
<br />
Mont, O., and A. Tukker. 2006. "Product-Service Systems." ''Journal of Cleaner Production.'' 14: 1451-1454.<br />
<br />
Moran, M. 2006. "Servicizing Solar Panels". Industry Course Report. Lund University International Master’s Programme in Environmental Studies and Sustainability Science Department (LUMES), Lund University, Sweden.<br />
<br />
McAfee, A. 2009. ''Enterprise 2.0: New Collaborative Tools for Your Organization's Toughest Challenges''. Boston, MA: Harvard Business School Press.<br />
<br />
Skyttner, L. 2006. ''General Systems Theory: Perspectives, Problems, Practice'', 2nd ed. Singapore: World Scientific Publishing Company.<br />
<br />
Spohrer, J.C. 2011. "Service Science: Progress & Directions." Presented at the International Joint Conference on Service Science, May 25-27, Taipei, Taiwan.<br />
<br />
Spohrer, J. and S.K. Kwan. 2009. "Service Science, Management, Engineering, and Design (SSMED): An Emerging Discipline-Outline & References." International Journal of Information Systems in the Service Sector 1(3).<br />
<br />
TM Forum. 2008.''Service Delivery Framework (SDF) Overview'', Release 2.0. Technical Report 139. Morristown, NJ: TeleManagement Forum.<br />
<br />
Tselentis, G., J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zahariadis (eds.). 2009. ''Towards the Future Internet- A European Research Perspective''. Amsterdam, The Netherlands: IOS Press, DOI:10.3233.<br />
<br />
US DOT. 2011. "Emergency Transportation Operations." Research and Innovative Technology Administration, last modified June 16, accessed June 23, 2011. http://www.its.dot.gov/eto/index.htm.<br />
<br />
Wild, P.J., J. Jupp, W. Kerley, C. Eckert, and P.J. Clarkson. 2007. "Towards A Framework for Profiling of Products and Services." Presented at 5th International Conference on Manufacturing Research (ICMR), September 11-13, Leicester, U.K.<br />
<br />
----<br />
<center>[[Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Fundamentals of Services|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46882
Enterprise Capability Management
2012-11-28T19:52:34Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009). The ITIL<br />
<br />
<BLOCKQUOTE><br />
“is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. In its current form …, ITIL is published in a series of five core publications, each of which covers an ITSM lifecycle stage.”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“ITIL describes procedures, tasks and checklists that are not organization-specific, used by an organization for establishing a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.” (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 2008) and architectural design process: ISO/IEC 42010 (ISO/IEC 2011) and ISO 15704 (ISO 2000)).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 2011. ''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:2011. <br />
<br />
ISO/IEC/IEEE 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
Wikipedia contributors, "Information Technology Infrastructure Library," ''Wikipedia, The Free Encyclopedia''. Accessed November 28, 2012. Available at: http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46881
Enterprise Capability Management
2012-11-28T19:50:45Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009). The ITIL<br />
<br />
<BLOCKQUOTE><br />
“is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. In its current form …, ITIL is published in a series of five core publications, each of which covers an ITSM lifecycle stage.”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“ITIL describes procedures, tasks and checklists that are not organization-specific, used by an organization for establishing a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.” (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 2008) and architectural design process: ISO/IEC 42010 (ISO/IEC 2011) and ISO 15704 (ISO 2000)).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 2011. ''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:2011. <br />
<br />
ISO/IEC/IEEE 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed November 28, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46878
Enterprise Capability Management
2012-11-28T19:38:15Z
<p>Janthony: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009). The ITIL<br />
<br />
<BLOCKQUOTE><br />
“is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. In its current form …, ITIL is published in a series of five core publications, each of which covers an ITSM lifecycle stage.”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“ITIL describes procedures, tasks and checklists that are not organization-specific, used by an organization for establishing a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.” (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 2008) and architectural design process: ISO/IEC 42010 (ISO/IEC 2011) and ISO 15704 (ISO 2000)).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 2011. ''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:2011. <br />
<br />
ISO/IEC/IEEE 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46869
Enterprise Systems Engineering
2012-11-28T19:13:17Z
<p>Janthony: /* Enterprise vs Organization */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
"One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the vision and aims, maintain a common understanding of requirements and monitor the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]]." (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
"Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user." (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed November 28, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46868
Enterprise Systems Engineering
2012-11-28T19:11:07Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
''One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the vision and aims, maintain a common understanding of requirements and monitor the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]].'' (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
"Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user." (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed November 28, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46867
Enterprise Systems Engineering
2012-11-28T19:06:53Z
<p>Janthony: /* Enterprise vs Organization */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
''One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the vision and aims, maintain a common understanding of requirements and monitor the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]].'' (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
"Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user." (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed September 12, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Socio-Technical_Features_of_Systems_of_Systems&diff=46866
Socio-Technical Features of Systems of Systems
2012-11-28T18:55:59Z
<p>Janthony: /* Human and Organizational Considerations in SoS */</p>
<hr />
<div><br />
Most [[System of Systems (SoS) (glossary)|systems of systems]] (SoS) are socio-technical systems that are composed of a number of interdependent resources, such as, people, processes, information, and technology that must interact with each other and their [[Environment (glossary)|environment]] in support of a common [[mission (glossary)]] (See also [[Enterprise Systems Engineering]]).<br />
<br />
==Human and Organizational Considerations in SoS==<br />
Within a SoS, these socio-technical systems are often referred to as [[enterprise (glossary)]] systems (Chen et al. 2008). Examples of emerging ‘soft’ issues that are critical to the [[Design (glossary)|design]] and operation of systems of systems can be identified as follows (Hubbard et al. 2010):<br />
* decision making in SoS, which includes addressing issues involving autonomy, authority, responsibility and [[Ethics (glossary)|ethics]],<br />
* measures of enterprise SoS performance,<br />
* impact of [[Culture (glossary)|culture]] and cultural attributes on multinational and multicultural [[Team (glossary)|team]] performance,<br />
* system of systems ethics, [[Governance (glossary)|governance]], and regulation,<br />
* system of systems experimentation,<br />
* shared/distributed situational awareness,<br />
* alternative approaches to training, e.g., virtual reality and gaming,<br />
* SoS lead and lag ‘soft’ [[Metric (glossary)|metrics]], e.g., improved mental and physical workload [[Measurement (glossary)|measurement]] techniques,<br />
* enterprise system [[Agility (glossary)|agility]] and [[Resilience (glossary)|resilience]], e.g., dynamic allocation and reallocation of function and the human in the loop, and<br />
* enterprise SoS leadership and motivational issues.<br />
<br />
The will still be some time before we have the ability to look into the future by modeling or simulating socio-technical systems or ‘soft’ elements of a system of systems in order to evaluate the [[effectiveness (glossary)|effectiveness]], impact or added value of alternative system configurations, prior to deployment. Such a capability would greatly enhance our ability to dynamically (re)configure appropriate socio-technical systems (people, [[process (glossary)|process]], and technology), to achieve the performance required to produce designated [[capability (glossary)]] in different contexts, and to avoid SoS structures that are susceptible to undesirable emergent behavior (also see emergence). <br />
<br />
There are three particular areas that are key to the development of these socio-technical / enterprise systems:<br />
* An enterprise architecture (EA) is the [[architecture (glossary)|architecture]] of an organization that supports the strategy, analysis, and planning by stakeholders and is used to determine how the organization can most effectively achieve its current and future objectives, <br />
* An enterprise architecture framework (EAF) provides an enabling methodology to is used to describe how an EA must be organized, structured, and operated in terms of people, processes, [[product (glossary)|product]], [[Information Technology (glossary)|information technology]] (IT) and resources in order to achieve its goal (Vernadat 1996; Bernus, Nemes et al. 2003; Chen, Doumeingts et al. 2008), and <br />
* enterprise system models not only provide the means to visualize, represent, and analyze the inner workings of an enterprise SoS, but may also constitute the building blocks of an enterprise SoS architecture (EA).<br />
<br />
Existing [[Model (glossary)|models]] and enterprise system architectures and frameworks (e.g. Zachman, Computer Integrated Manufacturing Open System Architecture (CIMOSA), Generalized Enterprise Reference Architecture and Methodology (GERAM), Virtual Enterprise Reference Architecture and Methodology (VERAM), TOronto Virtual Enterprise (TOVE), Purdue Enterprise Reference Architecture (PERA), Department of Defense Architecture Framework (DoDAF), and Ministry of Defence Architecture Framework (MODAF)) tend to deal with enterprise elements such as resources, information flows, and functions, quite well; however, they do not show a sufficient capability to include ''soft'' enterprise characteristics such as policies, culture, [[Competency (glossary)|competencies]], decision making structures, etc. within dynamic models. Hence, changes in one or more of these characteristics are not shown in overall organizational system performance. The following points can be made with reference to EAs:<br />
* Architecture is foundational for managing modern enterprises and planning enterprise integration,<br />
* An EA framework is an organized collection of ingredients (tools, methodologies, modeling languages, models, etc.) that are necessary to architect or re-architect a part of or an entire enterprise, and<br />
* For a given enterprise, the enterprise architecture describes the work the enterprise does, the information the enterprise uses, and the physical means, human labor, and IT that the enterprise requires.<br />
<br />
The prime advantage of an EA is to provide a common view (in the form of models) of what is taking place in the enterprise to relevant actors or stakeholders of the enterprise. The second decisive advantage of an EA is that it provides a sound basis for the management of change that occurs throughout the [[Life Cycle (glossary)]] of the enterprise. Vernadat (1996) combines the two methodologies of enterprise modeling and enterprise integration and advocates a systematic engineering approach, referred to as enterprise engineering, for modeling, analyzing, designing and implementing integrated enterprise systems.<br />
<br />
Enterprise modeling (EM) is concerned with the representation and specification of the various aspects of enterprise operations; namely, functional aspects to describe what are the things to be done and in which order, informational aspects to describe which objects are used or processed, resource aspects to describe who performs what and according to which policy, and organizational aspects to describe the organizational structure and the timeframe within which things are being done. These enterprise system models constitute the building blocks of an enterprise SoS architecture and can be combined within an EA framework to provide a dynamic overview of the enterprise system.<br />
<br />
Although there are several models available to assess the structure and performance of organizations (e.g. Castka 2001; Curtis et al. 2001; Tannenbaum et al. 1996), few if any of these models provide quantitative and qualitative measures of performance and none are truly able to provide a direct, multi-point, measurable cause and effect link between the various soft attributes of an enterprise system and its performance. It is clear, though, that success factors from a human perspective do center upon the structure of communication (stakeholder management) and decision making processes and systems within the overall system of systems.<br />
<br />
==Dealing with Socio-Technical Issues in an SoS==<br />
Many of the issues associated with ‘soft’ or organizational aspects of an SoS often exhibit many of the characteristics of so-called wicked problem (Rittel and Webber 1973), including:<br />
* problems are extremely complex and not bounded or stable,<br />
* they do not have uniquely correct solutions, but rather solutions that are either better or worse than others, and they also do not have a definitive formulation,<br />
* SoS requirements are often volatile with changing constraints and moving targets,<br />
* stakeholders have different views, and<br />
* understanding the whole context is challenging but critical.<br />
<br />
These issues relate to both hard (mechanical, electronic, and [[software (glossary)]]) and soft (people, organizations, and regulatory) systems considerations. Research must include mixed methods and approaches (Conklin 2005) that include both quantitative and qualitative techniques, which makes this a very challenging area intellectually.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Bernus, P., Nemes, L., et al. (eds). (2003). ''Handbook on enterprise architecture.'' Heidelberg, Springer Verlag.<br />
<br />
Castka, P.B. 2001. "Factors Affecting the Successful Implementation of High Performance Teams." ''Team Performance Management'', 7(7/8), 123-134. <br />
<br />
Chen, D., G. Doumeingts, et al. (2008). "Architectures for enterprise integration and interoperability: Past, present and future." ''Computers in Industry,'' 59(7): 647-659.<br />
<br />
Curtis, B., Hefley, W.E., and Miller, S.A. 2009. ''People Capability Maturity Model (P-CMM.'' Version 2.0, 2nd Ed. Software Engineering Institute. Carnegie Mellon University. Available at <br />
[http://repository.cmu.edu/cgi/viewcontent.cgi?article=1048&context=sei http://repository.cmu.edu/cgi/viewcontent.cgi?article=1048&context=sei]<br />
<br />
Conklin, J. 2005. ''Dialogue Mapping: Building Shared Understanding of Wicked Problems,'' 1st ed. Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd. <br />
<br />
Hubbard, E-M., Siemieniuch, C.E., Sinclair, M.A., and Hodgson, A. 2010. "Working towards a Holistic organisational Systems Model." Presented at 5th Int. Conf. Systems of Systems Engineering (SoSE), Loughborough, UK. 22-24 June. <br />
<br />
Rittel, H.W.J., and Webber, M.M. 1973. "Dilemmas in a General Theory of Planning." ''Policy Sciences 4'' Amsterdam, The Netherlands: Elsevier Scientific Publishing Company, Inc.: 155–169. In Cross, N. 1984. Ed. ''"Developments in Design Methodology."'' Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd. pp. 135–144.<br />
<br />
Tannenbaum, S.I., Salas, E., and Cannon-Bowers, J.A. 1996. "Promoting Team Effectiveness." In West, M. A. ''Handbook of Work Group Psychology.'' Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd.<br />
<br />
Vernadat, F.B. 1996. ''Enterprise Modeling and Integration: Principles and Applications.'' London, England, UK: Chapman and Hall Publishers.<br />
<br />
===Primary References===<br />
Checkland, P.B. 1981. [[Systems Thinking, Systems Practice]]. Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd.<br />
<br />
Hubbard, E-M., C.E. Siemieniuch, M.A. Sinclair, and A.Hodgson. 2010. "[[Working towards a Holistic Organisational Systems Model]]." Presented at 5th Int. Conf. Systems of Systems Engineering (SoSE), Loughborough, UK. 22-24 June. <br />
<br />
Rittel, H.W.J., and Webber, M.M. 1973. "[[Dilemmas in a General Theory of Planning]]." ''Policy Sciences 4'' Amsterdam, The Netherlands: Elsevier Scientific Publishing Company, Inc.: 155–169. In Cross, N. 1984. Ed. ''"Developments in Design Methodology."'' Chichester, West Sussex, England, UK: John Wiley & Sons, Ltd. pp. 135–144<br />
<br />
===Additional References===<br />
Bruesburg, A. and G. Fletcher. 2009. ''The Human View Handbook for MODAF'' Draft Version 2. Second Issue. Bristol, England, UK: Systems Engineering & Assessment Ltd. http://www.hfidtc.com/research/process/reports/phase-2/hv-handbook-issue2-draft.pdf.<br />
<br />
IFIP-IFAC Task Force. 1999. "The Generalised Enterprise Reference Architecture and Methodology." V1.6.3. http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/v1.6.3.html.<br />
<br />
ISO 14258:1998. ''Industrial automation systems — Concepts and rules for enterprise models.'' Geneva, Switzerland: International Organization for Standardization; <br />
<br />
ISO 19439:2006. ''Enterprise integration — Framework for enterprise modelling.'' Geneva, Switzerland: International Organization for Standardization. <br />
<br />
ISO 19440:2007. ''Enterprise integration — Constructs for enterprise modelling.'' Geneva, Switzerland: International Organization for Standardization.<br />
<br />
Miller, F. P., A. F. Vandome, and J. McBrewster. 2009. ''Enterprise Modelling.'' Mauritius: Alphascript Publishing, VDM Verlag Dr. Müller GmbH & Co. KG.<br />
<br />
----<br />
<center>[[Architecting Approaches for Systems of Systems|< Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Capability Engineering|Next Article >]]</center><br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Systems of Systems (SoS)]]</div>
Janthony
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=46859
Service Systems Engineering Stages
2012-11-28T17:56:48Z
<p>Janthony: /* Service Systems Engineering Tools & Technologies */</p>
<hr />
<div>This article describes the stages of the service systems development process (SSDP) and expected outputs for each stage; for a closer alignment with the traditional systems engineering (TSE) process, the concept and feasibility phases have been combined into a single service strategy/concept as discussed in the SEBoK [[Systems Engineering and Management]] article. All of the stages of the SSDP take a similar iterative approach to fully understand the [[enterprise (glossary)]] [[Capability (glossary)|capabilities]], enterprise process impact, [[Information Technology (glossary)|information technology]] (IT), and technology impacts and [[customer (glossary)]] expectations. Lin and Hsieh (2011) provide a good summary on New service Development processes. The Information Technology Infrastructure Library (ITIL) stage names have been purposely added to the SSDP to show the needed alignment between IT and technology. The reader should keep in mind that even though IT is crucial to the overall end-to-end system, service technology development needs must be taken into consideration in all the stages of SSDP.<br />
<br />
==Service Strategy/Concept==<br />
<br />
A service strategy/concept is the entry into the SSDP. The concept may be generated by an end-[[User (glossary)|user]] (enterprise customer or consumer), a business manager, an [[Engineering (glossary)|engineering]] organization, new web service designers, new technology developments, and/or information technology trends. The service concept is the highest level of the service idea and it usually addresses what service is being proposed to what markets and to whom within these markets. <br />
<br />
A high-level feasibility assessment of the concept is then carried out by the integrated service development team (ISDT) to assess the needs/impacts on enterprise process [[Capability (glossary)|capabilities]], [[Operational (glossary)|operational]] capabilities, and/or new technology developments (access, infrastructure, operations support systems (OSS), service support systems (SSS), and business support systems (BSS). It should also consider any impacts on service [[Governance (glossary)|governance]], social, cultural, and human behaviors. The feasibility assessment also gives a plus or minus 30% estimate on the time to develop and the [[Cost (glossary)|cost]] of development, which are entry points into the business case to evaluate whether the service is viable to develop and to market given the [[Constraint (glossary)|constraints]] and estimates. At this time, a decision ([[Decision Gate (glossary)|decision gate]]) determines if the service is to be developed.<br />
<br />
If the business case is viable, then a detailed business description of the service is developed. This includes functions and features to be included, phases of development, markets to be addressed, customers within the markets to be targeted, and customer experiences expected from the service (i.e., defining the [[Non-Functional Requirements (glossary)|non-functional requirements]] of the service, such as the [[Quality (glossary)|quality]] of service (QoS), [[Availability (glossary)|availability]], [[Reliability (glossary)|reliability]], and [[Security (glossary)|security]] considerations and offerings within the service). This description allows detailed studies of expected human-computer interactions, social networking, technology requirements, and operations requirements. Governance and organizational process requirements should also be included to generate the “service description” as the main output from this stage. <br />
<br />
Service systems engineering (SSE) takes an important role in understanding and eliciting the enterprise service concepts. Clearly, understood end-to-end business processes required for the intended service are fundamental to its successful development, deployment, and customer satisfaction. SSE works with business process management (BPM), social science, and cognitive science to elicit intended service operations, including target audiences, pre-sale, sale, and post-sale customer care processes.<br />
<br />
==Requirements Analysis and Engineering==<br />
<br />
A service requirements document is created that describes the service functions, the service entities, the intended interaction among entities, and the customer-facing and internal-facing functions/processes that are required to support the service. This description should conceptually include intended service level agreements (SLAs) and the obligations of the service provider process should there be any degree of non-compliance during service operation. <br />
<br />
In addition to the TSE activities described earlier, the SSE requirements analysis and engineering process must develop a customer-centric view of the service to analyze SLA, QoS, value co-creation, monitoring, and assessment requirements to comply with the expected/planned SLA. This analysis will determine whether dynamic changes of the service are required during service operation to correct faults, reconfigure, administer, or to adapt/self-adapt for possible performance degradations.<br />
<br />
Beyond the traditional service life cycle management (LCM) processes, the requirements must also be developed for service level management (SLM) processes and systems. These are needed to monitor, measure, and assess key performance indicators (KPIs), [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] (TPMs), and service performance measures (SPMs) according to the SLA. <br />
<br />
The SSE requirements analysis addresses the support systems for the [[governance (glossary)]], business, service, operations, and support processes to derive requirements for technologies, information systems, processes, and enterprise organizations. Interface requirements, information flows, and data requirements are also within the scope of requirements analysis. The main output is the service requirements document (SRD).<br />
<br />
SSE plays a critical role in describing the services needs for day-to-day operations. These include customer care centers requirements and interfaces between network infrastructure provider(s), content provider(s), service provider(s), service based application provider(s), and the customer management process for the service. All of these are described in detail in the service operations plans (SOPs) and the operations technical plans (OTPs).<br />
<br />
==Systems Design/Development==<br />
<br />
The SRD, SOP, and OTP have enough detail regarding the service functions, operations, interfaces, and information flows required among the different service system entities to analyze, identify, and recommend end-to-end applicable architecture frameworks; to carry out trade-off analyses for the alternatives among service system entities; and to describe and allocate relationships (interactions) among entities at all levels of the service architecture. Detailed requirements are worked at lower levels to generate specifications for entity developers including data structures, data flow diagrams, and allocated performance requirements. <br />
<br />
ITIL v. 3 (OGC 2009) recommends inclusion of the following service design processes:<br />
<br />
*service catalog management,<br />
*service level management, <br />
*[[Capacity (glossary)|capacity]] management,<br />
*availability management,<br />
*service continuity management,<br />
*security management, and<br />
*supplier/provider management.<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)|integration]] and interface requirements for the seamless operation of the service. In this regard, the system engineer takes an integrator role to ensure proper data generation and flow through all the different systems composing the service offered. The goal is to ensure customers (consumer or internal) are getting the information required to carry out the tasks required in the business, operations, service, and customer processes. The service [[Integration, Verification, and Validation (IV&V) (glossary)|integration, verification, and validation]] (IV&V) plans need to include end-to-end [[Verification (glossary)|verification]] and [[Validation (glossary)|validation]] procedures for any new development or adaptations required for planned dynamic configuration/re-configuration of previously tested service systems. (See also [[System Verification]] and [[System Validation]].)<br />
<br />
The systems engineer creates the IV&V plans using a number of different perspectives. These include<br />
<br />
*end-to-end service (service validation test plans),<br />
*customer care (operational readiness test plans),<br />
*service provider (network validation test plans),<br />
*service system entities interoperability/interface test plans,<br />
*content provider (content validation test plans), and<br />
*application (user acceptance test plans).<br />
<br />
==Service Transition/Deployment==<br />
<br />
Service systems may change very rapidly and new enhancements, new features, or new applications can be added as incremental developments, new developments, or adaptation to service offerings. Service systems engineers review new requirements to assess the feasibility of the changes to the service system entities, technologies, processes, and organizations, as well as their impacts on the service offerings. The service transition/deployment stage takes input from service development to plan for service insertion, technology insertion, processes adaptations, and implementation with minimal impact to existing services. During this stage, special care is taken with IV&V test plans and regression testing to ensure new developments work flawlessly with existing services. <br />
<br />
ITIL v. 3 (OGC 2009) recommends the following processes in the transition/deployment stage:<br />
<br />
*transition planning and support,<br />
*change management,<br />
*service asset and configuration management,<br />
*release and deployment management,<br />
*service validation and testing,<br />
*evaluation, and<br />
*knowledge management.<br />
<br />
==Service Operations/Continuous Service Improvement (CSI)==<br />
<br />
Service operation manages the day-to-day activities of all aspects of the end-to-end service delivery to the customer. It manages the operations, administration, maintenance, and provisioning of the service, technology, and infrastructure required to deliver the contracted service to the customer within the specified service levels. The main service operations processes in ITIL v. 3 are<br />
<br />
*event management,<br />
*incident management,<br />
*problem management,<br />
*request fulfillment, and<br />
*access management.<br />
<br />
A continuous service improvement (CSI) plan for the implementation of technologies and tools for the continuous improvement of the service, monitoring, measuring, and analyzing process and service metrics is essential.<br />
<br />
==Service Systems Engineering Tools & Technologies==<br />
<br />
Tools and technologies from a broad spectrum of fields are extensively used during the different stages of SSE. Not only are they used for the development of the hardware, software, information systems and technology components, but also for the modelling, definition, and [[Design (glossary)|design]] of the organization, processes, and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include modelling, [[Simulation (glossary)|simulation]], development, test bed, and social environmental aspects of the intended or to be designed service. The tools fall into three main domains:<br />
#business process management (BPM),<br />
#service design process, and<br />
#service design management.<br />
<br />
'''Business process management (BPM)''' generally deals with process management scenarios to coordinate people and systems, including sequential workflow, straight through processing, case management, content life cycle management, collaborative process work, and value chain participation. Systems engineers work with service managers to align the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation (BPMN) is a graphic notation standard that is implemented to describe a process’s realization within any given workflow. This notation is linked with web services business process execution language (WS-BPEL), a format used to perform an automated business process by implementing web services technology. For an extensive review of existing BPM tools and BPM suites, please see Hantry et al. (2010), Carroll et al. (2010), Andrikoupolous et al. (2010), Lin and Hsieh (2011), and Ward-Dutton (2010).<br />
<br />
'''Service design process''': Architecture frameworks (AF) and enterprise architectures (EAs) are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)|complex]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)|products]] and services. Systems engineering modeling tools, such as the unified modeling language (UML) (OMG 2010a) and system modeling language (SysML) (OMG 2010b), help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service oriented architecture (SOA) and systems and software engineering architecture (ISO/IEC/IEEE 2011) are standards that apply architecture principles for specialized applications. Successful implementation of the architecture tools helps identify critical interfaces and improves understanding of the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)|Mode-based systems engineering]] (MBSE), model driven architectures (MDA), and model oriented systems engineering (MOSES) are examples of commonly used tools for logical (functional), behavioral (operational), and physical design of the IT. UML, UML 2.0, and SysML are extensively used to describe operational scenarios, modes of operations, use cases, and entity relationships. For an extensive review of MBSE, MDA, and MOSES, please see Friedenthal (1998), Estefan (2008), Pezuela (2005), Andrikopoulos et al. (2010), and Hybertson (2010).<br />
<br />
In addition, trade-off and engineering analyses use different optimization methodologies. Since services exhibit a significant level of randomness, statistical analysis, demand forecasting, multi-objective optimization, queuing theory, and stochastic optimization methodologies are tools used to model and simulate the service system behavior. These methodologies support decision making in areas as diverse as resource allocation, number of facilities, facilities' geographical locations, fleet routing and optimization, service systems reliability and prognosis, and network optimization. A good overview of these methodologies can be found in Daskin (2010).<br />
<br />
During the service design process (SDP), planning for the implementation of technologies and tools for the continuous improvement of the service is performed. These tools support monitoring, measuring, and analyzing process and service performance metrics. The Deming cycle (plan, do, check, and act (PDCA) is widely used as the foundation for [[Quality (glossary)|quality]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] manufacturing, [[Six Sigma (glossary)|six sigma]], swim lanes, balanced scoreboard, benchmarking, and gap analysis methodologies are commonly used for service evaluation and continuous improvement.<br />
<br />
'''Service design management''': There are standards for implementing and managing systems engineering processes (IEEE 1220 (1998)) that help coordinate and synchronize all the service systems engineering processes leading to improved organizational collaboration and improved service delivery (see also [[Systems Engineering Standards]]). Standards have been developed in software engineering for product evaluation (ISO/IEC 14598 (1998)) and product quality (ISO/IEC 9126 series (2003a, 2003b, & 2004)), as well as information security management (ISO 27001 (2005)) and evaluation series (ISO 15408 (2008a, 2008b, & 2009)). The ITIL v. 3 describes best practices for IT service management, which can be extended to include service systems.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Adams, S., A. Cartlidge, A. Hanna, S. Rance, J. Sowerby, J. Windebank. 2009. ''ITIL V3 Foundation Handbook.'' London, England. The Stationary Office: 44. ISBN 9780113311989<br />
<br />
Andrikopoulos, V., A. Bucchiarone, E. Di Nitto, R. Kazhamiakin, S. Lane, V. Mazza, and I. Richardson. 2010. "Chapter 8: Service Engineering." Papazoglou, M.; Pohl, K.; Parkin, M.; Metzger, A. (Eds.) . ''"Service Research Challenges and Solutions for the Future Internet S-Cube – Towards Engineering, Managing and Adapting Service-Based Systems"'' Berlin Heidelberg, Germany: Springer-Verlag: 271-337.<br />
<br />
Carroll, N., E. Whelan, and I. Richardson. "Applying Social Network Analysis to Discover Service Innovation within Agile Service Networks." ''Service Science 2'' (4): 225-244.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]]'', rev, B. Seattle, WA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at: http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf<br />
<br />
Friedenthal, S. 1998. "Object Oriented System Engineering: Process Integration for 2000 and beyond." Presented at System Engineering & Software Symposium. New Orleans, LA: Lockheed Martin Corporation. <br />
<br />
Hantry, F., M.P. Papazoglou, W. van den Heuvel, R. Haque, E. Whelan, N. Carroll, D. Karastoyanova, F. Leymann, C. Nikolaou, W. Lamersdorf, and M. Hacid. 2010. "Chapter: Business Process Management." in Papazoglou, M.P., K. Pohl, M. Parkin, A. Metzger (eds.) . ''Service Research Challenges and Solutions for the Future Internet S-Cube – Towards Engineering, Managing and Adapting Service-Based Systems.'' Berlin Heidelberg, Germany: Springer-Verlag: 27-54.<br />
<br />
Hybertson, D.W. 2009. ''[[Model-Oriented Systems Engineering Science]]: A Unifying Framework for Traditional and Complex Systems.'' Boston, MA, USA: Auerbach Publications. ISBN # 978-1-4200-7251-8.<br />
<br />
IEEE. 1998. ''IEEE Standard for Application and Management of the Systems Engineering Process''. Washington, DC: Institute of Electrical and Electronics Engineers (IEEE), IEEE 1220-1998.<br />
<br />
ISO/IEC. 1998. ''Information technology — Part 5: Process for evaluators.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 14598-5:1998.<br />
<br />
ISO/IEC. 2003a. ''Software engineering — Product quality — Part 2: External metrics.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC TR 9126-2:2003.<br />
<br />
ISO/IEC. 2003b. ''Software engineering — Product quality — Part 3: Internal metrics.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC TR 9126-3:2003.<br />
<br />
ISO/IEC. 2004. ''Software engineering — Product quality — Part 4: Quality in use metrics.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC TR 9126-4:2004.<br />
<br />
ISO/IEC. 2005. ''Information technology — Security techniques — Information security management systems — Requirements.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 27001:2005.<br />
<br />
ISO/IEC. 2008a. ''Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15408-2:2008.<br />
<br />
ISO/IEC. 2008b. ''Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance components.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15408-3:2008.<br />
<br />
ISO/IEC. 2009. ''Information technology — Security techniques — Evaluation criteria for IT security — <br />
Part 1: Introduction and general model.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15408-1:2009.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering — Architecture description.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 42010:2011.<br />
<br />
Lefever, B. 2005. [[SeSCE Methodology]]. SeCSE Service Centric Systems Engineering. SeCSE511680. Available at: http://www.secse-project.eu/wp-content/uploads/2007/08/a5_d4-secse-methodology-v1_3.pdf<br />
<br />
Lin, F. and P. Hsieh. 2011. "A SAT View on New Service Development." ''Service Science'' 3(2): 141-157.<br />
<br />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<br />
<br />
OMG. 2010a. ''Unified Modeling Language™ (UML),'' Version 2.. Needham, MA, USA: Object Management Group. Available at http://www.omg.org/spec/UML/.<br />
<br />
OMG. 2010b. ''OMG Systems Modeling Language (SysML),'' Version 1.2. Needham, MA, USA: Object Management Group. Available at http://www.sysml.org/docs/specs/OMGSysML-v1.2-10-06-02.pdf.<br />
<br />
Pezuela, C., 2005. "Collection of Existing Service Centric Prototypes." Report A5.D1 Brussels, Belgium: European Union, Information Society Technology. http://www.secse-project.eu/wp-content/uploads/2007/08/a5d1-collection-of-existing-service-centric-prototypes.pdf Accessed on September 5, 2011.<br />
<br />
Ward-Dutton, N. 2010. "BPM Technology: Vendor Capability Comparison." MWD Premium Advisory Report. Horsham, West Sussex, UK: Macehiter Ward-Dutton (MWD) Limited. MWD Advisors. http://www.mwdadvisors.com/library/detail.php?id=380 Accessed September 5, 2011.<br />
<br />
===Primary References===<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]]'', rev, B. Seattle, WA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at: http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf<br />
<br />
Hybertson, D.W. 2009. ''[[Model-Oriented Systems Engineering Science]]: A Unifying Framework for Traditional and Complex Systems.'' Boston, MA, USA: Auerbach Publications. ISBN # 978-1-4200-7251-8.<br />
<br />
Lefever, B. 2005. [[SeSCE Methodology]]. Rome, Italy: SeCSE Service Centric Systems Engineering. SeCSE511680. Available at: http://www.secse-project.eu/wp-content/uploads/2007/08/a5_d4-secse-methodology-v1_3.pdf<br />
<br />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<br />
<br />
===Additional References===<br />
<br />
None.<br />
<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Properties_of_Services&diff=46795
Properties of Services
2012-11-28T15:55:06Z
<p>Janthony: /* Service Key Performance Indicators */</p>
<hr />
<div>A [[Service (glossary)|service]] is realized by the [[Service System (glossary)|service system]] through the relationships of service system entities that interact (or relate) in a particular way to deliver the specific service via a service level agreement (SLA). Current management frameworks typically only focus on the interfaces of single service system entities. Meanwhile, SLAs are mapped to the respective [[Customer (glossary)|customer]] [[Requirement (glossary)|requirements]]. These policies are provider-specific means to express constraints and rules for their internal operations. These rules may be independent of any particular customer (Theilmann 2009). <br />
<br />
Services not only involve the interaction between the service provider and the consumer to produce [[Value (glossary)|value]], but have other attributes, like an intangible [[Quality (glossary)|quality]] of service (e.g., an ambulance service's availability and response time to an emergency request). The demand for a service may have varying loads dependent on the time of day, day of week, season, or other unexpected needs (e.g., natural disasters, [[Product (glossary)|product]] promotion campaigns, etc.). In the US for instance, travel services have peak demands during Christmas week; Mother’s day is usually the highest volume handling day for a telecommunications provider and tax services peak during extended periods (January through mid-April). Services cannot be inventoried; they are rendered at the time they are requested. <br />
<br />
Additionally, for a [[Business (glossary)|business]] [[Enterprise (glossary)|enterprise]], delivering the service at the minimum [[Cost (glossary)|cost]] while maximizing its profits may be the service objective. In contrast, for a non-profit [[Organization (glossary)|organization]] the objective may be to maximize [[Customer (glossary)|customer]] satisfaction while optimizing the resources required to render the service (e.g., during a natural disaster). Thus, the design and operations of service systems “is all about finding the appropriate balance between the resources devoted to the [[System (glossary)|systems]] and the demands placed on the system so that the quality of service to the customer is as good as possible” (Daskin 2010).<br />
<br />
==Service Level Agreement==<br />
<br />
A SLA is a set of technical (functional) and non-technical (non-functional) parameters agreed among customers and service providers. SLAs can and do contain administrative level (non-functional) business related parameters, such as SLA duration, service availability for the SLA duration, consequences for variations, failure reporting, priorities, and provisions for modifications to the SLA. However, for service level management, the service level (technical) parameters need to be defined, monitored, and assessed; these parameters may include such things as throughput; quality; availability; security; performance; reliability, for example, mean time between failure (MTBF), maximum downtime, and time-to-repair; and resource allocation. <br />
<br />
An SLA represents the negotiated service level requirements (SLR) of the customer and should establish valid and reliable service performance [[Measure (glossary)|measures]] since it is usually the basis for effective service level management (SLM). The goal of SLM is to ensure that service providers meet and maintain the prescribed quality of service (QoS). However, care should be taken since in some domains the term QoS refers only to resource reservation control mechanisms rather than the achieved service quality (e.g., internet protocol (IP) networks). Some terms used to mean the “achieved service quality” include quality of experience (QoE), user-perceived performance, and degree of satisfaction of the user; these other terms are more generally used across service domains.<br />
<br />
Non-functional properties fall into two basic categories: business properties, such as price and method of payment, and environmental properties, such as time and location. Business and environmental properties are classified as “context properties” by Youakim Badr (Badr et al. 2008). QoS properties are characteristics such as [[Availability (glossary)|availability]], [[Resilience (glossary)|resilience]], [[Security (glossary)|security]], [[Reliability (glossary)|reliability]], [[Scalability (glossary)|scalability]], agreement duration, response times, repair times, usability, etc. Therefore services evaluation measures are customer oriented and include not only traditional performance metrics (productivity, quality, etc.), but also require a comprehensive analysis of the service system from an end-to-end perspective. Service evaluation typically includes customer demand-supply to ensure economic viability across the lifecycle of the service system. Furthermore, the service delivery is evaluated using the key technical performance metrics listed above, adding also Service Process Measures (provisioning time, time-to-restore/repair, etc.) and Technical Performance Measures (end-to-end response times, latency, throughput, etc.). Finally, the service system’s SLAs are then the composition of these categories evaluated on a systemic level to ensure consistency, equity, and sustainability of the service to assure that the desired/contracted SLA for customer satisfaction, value co-creation, and high system robustness are realized. (Spohrer 2011; Tien and Berg 2003; Theilmann and Baresi, 2009)<br />
<br />
==Service Key Performance Indicators==<br />
<br />
Service key performance indicators (KPI) are defined and agreed to in the SLA; the service KPIs are decomposed into service process measures (SPM) and technical performance measures (TPM) during the analysis stage of the service systems engineering (SSE) process. In the design process, the KPIs and TPM are allocated to service system entities and their [[Component (glossary)|components]], as well as to the business processes and their components so as to ensure compliance with SLAs. The allocated measures generate [[Derived Requirement (glossary)|derived requirements]] (SLR) for the system entities and their relationships, as well as for the service entities' components and the data and information flows required in the service systems to monitor, measure, and assess end-to-end SLA. These allocations ensure that the appropriate performance indicators apply to each of the links in the service value chain. <br />
<br />
TPMs are typically categorized by the number of defective parts in a manufacturing service, data transmission [[Latent (glossary)|latency]] and data throughput in an end-to-end application service, IP QoS expressed by latency, jitter delay, and throughput; SPMs are typically categorized by service provisioning time, end-to-end response times to a service request (a combination of data and objective feedback), and quality of experience (QoE verified by objective feedback). Together, the KPI (TPM combined with SPM) and perception measures make up the service level management function. A quality assurance system's (QAS) continuous service improvement (CSI), processes, and process quality management and improvement (PQMI) should be planned, designed, deployed, and managed for the [[Capability (glossary)|capability]] to continuously improve the service system and to monitor compliance with SLAs (e.g., PQMI, capability maturity model integration (CMMI) (SEI 2007), International Organization for Standardization (ISO) Standards 9001 (ISO/IEC 2008), Telecom Quality Management System Standards (TL 9000) (QuEST Forum 2012), Information Technology Infrastructure Library (ITIL) v. 3 (OGC 2009), etc.). <br />
<br />
As discussed earlier, QoS needs to correlate customer perceived quality (subjective measures) with objective SPM and TPM measures. There are several techniques available to help monitor, measure, and assess TPM’s, but most are a variation on the theme of culling information from TPM’s using, for example, perceptual speech quality measure (PSQM) and perceptual evaluation of video quality (PEVQ) and enhancing or verifying this information with customer or end-user perception of service by extending mean opinion score (MOS) techniques/customer opinion models (Bell System 1984). Telecommunication systems engineering (TCSE) played an important role in finding methodologies for correlation between perception and objective measures for the services of the twentieth century; SSE should continue to encourage multidisciplinary participation to equally find methodologies, processes, and tools to correlate perceived service quality with TPM and with SPM for the services of the twenty-first century (Freeman 2004). <br />
<br />
Subjective (qualitative) service quality is the customer’s perceived conformity of the service with the expected objective. Word-of-mouth, personal needs, and past experiences create customer expectations regarding the service. The customers' perception of the service must be captured via surveys and interviews. The customers' perception of the service is then compared with their expectations for the service; this process captures the perceived service quality. Care should be taken to understand that subjective measures appear to measure customer attitudes, and attitudes may be the result of several encounters with the service, as well as numerous encounters with similar services.<br />
<br />
In summary, the SLA documents the SLRs and establishes reliable and valid service performance measures, technical parameters, and the agreed performance levels for the technical parameters. The technical parameters are then monitored and continuously compared against both objective and subjective data culled from multiple internal and external sources (service level management). The goal is not to report the level of service in a given period, but to develop and implement a dynamic system capable of predicting and driving service level improvement over time (i.e., continual service improvement (CSI)).<br />
<br />
==Evolution of Services==<br />
<br />
The second, third, and fourth decades of the twenty-first century will almost certainly see similar, and probably accelerated, technology development as seen in the prior three decades. Mass collaboration will become an established mode of operation. The beginnings of mass collaboration have manifested in developments such as value co-creation where loosely entangled actors or entities come together to create value in unprecedented ways, but ways that meet mutual and broader market requirements. Further developments in the technology, use, and acceptance of social media will continue to fuel the acceleration of these developments. <br />
<br />
The next decades will see the grounding of concepts, such as crowdsourcing, coined by Jeff Howe in a June 2006 Wired magazine article; open innovation, promoted by Henry Chesbrough, a professor and executive director at the Center for Open Innovation at Berkeley; and mass collaboration and open source innovation supported by Enterprise 2.0 tools, as conceived by Wikinomics consultant Don Tapscott.<br />
<br />
Roberto Saracco, a telecommunications expert specializing in analyzing economical impacts of technology evolution, argues that: “Communications will be the invisible fabric connecting us and the world whenever and wherever we happen to be in a completely seamless way, connecting us so transparently, cheaply, and effortlessly that very seldom will we think about it.” The ubiquity and invisibility of these communications will greatly facilitate the creation and destruction of ad hoc collectives (groups of entities that share or are motivated by at least one common issue or interest, or work together on a specific project(s) to achieve a common objective). This enterprise may engender the concept of the hive mind (the collective intelligence of many), which will be an intelligent version of real-life super organisms, such as ant or bee nests (Hölldobler and Wilson 2009). <br />
<br />
These models will most certainly give rise to issues of property rights and liabilities; access rights for both the provider and the customer can be owned outright, contracted/leased, shared, or have privileged access (Spohrer 2011). For now, we are on the cusp of a management revolution that is likely to be as profound and unsettling as the one that gave birth to the modern industrial age. Driven by the emergence of powerful new collaborative technologies, this transformation will radically reshape the nature of work, the boundaries of the enterprise, and the responsibilities of business [[Leader (glossary)|leaders]] (McAfee 2009).<br />
<br />
The service-providing industry in the US is divided into thirteen sectors (Chang 2010):<br />
<br />
#professional and business services,<br />
#healthcare and social assistance,<br />
#state and local government,<br />
#leisure and hospitality,<br />
#other services,<br />
#educational services,<br />
#retail trade,<br />
#financial activities,<br />
#transportation and warehousing,<br />
#wholesale trade,<br />
#information,<br />
#federal government, and<br />
#utilities.<br />
<br />
Spohrer (2011) goes beyond the service sectors to propose three types of service systems: <br />
<br />
#'''''Systems that focus on flow of things''''': transportation and supply chains, water and waste recycling, food and products, energy and electric Grid, information/ICT & cloud;<br />
#'''''Systems that focus on Human Activities and Development''''': buildings and construction, retail and hospitality / media and entertainment industries, banking and finance / business consulting industries, healthcare and family life systems, education and work life / jobs and entrepreneurship; and<br />
#'''''Systems that focus on Governing''''': cities, states, and nations.<br />
<br />
Categorizing types and sectors of services is an important beginning because it can lead to a better understanding of the emerging rules and relationships in service value chains. This approach can further enhance the value co-creation capabilities of innovative service concepts that contribute to our quality of life. The classification also helps in identifying different objectives and constraints for the design and operations of the service system. Some examples include strategic policies under limited budget: education, strategic with readiness for quick response; national defense; business enterprise, maximizing profit while minimizing cost; etc.<br />
<br />
In addition, this classification is being used to determine the overlap and synergies required among different science disciplines to enable trans-disciplinary collaboration and educational programs.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Badr, Y., A. Abraham, F. Biennier, and C. Grosan. 2008. "Enhancing Web Service Selection by User Preferences of Non-Functional Features." Presented at 4th International Conference on Next Generation Web Services Practices, October 20-22, Seoul, South Korea.<br />
<br />
Chang, C.M. 2010. ''Service Systems Management and Engineering, Creating Strategic Differentiation and Operational Excellence.'' New York, NY, USA: John Wiley & Sons, Inc.<br />
<br />
Daskin, M.S. 2010. ''Service Science.'' New York, NY, USA: John Wiley & Sons.<br />
<br />
Freeman, R.L. 2004. ''[[Telecommunication Systems Engineering]],'' 4th ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Hölldobler, B. and E.O. Wilson. 2009. ''The Super-organism: The Beauty, Elegance, and Strangeness of Insect Societies.'' New York, NY, USA: W.W. Norton & Company.<br />
<br />
ISO. 2008. ''Quality management systems -- Requirements.'' Geneva, Switzerland: International Organisation for Standardisation. ISO 9001:2008.<br />
<br />
McAfee, A. 2009. ''Enterprise 2.0: New Collaborative Tools for Your Organization's Toughest Challenges.'' Boston, MA, USA: Harvard Business School Press.<br />
<br />
OGC (Office of Government Commerce). 2009. ''[[ITIL Lifecycle Publication Suite Books]].'' London, UK: The Stationery Office.<br />
<br />
QuEST Forum. 2012. ''Quality Management System (QMS) Measurements Handbook,'' Release 5.0. Plano, TX, USA: Quest Forum. <br />
<br />
Ray, R.F. (ed). 1984. ''Engineering and Operations in Bell System'', 2nd ed. Florham Park, NJ, USA: AT&T Bell Labs.<br />
<br />
SEI. 2007. ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).<br />
<br />
Spohrer, J.C. 2011. "Service Science: Progress & Directions." Presented at the International Joint Conference on Service Science, 25-27 May 2011, Taipei, Taiwan.<br />
<br />
Theilmann, W. and Baresi, L. 2009. "Chapter: [[Multi-level SLAs for Harmonized Management in the Future Internet]]." In ''Towards the Future Internet- A European Research Perspective,'' edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
Tien, J,M. and D. Berg. 2003. "[[A Case for Service Systems Engineering]]." ''Journal of Systems Science and Systems Engineering.'' 12(1): 13-38.<br />
<br />
===Primary References===<br />
<br />
Chang, C.M. 2010. ''[[Service Systems Management and Engineering]], Creating Strategic Differentiation and Operational Excellence.'' New York, NY, USA: John Wiley & Sons, Inc. <br />
<br />
Theilmann, W. and Baresi, L. 2009. "Chapter : [[Multi-level SLAs for Harmonized Management in the Future Internet]]." In ''Towards the Future Internet- A European Research Perspective,'' edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
===Additional References===<br />
None. <br />
----<br />
<center>[[Fundamentals of Services|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Scope of Service Systems Engineering|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Properties_of_Services&diff=46794
Properties of Services
2012-11-28T15:54:28Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>A [[Service (glossary)|service]] is realized by the [[Service System (glossary)|service system]] through the relationships of service system entities that interact (or relate) in a particular way to deliver the specific service via a service level agreement (SLA). Current management frameworks typically only focus on the interfaces of single service system entities. Meanwhile, SLAs are mapped to the respective [[Customer (glossary)|customer]] [[Requirement (glossary)|requirements]]. These policies are provider-specific means to express constraints and rules for their internal operations. These rules may be independent of any particular customer (Theilmann 2009). <br />
<br />
Services not only involve the interaction between the service provider and the consumer to produce [[Value (glossary)|value]], but have other attributes, like an intangible [[Quality (glossary)|quality]] of service (e.g., an ambulance service's availability and response time to an emergency request). The demand for a service may have varying loads dependent on the time of day, day of week, season, or other unexpected needs (e.g., natural disasters, [[Product (glossary)|product]] promotion campaigns, etc.). In the US for instance, travel services have peak demands during Christmas week; Mother’s day is usually the highest volume handling day for a telecommunications provider and tax services peak during extended periods (January through mid-April). Services cannot be inventoried; they are rendered at the time they are requested. <br />
<br />
Additionally, for a [[Business (glossary)|business]] [[Enterprise (glossary)|enterprise]], delivering the service at the minimum [[Cost (glossary)|cost]] while maximizing its profits may be the service objective. In contrast, for a non-profit [[Organization (glossary)|organization]] the objective may be to maximize [[Customer (glossary)|customer]] satisfaction while optimizing the resources required to render the service (e.g., during a natural disaster). Thus, the design and operations of service systems “is all about finding the appropriate balance between the resources devoted to the [[System (glossary)|systems]] and the demands placed on the system so that the quality of service to the customer is as good as possible” (Daskin 2010).<br />
<br />
==Service Level Agreement==<br />
<br />
A SLA is a set of technical (functional) and non-technical (non-functional) parameters agreed among customers and service providers. SLAs can and do contain administrative level (non-functional) business related parameters, such as SLA duration, service availability for the SLA duration, consequences for variations, failure reporting, priorities, and provisions for modifications to the SLA. However, for service level management, the service level (technical) parameters need to be defined, monitored, and assessed; these parameters may include such things as throughput; quality; availability; security; performance; reliability, for example, mean time between failure (MTBF), maximum downtime, and time-to-repair; and resource allocation. <br />
<br />
An SLA represents the negotiated service level requirements (SLR) of the customer and should establish valid and reliable service performance [[Measure (glossary)|measures]] since it is usually the basis for effective service level management (SLM). The goal of SLM is to ensure that service providers meet and maintain the prescribed quality of service (QoS). However, care should be taken since in some domains the term QoS refers only to resource reservation control mechanisms rather than the achieved service quality (e.g., internet protocol (IP) networks). Some terms used to mean the “achieved service quality” include quality of experience (QoE), user-perceived performance, and degree of satisfaction of the user; these other terms are more generally used across service domains.<br />
<br />
Non-functional properties fall into two basic categories: business properties, such as price and method of payment, and environmental properties, such as time and location. Business and environmental properties are classified as “context properties” by Youakim Badr (Badr et al. 2008). QoS properties are characteristics such as [[Availability (glossary)|availability]], [[Resilience (glossary)|resilience]], [[Security (glossary)|security]], [[Reliability (glossary)|reliability]], [[Scalability (glossary)|scalability]], agreement duration, response times, repair times, usability, etc. Therefore services evaluation measures are customer oriented and include not only traditional performance metrics (productivity, quality, etc.), but also require a comprehensive analysis of the service system from an end-to-end perspective. Service evaluation typically includes customer demand-supply to ensure economic viability across the lifecycle of the service system. Furthermore, the service delivery is evaluated using the key technical performance metrics listed above, adding also Service Process Measures (provisioning time, time-to-restore/repair, etc.) and Technical Performance Measures (end-to-end response times, latency, throughput, etc.). Finally, the service system’s SLAs are then the composition of these categories evaluated on a systemic level to ensure consistency, equity, and sustainability of the service to assure that the desired/contracted SLA for customer satisfaction, value co-creation, and high system robustness are realized. (Spohrer 2011; Tien and Berg 2003; Theilmann and Baresi, 2009)<br />
<br />
==Service Key Performance Indicators==<br />
<br />
Service key performance indicators (KPI) are defined and agreed to in the SLA; the service KPIs are decomposed into service process measures (SPM) and technical performance measures (TPM) during the analysis stage of the service systems engineering (SSE) process. In the design process, the KPIs and TPM are allocated to service system entities and their [[Component (glossary)|components]], as well as to the business processes and their components so as to ensure compliance with SLAs. The allocated measures generate [[Derived Requirement (glossary)|derived requirements]] (SLR) for the system entities and their relationships, as well as for the service entities' components and the data and information flows required in the service systems to monitor, measure, and assess end-to-end SLA. These allocations ensure that the appropriate performance indicators apply to each of the links in the service value chain. <br />
<br />
TPMs are typically categorized by the number of defective parts in a manufacturing service, data transmission [[Latent (glossary)|latency]] and data throughput in an end-to-end application service, IP QoS expressed by latency, jitter delay, and throughput; SPMs are typically categorized by service provisioning time, end-to-end response times to a service request (a combination of data and objective feedback), and quality of experience (QoE verified by objective feedback). Together, the KPI (TPM combined with SPM) and perception measures make up the service level management function. A quality assurance system's (QAS) continuous service improvement (CSI), processes, and process quality management and improvement (PQMI) should be planned, designed, deployed, and managed for the [[Capability (glossary)|capability]] to continuously improve the service system and to monitor compliance with SLAs (e.g., PQMI, capability maturity model integration (CMMI) (SEI 2007), International Organization for Standardization (ISO) Standards 9001 (ISO/IEC 2008), Telecom Quality Management System Standards (TL 9000), Information Technology Infrastructure Library (ITIL) v. 3 (OGC 2009), etc.). <br />
<br />
As discussed earlier, QoS needs to correlate customer perceived quality (subjective measures) with objective SPM and TPM measures. There are several techniques available to help monitor, measure, and assess TPM’s, but most are a variation on the theme of culling information from TPM’s using, for example, perceptual speech quality measure (PSQM) and perceptual evaluation of video quality (PEVQ) and enhancing or verifying this information with customer or end-user perception of service by extending mean opinion score (MOS) techniques/customer opinion models (Bell System 1984). Telecommunication systems engineering (TCSE) played an important role in finding methodologies for correlation between perception and objective measures for the services of the twentieth century; SSE should continue to encourage multidisciplinary participation to equally find methodologies, processes, and tools to correlate perceived service quality with TPM and with SPM for the services of the twenty-first century (Freeman 2004). <br />
<br />
Subjective (qualitative) service quality is the customer’s perceived conformity of the service with the expected objective. Word-of-mouth, personal needs, and past experiences create customer expectations regarding the service. The customers' perception of the service must be captured via surveys and interviews. The customers' perception of the service is then compared with their expectations for the service; this process captures the perceived service quality. Care should be taken to understand that subjective measures appear to measure customer attitudes, and attitudes may be the result of several encounters with the service, as well as numerous encounters with similar services.<br />
<br />
In summary, the SLA documents the SLRs and establishes reliable and valid service performance measures, technical parameters, and the agreed performance levels for the technical parameters. The technical parameters are then monitored and continuously compared against both objective and subjective data culled from multiple internal and external sources (service level management). The goal is not to report the level of service in a given period, but to develop and implement a dynamic system capable of predicting and driving service level improvement over time (i.e., continual service improvement (CSI)).<br />
<br />
==Evolution of Services==<br />
<br />
The second, third, and fourth decades of the twenty-first century will almost certainly see similar, and probably accelerated, technology development as seen in the prior three decades. Mass collaboration will become an established mode of operation. The beginnings of mass collaboration have manifested in developments such as value co-creation where loosely entangled actors or entities come together to create value in unprecedented ways, but ways that meet mutual and broader market requirements. Further developments in the technology, use, and acceptance of social media will continue to fuel the acceleration of these developments. <br />
<br />
The next decades will see the grounding of concepts, such as crowdsourcing, coined by Jeff Howe in a June 2006 Wired magazine article; open innovation, promoted by Henry Chesbrough, a professor and executive director at the Center for Open Innovation at Berkeley; and mass collaboration and open source innovation supported by Enterprise 2.0 tools, as conceived by Wikinomics consultant Don Tapscott.<br />
<br />
Roberto Saracco, a telecommunications expert specializing in analyzing economical impacts of technology evolution, argues that: “Communications will be the invisible fabric connecting us and the world whenever and wherever we happen to be in a completely seamless way, connecting us so transparently, cheaply, and effortlessly that very seldom will we think about it.” The ubiquity and invisibility of these communications will greatly facilitate the creation and destruction of ad hoc collectives (groups of entities that share or are motivated by at least one common issue or interest, or work together on a specific project(s) to achieve a common objective). This enterprise may engender the concept of the hive mind (the collective intelligence of many), which will be an intelligent version of real-life super organisms, such as ant or bee nests (Hölldobler and Wilson 2009). <br />
<br />
These models will most certainly give rise to issues of property rights and liabilities; access rights for both the provider and the customer can be owned outright, contracted/leased, shared, or have privileged access (Spohrer 2011). For now, we are on the cusp of a management revolution that is likely to be as profound and unsettling as the one that gave birth to the modern industrial age. Driven by the emergence of powerful new collaborative technologies, this transformation will radically reshape the nature of work, the boundaries of the enterprise, and the responsibilities of business [[Leader (glossary)|leaders]] (McAfee 2009).<br />
<br />
The service-providing industry in the US is divided into thirteen sectors (Chang 2010):<br />
<br />
#professional and business services,<br />
#healthcare and social assistance,<br />
#state and local government,<br />
#leisure and hospitality,<br />
#other services,<br />
#educational services,<br />
#retail trade,<br />
#financial activities,<br />
#transportation and warehousing,<br />
#wholesale trade,<br />
#information,<br />
#federal government, and<br />
#utilities.<br />
<br />
Spohrer (2011) goes beyond the service sectors to propose three types of service systems: <br />
<br />
#'''''Systems that focus on flow of things''''': transportation and supply chains, water and waste recycling, food and products, energy and electric Grid, information/ICT & cloud;<br />
#'''''Systems that focus on Human Activities and Development''''': buildings and construction, retail and hospitality / media and entertainment industries, banking and finance / business consulting industries, healthcare and family life systems, education and work life / jobs and entrepreneurship; and<br />
#'''''Systems that focus on Governing''''': cities, states, and nations.<br />
<br />
Categorizing types and sectors of services is an important beginning because it can lead to a better understanding of the emerging rules and relationships in service value chains. This approach can further enhance the value co-creation capabilities of innovative service concepts that contribute to our quality of life. The classification also helps in identifying different objectives and constraints for the design and operations of the service system. Some examples include strategic policies under limited budget: education, strategic with readiness for quick response; national defense; business enterprise, maximizing profit while minimizing cost; etc.<br />
<br />
In addition, this classification is being used to determine the overlap and synergies required among different science disciplines to enable trans-disciplinary collaboration and educational programs.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Badr, Y., A. Abraham, F. Biennier, and C. Grosan. 2008. "Enhancing Web Service Selection by User Preferences of Non-Functional Features." Presented at 4th International Conference on Next Generation Web Services Practices, October 20-22, Seoul, South Korea.<br />
<br />
Chang, C.M. 2010. ''Service Systems Management and Engineering, Creating Strategic Differentiation and Operational Excellence.'' New York, NY, USA: John Wiley & Sons, Inc.<br />
<br />
Daskin, M.S. 2010. ''Service Science.'' New York, NY, USA: John Wiley & Sons.<br />
<br />
Freeman, R.L. 2004. ''[[Telecommunication Systems Engineering]],'' 4th ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Hölldobler, B. and E.O. Wilson. 2009. ''The Super-organism: The Beauty, Elegance, and Strangeness of Insect Societies.'' New York, NY, USA: W.W. Norton & Company.<br />
<br />
ISO. 2008. ''Quality management systems -- Requirements.'' Geneva, Switzerland: International Organisation for Standardisation. ISO 9001:2008.<br />
<br />
McAfee, A. 2009. ''Enterprise 2.0: New Collaborative Tools for Your Organization's Toughest Challenges.'' Boston, MA, USA: Harvard Business School Press.<br />
<br />
OGC (Office of Government Commerce). 2009. ''[[ITIL Lifecycle Publication Suite Books]].'' London, UK: The Stationery Office.<br />
<br />
QuEST Forum. 2012. ''Quality Management System (QMS) Measurements Handbook,'' Release 5.0. Plano, TX, USA: Quest Forum. <br />
<br />
Ray, R.F. (ed). 1984. ''Engineering and Operations in Bell System'', 2nd ed. Florham Park, NJ, USA: AT&T Bell Labs.<br />
<br />
SEI. 2007. ''Capability Maturity Model Integrated (CMMI) for Development'', version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).<br />
<br />
Spohrer, J.C. 2011. "Service Science: Progress & Directions." Presented at the International Joint Conference on Service Science, 25-27 May 2011, Taipei, Taiwan.<br />
<br />
Theilmann, W. and Baresi, L. 2009. "Chapter: [[Multi-level SLAs for Harmonized Management in the Future Internet]]." In ''Towards the Future Internet- A European Research Perspective,'' edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
Tien, J,M. and D. Berg. 2003. "[[A Case for Service Systems Engineering]]." ''Journal of Systems Science and Systems Engineering.'' 12(1): 13-38.<br />
<br />
===Primary References===<br />
<br />
Chang, C.M. 2010. ''[[Service Systems Management and Engineering]], Creating Strategic Differentiation and Operational Excellence.'' New York, NY, USA: John Wiley & Sons, Inc. <br />
<br />
Theilmann, W. and Baresi, L. 2009. "Chapter : [[Multi-level SLAs for Harmonized Management in the Future Internet]]." In ''Towards the Future Internet- A European Research Perspective,'' edited by G. Tselentis, J. Domingue, A. Galis, A. Gavras, D. Hausheer, S. Krco, V. Lotz, and T. Zehariadis. Amsterdam, The Netherlands: IOS Press.<br />
<br />
===Additional References===<br />
None. <br />
----<br />
<center>[[Fundamentals of Services|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Scope of Service Systems Engineering|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=46784
Service Systems Engineering Stages
2012-11-28T15:47:15Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>This article describes the stages of the service systems development process (SSDP) and expected outputs for each stage; for a closer alignment with the traditional systems engineering (TSE) process, the concept and feasibility phases have been combined into a single service strategy/concept as discussed in the SEBoK [[Systems Engineering and Management]] article. All of the stages of the SSDP take a similar iterative approach to fully understand the [[enterprise (glossary)]] [[Capability (glossary)|capabilities]], enterprise process impact, [[Information Technology (glossary)|information technology]] (IT), and technology impacts and [[customer (glossary)]] expectations. Lin and Hsieh (2011) provide a good summary on New service Development processes. The Information Technology Infrastructure Library (ITIL) stage names have been purposely added to the SSDP to show the needed alignment between IT and technology. The reader should keep in mind that even though IT is crucial to the overall end-to-end system, service technology development needs must be taken into consideration in all the stages of SSDP.<br />
<br />
==Service Strategy/Concept==<br />
<br />
A service strategy/concept is the entry into the SSDP. The concept may be generated by an end-[[User (glossary)|user]] (enterprise customer or consumer), a business manager, an [[Engineering (glossary)|engineering]] organization, new web service designers, new technology developments, and/or information technology trends. The service concept is the highest level of the service idea and it usually addresses what service is being proposed to what markets and to whom within these markets. <br />
<br />
A high-level feasibility assessment of the concept is then carried out by the integrated service development team (ISDT) to assess the needs/impacts on enterprise process [[Capability (glossary)|capabilities]], [[Operational (glossary)|operational]] capabilities, and/or new technology developments (access, infrastructure, operations support systems (OSS), service support systems (SSS), and business support systems (BSS). It should also consider any impacts on service [[Governance (glossary)|governance]], social, cultural, and human behaviors. The feasibility assessment also gives a plus or minus 30% estimate on the time to develop and the [[Cost (glossary)|cost]] of development, which are entry points into the business case to evaluate whether the service is viable to develop and to market given the [[Constraint (glossary)|constraints]] and estimates. At this time, a decision ([[Decision Gate (glossary)|decision gate]]) determines if the service is to be developed.<br />
<br />
If the business case is viable, then a detailed business description of the service is developed. This includes functions and features to be included, phases of development, markets to be addressed, customers within the markets to be targeted, and customer experiences expected from the service (i.e., defining the [[Non-Functional Requirements (glossary)|non-functional requirements]] of the service, such as the [[Quality (glossary)|quality]] of service (QoS), [[Availability (glossary)|availability]], [[Reliability (glossary)|reliability]], and [[Security (glossary)|security]] considerations and offerings within the service). This description allows detailed studies of expected human-computer interactions, social networking, technology requirements, and operations requirements. Governance and organizational process requirements should also be included to generate the “service description” as the main output from this stage. <br />
<br />
Service systems engineering (SSE) takes an important role in understanding and eliciting the enterprise service concepts. Clearly, understood end-to-end business processes required for the intended service are fundamental to its successful development, deployment, and customer satisfaction. SSE works with business process management (BPM), social science, and cognitive science to elicit intended service operations, including target audiences, pre-sale, sale, and post-sale customer care processes.<br />
<br />
==Requirements Analysis and Engineering==<br />
<br />
A service requirements document is created that describes the service functions, the service entities, the intended interaction among entities, and the customer-facing and internal-facing functions/processes that are required to support the service. This description should conceptually include intended service level agreements (SLAs) and the obligations of the service provider process should there be any degree of non-compliance during service operation. <br />
<br />
In addition to the TSE activities described earlier, the SSE requirements analysis and engineering process must develop a customer-centric view of the service to analyze SLA, QoS, value co-creation, monitoring, and assessment requirements to comply with the expected/planned SLA. This analysis will determine whether dynamic changes of the service are required during service operation to correct faults, reconfigure, administer, or to adapt/self-adapt for possible performance degradations.<br />
<br />
Beyond the traditional service life cycle management (LCM) processes, the requirements must also be developed for service level management (SLM) processes and systems. These are needed to monitor, measure, and assess key performance indicators (KPIs), [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] (TPMs), and service performance measures (SPMs) according to the SLA. <br />
<br />
The SSE requirements analysis addresses the support systems for the [[governance (glossary)]], business, service, operations, and support processes to derive requirements for technologies, information systems, processes, and enterprise organizations. Interface requirements, information flows, and data requirements are also within the scope of requirements analysis. The main output is the service requirements document (SRD).<br />
<br />
SSE plays a critical role in describing the services needs for day-to-day operations. These include customer care centers requirements and interfaces between network infrastructure provider(s), content provider(s), service provider(s), service based application provider(s), and the customer management process for the service. All of these are described in detail in the service operations plans (SOPs) and the operations technical plans (OTPs).<br />
<br />
==Systems Design/Development==<br />
<br />
The SRD, SOP, and OTP have enough detail regarding the service functions, operations, interfaces, and information flows required among the different service system entities to analyze, identify, and recommend end-to-end applicable architecture frameworks; to carry out trade-off analyses for the alternatives among service system entities; and to describe and allocate relationships (interactions) among entities at all levels of the service architecture. Detailed requirements are worked at lower levels to generate specifications for entity developers including data structures, data flow diagrams, and allocated performance requirements. <br />
<br />
ITIL v. 3 (OGC 2009) recommends inclusion of the following service design processes:<br />
<br />
*service catalog management,<br />
*service level management, <br />
*[[Capacity (glossary)|capacity]] management,<br />
*availability management,<br />
*service continuity management,<br />
*security management, and<br />
*supplier/provider management.<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)|integration]] and interface requirements for the seamless operation of the service. In this regard, the system engineer takes an integrator role to ensure proper data generation and flow through all the different systems composing the service offered. The goal is to ensure customers (consumer or internal) are getting the information required to carry out the tasks required in the business, operations, service, and customer processes. The service [[Integration, Verification, and Validation (IV&V) (glossary)|integration, verification, and validation]] (IV&V) plans need to include end-to-end [[Verification (glossary)|verification]] and [[Validation (glossary)|validation]] procedures for any new development or adaptations required for planned dynamic configuration/re-configuration of previously tested service systems. (See also [[System Verification]] and [[System Validation]].)<br />
<br />
The systems engineer creates the IV&V plans using a number of different perspectives. These include<br />
<br />
*end-to-end service (service validation test plans),<br />
*customer care (operational readiness test plans),<br />
*service provider (network validation test plans),<br />
*service system entities interoperability/interface test plans,<br />
*content provider (content validation test plans), and<br />
*application (user acceptance test plans).<br />
<br />
==Service Transition/Deployment==<br />
<br />
Service systems may change very rapidly and new enhancements, new features, or new applications can be added as incremental developments, new developments, or adaptation to service offerings. Service systems engineers review new requirements to assess the feasibility of the changes to the service system entities, technologies, processes, and organizations, as well as their impacts on the service offerings. The service transition/deployment stage takes input from service development to plan for service insertion, technology insertion, processes adaptations, and implementation with minimal impact to existing services. During this stage, special care is taken with IV&V test plans and regression testing to ensure new developments work flawlessly with existing services. <br />
<br />
ITIL v. 3 (OGC 2009) recommends the following processes in the transition/deployment stage:<br />
<br />
*transition planning and support,<br />
*change management,<br />
*service asset and configuration management,<br />
*release and deployment management,<br />
*service validation and testing,<br />
*evaluation, and<br />
*knowledge management.<br />
<br />
==Service Operations/Continuous Service Improvement (CSI)==<br />
<br />
Service operation manages the day-to-day activities of all aspects of the end-to-end service delivery to the customer. It manages the operations, administration, maintenance, and provisioning of the service, technology, and infrastructure required to deliver the contracted service to the customer within the specified service levels. The main service operations processes in ITIL v. 3 are<br />
<br />
*event management,<br />
*incident management,<br />
*problem management,<br />
*request fulfillment, and<br />
*access management.<br />
<br />
A continuous service improvement (CSI) plan for the implementation of technologies and tools for the continuous improvement of the service, monitoring, measuring, and analyzing process and service metrics is essential.<br />
<br />
==Service Systems Engineering Tools & Technologies==<br />
<br />
Tools and technologies from a broad spectrum of fields are extensively used during the different stages of SSE. Not only are they used for the development of the hardware, software, information systems and technology components, but also for the modelling, definition, and [[Design (glossary)|design]] of the organization, processes, and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include modelling, [[Simulation (glossary)|simulation]], development, test bed, and social environmental aspects of the intended or to be designed service. The tools fall into three main domains:<br />
#business process management (BPM),<br />
#service design process, and<br />
#service design management.<br />
<br />
'''Business process management (BPM)''' generally deals with process management scenarios to coordinate people and systems, including sequential workflow, straight through processing, case management, content life cycle management, collaborative process work, and value chain participation. Systems engineers work with service managers to align the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation (BPMN) is a graphic notation standard that is implemented to describe a process’s realization within any given workflow. This notation is linked with web services business process execution language (WS-BPEL), a format used to perform an automated business process by implementing web services technology. For an extensive review of existing BPM tools and BPM suites, please see Hantry et al. (2010), Carroll et al. (2010), Andrikoupolous et al. (2010), Lin and Hsieh (2011), and Ward-Dutton (2010).<br />
<br />
'''Service design process''': Architecture frameworks (AF) and enterprise architectures (EAs) are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)|complex]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)|products]] and services. Systems engineering modeling tools, such as the unified modeling language (UML) (OMG 2010a) and system modeling language (SysML) (OMG 2010b), help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service oriented architecture (SOA) and systems and software engineering architecture (ISO/IEC/IEEE 2011) are standards that apply architecture principles for specialized applications. Successful implementation of the architecture tools helps identify critical interfaces and improves understanding of the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)|Mode-based systems engineering]] (MBSE), model driven architectures (MDA), and model oriented systems engineering (MOSES) are examples of commonly used tools for logical (functional), behavioral (operational), and physical design of the IT. UML, UML 2.0, and SysML are extensively used to describe operational scenarios, modes of operations, use cases, and entity relationships. For an extensive review of MBSE, MDA, and MOSES, please see Friedenthal (1998), Estefan (2008), Pezuela (2005), Andrikopoulos et al. (2010), and Hybertson (2010).<br />
<br />
In addition, trade-off and engineering analyses use different optimization methodologies. Since services exhibit a significant level of randomness, statistical analysis, demand forecasting, multi-objective optimization, queuing theory, and stochastic optimization methodologies are tools used to model and simulate the service system behavior. These methodologies support decision making in areas as diverse as resource allocation, number of facilities, facilities' geographical locations, fleet routing and optimization, service systems reliability and prognosis, and network optimization. A good overview of these methodologies can be found in Daskin (2010).<br />
<br />
During the service design process (SDP), planning for the implementation of technologies and tools for the continuous improvement of the service is performed. These tools support monitoring, measuring, and analyzing process and service performance metrics. The Deming cycle (plan, do, check, and act (PDCA) is widely used as the foundation for [[Quality (glossary)|quality]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] manufacturing, [[Six Sigma (glossary)|six sigma]], swim lanes, balanced scoreboard, benchmarking, and gap analysis methodologies are commonly used for service evaluation and continuous improvement.<br />
<br />
'''Service design management''': There are standards for implementing and managing systems engineering processes (IEEE 1220 (1998)) that help coordinate and synchronize all the service systems engineering processes leading to improved organizational collaboration and improved service delivery (see also [[Systems Engineering Standards]]). Standards have been developed in software engineering for product evaluation (ISO/IEC 14598 (1998)) and product quality (ISO/IEC 9126 series (2003a, 2003b, & 2004)), as well as information security management (ISO 27001 (2005)) and evaluation series (ISO 15408 (2008a, 2008b, & 2009). The ITIL v. 3 describes best practices for IT service management, which can be extended to include service systems.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Adams, S., A. Cartlidge, A. Hanna, S. Rance, J. Sowerby, J. Windebank. 2009. ''ITIL V3 Foundation Handbook.'' London, England. The Stationary Office: 44. ISBN 9780113311989<br />
<br />
Andrikopoulos, V., A. Bucchiarone, E. Di Nitto, R. Kazhamiakin, S. Lane, V. Mazza, and I. Richardson. 2010. "Chapter 8: Service Engineering." Papazoglou, M.; Pohl, K.; Parkin, M.; Metzger, A. (Eds.) . ''"Service Research Challenges and Solutions for the Future Internet S-Cube – Towards Engineering, Managing and Adapting Service-Based Systems"'' Berlin Heidelberg, Germany: Springer-Verlag: 271-337.<br />
<br />
Carroll, N., E. Whelan, and I. Richardson. "Applying Social Network Analysis to Discover Service Innovation within Agile Service Networks." ''Service Science 2'' (4): 225-244.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]]'', rev, B. Seattle, WA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at: http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf<br />
<br />
Friedenthal, S. 1998. "Object Oriented System Engineering: Process Integration for 2000 and beyond." Presented at System Engineering & Software Symposium. New Orleans, LA: Lockheed Martin Corporation. <br />
<br />
Hantry, F., M.P. Papazoglou, W. van den Heuvel, R. Haque, E. Whelan, N. Carroll, D. Karastoyanova, F. Leymann, C. Nikolaou, W. Lamersdorf, and M. Hacid. 2010. "Chapter: Business Process Management." in Papazoglou, M.P., K. Pohl, M. Parkin, A. Metzger (eds.) . ''Service Research Challenges and Solutions for the Future Internet S-Cube – Towards Engineering, Managing and Adapting Service-Based Systems.'' Berlin Heidelberg, Germany: Springer-Verlag: 27-54.<br />
<br />
Hybertson, D.W. 2009. ''[[Model-Oriented Systems Engineering Science]]: A Unifying Framework for Traditional and Complex Systems.'' Boston, MA, USA: Auerbach Publications. ISBN # 978-1-4200-7251-8.<br />
<br />
IEEE. 1998. ''IEEE Standard for Application and Management of the Systems Engineering Process''. Washington, DC: Institute of Electrical and Electronics Engineers (IEEE), IEEE 1220-1998.<br />
<br />
ISO/IEC. 1998. ''Information technology — Part 5: Process for evaluators.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 14598-5:1998.<br />
<br />
ISO/IEC. 2003a. ''Software engineering — Product quality — Part 2: External metrics.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC TR 9126-2:2003.<br />
<br />
ISO/IEC. 2003b. ''Software engineering — Product quality — Part 3: Internal metrics.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC TR 9126-3:2003.<br />
<br />
ISO/IEC. 2004. ''Software engineering — Product quality — Part 4: Quality in use metrics.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC TR 9126-4:2004.<br />
<br />
ISO/IEC. 2005. ''Information technology — Security techniques — Information security management systems — Requirements.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 27001:2005.<br />
<br />
ISO/IEC. 2008a. ''Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15408-2:2008.<br />
<br />
ISO/IEC. 2008b. ''Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance components.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15408-3:2008.<br />
<br />
ISO/IEC. 2009. ''Information technology — Security techniques — Evaluation criteria for IT security — <br />
Part 1: Introduction and general model.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15408-1:2009.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering — Architecture description.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 42010:2011.<br />
<br />
Lefever, B. 2005. [[SeSCE Methodology]]. SeCSE Service Centric Systems Engineering. SeCSE511680. Available at: http://www.secse-project.eu/wp-content/uploads/2007/08/a5_d4-secse-methodology-v1_3.pdf<br />
<br />
Lin, F. and P. Hsieh. 2011. "A SAT View on New Service Development." ''Service Science'' 3(2): 141-157.<br />
<br />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<br />
<br />
OMG. 2010a. ''Unified Modeling Language™ (UML),'' Version 2.. Needham, MA, USA: Object Management Group. Available at http://www.omg.org/spec/UML/.<br />
<br />
OMG. 2010b. ''OMG Systems Modeling Language (SysML),'' Version 1.2. Needham, MA, USA: Object Management Group. Available at http://www.sysml.org/docs/specs/OMGSysML-v1.2-10-06-02.pdf.<br />
<br />
Pezuela, C., 2005. "Collection of Existing Service Centric Prototypes." Report A5.D1 Brussels, Belgium: European Union, Information Society Technology. http://www.secse-project.eu/wp-content/uploads/2007/08/a5d1-collection-of-existing-service-centric-prototypes.pdf Accessed on September 5, 2011.<br />
<br />
Ward-Dutton, N. 2010. "BPM Technology: Vendor Capability Comparison." MWD Premium Advisory Report. Horsham, West Sussex, UK: Macehiter Ward-Dutton (MWD) Limited. MWD Advisors. http://www.mwdadvisors.com/library/detail.php?id=380 Accessed September 5, 2011.<br />
<br />
===Primary References===<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]]'', rev, B. Seattle, WA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at: http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf<br />
<br />
Hybertson, D.W. 2009. ''[[Model-Oriented Systems Engineering Science]]: A Unifying Framework for Traditional and Complex Systems.'' Boston, MA, USA: Auerbach Publications. ISBN # 978-1-4200-7251-8.<br />
<br />
Lefever, B. 2005. [[SeSCE Methodology]]. Rome, Italy: SeCSE Service Centric Systems Engineering. SeCSE511680. Available at: http://www.secse-project.eu/wp-content/uploads/2007/08/a5_d4-secse-methodology-v1_3.pdf<br />
<br />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<br />
<br />
===Additional References===<br />
<br />
None.<br />
<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Background&diff=46769
Enterprise Systems Engineering Background
2012-11-28T15:33:17Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>This article provides a common context for the succeeding topics in the knowledge area. <br />
<br />
==Capabilities in the Enterprise==<br />
The enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems or system elements. Since there could possibly be several organizations involved in this enterprise venture, each organization could be responsible for particular systems or perhaps for certain kinds of elements. Each organization brings their own organizational capability with them and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are illustrated below.<br />
<br />
[[File:ESE-F02.png|thumb|650px|center|'''Figure 1. Individual Competence Leads to Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
Organizational capabilities are addressed in the article on [[Systems Engineering Organizational Strategy]], and individual competencies are addressed in the article on [[Enabling Individuals]] as they relate to the principles, theories, and practices of organizational [[Behavior (glossary)|behavior]]. <br />
<br />
===Organizational Capabilities and Competencies===<br />
The word "[[capability (glossary)|capability]]" is used in [[Systems Engineering (glossary)|systems engineering]] (SE) in the sense of “the ability to do something useful under a particular set of conditions.” This article discusses three different kinds of capabilities: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. It uses the word “competence” to refer to the ability of people relative to the SE task. [[Competency (glossary)|Individual competence]], (sometimes called "competency"), contributes to, but is not the sole determinant of, organizational capability. This competence is translated to organizational capabilities through the work practices that are adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance [[Enterprise (glossary)|enterprise]] operational capability in response to [[Stakeholder (glossary)|stakeholder’s]] concerns about a problem situation. <br />
<br />
Enterprise stakeholders are the ultimate arbiters of [[value (glossary)]] for the system to be delivered. Organizational, system, and operational capabilities cannot be designed, improved, and implemented independently. The key to understanding the dependencies between capabilities is through [[Architecture (glossary)|architecture]] modeling and analysis as part of the activities described in the article called [[Enterprise Capability Management]]. “Capability engineering” is an emerging discipline that could enhance the [[Effectiveness (glossary)|effectiveness]] of [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE), which is further discussed in the article on [[Systems of Systems (SoS)]].<br />
<br />
===Organizational Design===<br />
The competencies of individuals are important to the overall organizational capability as discussed in the article on [[Enabling Individuals]]. The organizational capability is also a function of how the people, [[Team (glossary)|teams]], [[Project (glossary)|projects]], and [[Business (glossary)|businesses]] are organized. The organizational [[Design (glossary)|design]] should specify the roles, authorities, responsibilities, and accountabilities (RARA) of the organizational units to ensure the most efficient and effective operations. Effectiveness of enterprise operations is certainly driven by management principles, concepts, and approaches, but it is also largely driven by its leadership principles, concepts, and approaches. These factors are discussed in the article on [[Systems Engineering Organizational Strategy]] that discusses how to organize for effective performance of SE.<br />
<br />
Organizational [[Structure (glossary)|structure]] is tightly tied to creating value for the enterprise’s various stakeholders. Since the enterprise is made up of various elements including people, processes, technologies, and assets, the organizational structure of the people and the allocation of responsibilities for executing portions of the value stream is a “design decision” for the enterprise and hence is a key element of properly performing ESE. Organizational design is increasingly influenced by the portfolio of products and services and the degree of coupling between them. This organizational design will be based on organizational design patterns and their tradeoffs, as discussed in the article on [[Systems Engineering Organizational Strategy]]. Browning (2009) discusses one approach for modeling and analysis of an organization.<br />
<br />
===Operational Capabilities & Operational Services===<br />
As you can see in this figure, operational capabilities provide operational services that are enabled by system capabilities. These system capabilities are inherent in the system that is conceived, developed, created and/or operated by an enterprise. ESE concentrates its efforts on maximizing operational value for various stakeholders, some of whom may be interested in the improvement of some problem situation. <br />
<br />
ESE, however, addresses more than just solving problems; it also deals with the exploitation of [[Opportunity (glossary)|opportunities]] for better ways to achieve the enterprise goals. This opportunity might involve lowering of operating [[Cost (glossary)|costs]], increasing market share, decreasing deployment risk, reducing time to market, and any number of other enterprise goals. The importance of addressing opportunity potentials should not be underestimated in the execution of ESE practices. <br />
<br />
This article focuses on the ''operational capabilities'' of an enterprise and the contribution of these capabilities to ''operational value'' (as perceived by the stakeholders). Notice that the organization or enterprise can deal with either the system as a whole or with only one (or a few) of its elements. These elements are not necessarily hard items, like hardware and [[Software (glossary)|software]], but can also include “soft” items, like people, [[Process (glossary) |processes]], principles, policies, practices, organizations, doctrine, theories, beliefs, and so on.<br />
<br />
===Services vs. Products vs. Enterprises===<br />
A [[Service System (glossary)|service system]] is a collection of items (or entities) that perform the operations, administration, management and provisioning (OAM&P) of resources that together provide the opportunities to co-create [[value (glossary)]] by both the service provider and the service consumer.<br />
<br />
A collection of services is not necessarily a service system. In fact, this collection of services is often merely a product system that is one of the resources being OAM&P'ed by the service system. A product system can be composed of hardware, software, personnel (see note 1), facilities, data, materials, techniques, and even services. Each of these product [[System Element (glossary)|system elements]] can be "engineered."<br />
<br />
:<I>Note 1. Even personnel are engineered in the sense that their roles and responsibilities are specified precisely and trade-offs are made about which functions are performed by these people versus by hardware or software. People are "produced" in the sense that untrained people are trained to perform their allocated system functions, unknowledgeable people are educated to find or create the information they need to do their assigned task, and uninformed people are taught how to get access to the data they need, and how to extract relevant information from that data.</I><br />
<br />
It is important to understand the difference between the services "enabled" by a service system versus the services that are the elements of a service system entity. See the [[Service Systems Engineering]] article for more information about services and how they are engineered.<br />
<br />
Likewise, a collection of services is not necessarily an enterprise system. An enterprise may be composed of service systems, along with product systems, as well as policies, procedures, properties, knowledge, financial capital, intellectual capital, and so on. An enterprise might even contain sub-enterprises. Enterprise SE must do the engineering not only across the enterprise itself, but may also get involved in the engineering of the service systems and products systems that the enterprise depends on in order to achieve its goals.<br />
<br />
===Enterprise Components===<br />
The above depictions of enterprise-related things do not show the [[Component (glossary)|components]] of an enterprise. The components of an enterprise when it is viewed as a “system” are different than the components of a product or service system (which is the focus of most literature on systems engineering). The figure below shows the typical kinds of components (shown here as “domains”) in an enterprise (Troux 2010) that could be utilized in achieving the desired enterprise <I>operational capability</I> as shown in Figure 1. It is this operational capability that drives ultimate value for the enterprise’s [[Customer (glossary)|customers]] and other stakeholders. Further discussion on enterprise components is provided by Reese (2010) and Lawson (2010, chap. 8).<br />
<br />
[[File:ESE-F03.png|thumb|550px|center|'''Figure 2. Categories of Enterprise Components (Troux Technologies, 2010).''' Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.]]<br />
<br />
The application/software and infrastructure/hardware domains (shown above) are likely the most familiar to systems engineers. The application/software domain contains things like the deployed software itself plus applications, modules, servers, patches, functions, and messages. The infrastructure/hardware domain contains things like the hardware itself plus networks and different kinds of hardware like computing hardware, cabinets, and network devices. There might different subtypes of computing hardware like computers, servers, desktops, laptops, and mainframes. <br />
<br />
This particular "semantic model" had its origins in the area of information technology (IT) management but has been successfully expanded beyond the IT domain (Martin 2003 and 2005). You can see from this elaboration of these domains that an enterprise architecture "schema" can be quite extensive in the kinds of things it can model. The less technical domains would be things like policy, market, strategy, transition, financial, knowledge and skill, and analysis. In a typical enterprise architecture schema like this there could be over a hundred types of modeling objects grouped into these domains. <br />
<br />
Various tools used in modeling the enterprise are described at http://www.enterprise-architecture.info/EA_Tools.htm (IEAD 2011). The TOGAF metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html) used in The Open Group Architecture Framework (TOGAF) is another useful depiction of the various modeling entities involved in modeling the enterprise (TOGAF 2009).<br />
<br />
==Scope of Enterprise SE==<br />
Computer and communications technologies make it easier to integrate activities across the enterprise, but this does not necessarily make the enterprise more effective and efficient. To enable this to happen, one needs to look at the whole enterprise as a system, rather than as a collection of functions connected solely by information systems and shared facilities.<br />
<br />
===Essential Challenges===<br />
Enterprises face strategic challenges that are essential to address in order to ensure that the enterprise will succeed (Rouse 2009):<br />
*'''Growth:''' Increasing impact, perhaps in saturated/declining “markets”,<br />
*'''Value:''' Enhancing relationships of processes to benefits and costs,<br />
*'''Focus:''' Pursuing opportunities and avoiding diversions,<br />
*'''Change:''' Competing creatively while maintaining continuity,<br />
*'''Future:''' Investing in inherently unpredictable outcomes,<br />
*'''Knowledge:''' Transforming information to insights to programs, and<br />
*'''Time:''' Carefully allocating the organization’s scarcest resource.<br />
<br />
To address these challenges, one recognizes that the central source of value in the enterprise is in its people. “Understanding and supporting the interests of an enterprise’s diverse stakeholders — and finding the ‘sweet spot’ among the many competing interests — is a central aspect of discerning the work of the enterprise as a system and creating mechanisms to enhance this work” (Rouse 2009).<br />
<br />
===Enterprise Transformation===<br />
Enterprises are constantly transforming, whether at the individual level (wherein individuals alter their work practices) or at the enterprise level (large-scale planned strategic changes) (Srinivasan 2010). These changes are a response on the part of the enterprise to evolving opportunities and emerging [[Threat (glossary)|threats]]. It is not merely a matter of doing work better, but doing different work, which is often a more important result. Value is created through the execution of business processes. However, not all processes necessarily contribute to overall value (Rouse 2005, 138-150). It is important to focus on process and how they contribute to the overall value stream. <br />
<br />
After gaining a good understanding of business processes, the next main concern is how best to deploy and manage the enterprise’s human, financial, and physical assets. The key challenge in transforming an enterprise is, in the midst of all this change, continuing to ''satisfice'' key stakeholders (see note 2).<br />
<br />
:<I>Note 2. “Satisfice” means to decide on and pursue a course of action satisfying the minimum requirements to achieve a goal. For the enterprise as a whole, it is often impossible to completely satisfy all stakeholders given their competing and conflicting concerns and interests. Therefore, the concept of “satisficing” is a very important element in the execution of ESE practices. It has less stringent criteria than the concept of "satisfaction," which is commonly used in product/service systems engineering.</I><br />
<br />
Systems engineers have to respond to an increased recognition of the ‘connectedness’ of products and systems, brought about by a number of trends, for example: the capability of (mainly digital) technology, working across multiple systems, to transform businesses and operational systems; the need to create systems in families to increase product diversity and reuse technology, in order to reduce development and operating costs; and the need to build systems which can be brought together flexibly in operations, even if such co-operation was not foreseen at the time of development.<br />
<br />
There has also been an increase in collaborative systems development activities, often spanning national boundaries. This has proceeded alongside a growth in the development of what might be called ''meta-systems,'' that is systems comprising parts which would previously have been considered as complex in their own right a generation ago, now conceived of and developed as a whole, and thus requiring fresh approaches, of the adaption of old ones.<br />
<br />
Tackling these issues requires an approach that transcends the technical and process domain. ESE needs to address integration at the organizational and value chain level.<br />
<br />
===Transformation Context===<br />
Enterprise transformation occurs in the external context of the economy and markets as shown in the figure below (Rouse 2009). The “market” for the enterprise can be thought of as the context in which the enterprise operates. Of course, in the public sector, the enterprise’s “market” is commonly known as its “constituency.” <br />
<br />
[[File:ESE-F04.png|thumb|center|500px|'''Figure 3. Context for Enterprise Transformation (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
The term “intraprise” is used here to denote the many systems internal to the enterprise. This includes "information systems such as... ERP [enterprise resource planning] systems, as well as social and cultural systems. More specifically, work assignments are pursued via work processes and yield work products, incurring costs" (Rouse 2009). The social and cultural aspects of an enterprise are addressed further in the article called [[Enabling Businesses and Enterprises]].<br />
<br />
==Modeling the Enterprise==<br />
[[Model (glossary)|Models]] of the enterprise can serve as the basis for understanding the enterprise in its context of markets and economies. The figure below shows the various drivers (or inputs) of an enterprise and its potential outcomes (or outputs) (Rouse 2009). [[Enterprise Architecture (glossary)|Enterprise architecture]] can be a key enabler for modeling and can serve as a basis for transformation (Vernadat 1996; Bernus, Laszlo, and Schmidt 2003; Nightingale and Rhodes 2004). Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010) (See also [[Representing Systems with Models]]). For a good review of the subject see Lillehagen (2008).<br />
<br />
[[File:ESE-F05.png|thumb|center|500px|center|'''Figure 4. Drivers and Outcomes for the Enterprise (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
==In Pursuit of Value==<br />
Based on his theory of enterprise transformation, Rouse (2005, 279-295) has identified four alternative perspectives that tend to drive the need for transformation:<br />
#'''Value Opportunities:''' The lure of greater success via market and/or technology opportunities prompts transformation initiatives.<br />
#'''Value Threats:''' The danger of anticipated [[Failure (glossary)|failure]] due to market and/or technology threats prompts transformation initiatives.<br />
#'''Value Competition:''' Other players’ transformation initiatives prompt recognition that transformation is necessary to continued success.<br />
#'''Value Crises:''' Steadily declining market performance, cash flow problems, etc., prompt recognition that transformation is necessary for the enterprise to survive.<br />
<br />
Work processes can be enhanced, streamlined, eliminated, and invented to help in the pursuit of enhanced value. These process changes should be aligned with enterprise strategy to maximize value produced by the enterprise (Hammer and Champy 1993). As shown below, there are many entities involved in helping the enterprise create value for society, participating organizations, and other stakeholders.<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 5. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hammer, M., and J. Champy. 1993. ''Reengineering the Corporation: A Manifesto for Business Revolution.'' New York, NY: Harper Business, HarperCollins Publishers. <br />
<br />
IEAD. 2011. "Enterprise Architecture Tools." Institute for Enterprise Architecture Developments. Accessed September 12, 2012. Available at: http://www.enterprise-architecture.info/EA_Tools.htm.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Lillehagen, F., and J. Krogstie. 2008. "State of the Art of Enterprise Modelling." Chapter 4 in ''Active Knowledge Management of Enterprises.'' New York, NY: Springer.<br />
<br />
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. <br />
<br />
Martin, J.N., 2003. "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. <br />
<br />
Miller, J., and S. Page. 2007. ''Complex Adaptive Systems: An Introduction to Computational Models of Social Life.'' Princeton, NJ, USA: Princeton University Press.<br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2):138-50. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria.<br />
<br />
TOGAF 2009. "The Open Group Architecture Framework," version 9. The Open Architecture Group. Accessed on September 2, 2011. Available at: http://www.opengroup.org/togaf. <br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
White, B.E. 2009. "Complex Adaptive Systems Engineering (CASE)." Presented at IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''[[Design of Enterprise Systems: Theory, Architecture, and Methods]].'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse (eds.), ''Handbook of systems engineering and management,'' 2nd ed. New York, NY: Wiley and Sons, Inc.<br />
<br />
Srinivasan, J. 2010. "[[Towards a Theory Sensitive Approach to Planning Enterprise Transformation]]." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
White, B.E. 2009. "[[Complex Adaptive Systems Engineering (CASE)]]." IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Additional References===<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"Systems of systems engineering: Principles and applications."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105.<br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering 38'' (1) (Spring 2008): 17-25. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In M.A. Somerville and D. Rappaport (eds.), ''Transdiciplinarity: Recreating Integrated Knowledge."' Oxford, UK: EOLSS Publishers: 158-169. <br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications,'' Revised ed. New York, NY: Braziller.<br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''"General Principles of Systems Design."'' New York, NY: Dorset House Publishing Company.<br />
<br />
White, B.E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[The Enterprise as a System|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Background&diff=46766
Enterprise Systems Engineering Background
2012-11-28T15:32:26Z
<p>Janthony: /* Enterprise Components */</p>
<hr />
<div>This article provides a common context for the succeeding topics in the knowledge area. <br />
<br />
==Capabilities in the Enterprise==<br />
The enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems or system elements. Since there could possibly be several organizations involved in this enterprise venture, each organization could be responsible for particular systems or perhaps for certain kinds of elements. Each organization brings their own organizational capability with them and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are illustrated below.<br />
<br />
[[File:ESE-F02.png|thumb|650px|center|'''Figure 1. Individual Competence Leads to Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
Organizational capabilities are addressed in the article on [[Systems Engineering Organizational Strategy]], and individual competencies are addressed in the article on [[Enabling Individuals]] as they relate to the principles, theories, and practices of organizational [[Behavior (glossary)|behavior]]. <br />
<br />
===Organizational Capabilities and Competencies===<br />
The word "[[capability (glossary)|capability]]" is used in [[Systems Engineering (glossary)|systems engineering]] (SE) in the sense of “the ability to do something useful under a particular set of conditions.” This article discusses three different kinds of capabilities: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. It uses the word “competence” to refer to the ability of people relative to the SE task. [[Competency (glossary)|Individual competence]], (sometimes called "competency"), contributes to, but is not the sole determinant of, organizational capability. This competence is translated to organizational capabilities through the work practices that are adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance [[Enterprise (glossary)|enterprise]] operational capability in response to [[Stakeholder (glossary)|stakeholder’s]] concerns about a problem situation. <br />
<br />
Enterprise stakeholders are the ultimate arbiters of [[value (glossary)]] for the system to be delivered. Organizational, system, and operational capabilities cannot be designed, improved, and implemented independently. The key to understanding the dependencies between capabilities is through [[Architecture (glossary)|architecture]] modeling and analysis as part of the activities described in the article called [[Enterprise Capability Management]]. “Capability engineering” is an emerging discipline that could enhance the [[Effectiveness (glossary)|effectiveness]] of [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE), which is further discussed in the article on [[Systems of Systems (SoS)]].<br />
<br />
===Organizational Design===<br />
The competencies of individuals are important to the overall organizational capability as discussed in the article on [[Enabling Individuals]]. The organizational capability is also a function of how the people, [[Team (glossary)|teams]], [[Project (glossary)|projects]], and [[Business (glossary)|businesses]] are organized. The organizational [[Design (glossary)|design]] should specify the roles, authorities, responsibilities, and accountabilities (RARA) of the organizational units to ensure the most efficient and effective operations. Effectiveness of enterprise operations is certainly driven by management principles, concepts, and approaches, but it is also largely driven by its leadership principles, concepts, and approaches. These factors are discussed in the article on [[Systems Engineering Organizational Strategy]] that discusses how to organize for effective performance of SE.<br />
<br />
Organizational [[Structure (glossary)|structure]] is tightly tied to creating value for the enterprise’s various stakeholders. Since the enterprise is made up of various elements including people, processes, technologies, and assets, the organizational structure of the people and the allocation of responsibilities for executing portions of the value stream is a “design decision” for the enterprise and hence is a key element of properly performing ESE. Organizational design is increasingly influenced by the portfolio of products and services and the degree of coupling between them. This organizational design will be based on organizational design patterns and their tradeoffs, as discussed in the article on [[Systems Engineering Organizational Strategy]]. Browning (2009) discusses one approach for modeling and analysis of an organization.<br />
<br />
===Operational Capabilities & Operational Services===<br />
As you can see in this figure, operational capabilities provide operational services that are enabled by system capabilities. These system capabilities are inherent in the system that is conceived, developed, created and/or operated by an enterprise. ESE concentrates its efforts on maximizing operational value for various stakeholders, some of whom may be interested in the improvement of some problem situation. <br />
<br />
ESE, however, addresses more than just solving problems; it also deals with the exploitation of [[Opportunity (glossary)|opportunities]] for better ways to achieve the enterprise goals. This opportunity might involve lowering of operating [[Cost (glossary)|costs]], increasing market share, decreasing deployment risk, reducing time to market, and any number of other enterprise goals. The importance of addressing opportunity potentials should not be underestimated in the execution of ESE practices. <br />
<br />
This article focuses on the ''operational capabilities'' of an enterprise and the contribution of these capabilities to ''operational value'' (as perceived by the stakeholders). Notice that the organization or enterprise can deal with either the system as a whole or with only one (or a few) of its elements. These elements are not necessarily hard items, like hardware and [[Software (glossary)|software]], but can also include “soft” items, like people, [[Process (glossary) |processes]], principles, policies, practices, organizations, doctrine, theories, beliefs, and so on.<br />
<br />
===Services vs. Products vs. Enterprises===<br />
A [[Service System (glossary)|service system]] is a collection of items (or entities) that perform the operations, administration, management and provisioning (OAM&P) of resources that together provide the opportunities to co-create [[value (glossary)]] by both the service provider and the service consumer.<br />
<br />
A collection of services is not necessarily a service system. In fact, this collection of services is often merely a product system that is one of the resources being OAM&P'ed by the service system. A product system can be composed of hardware, software, personnel (see note 1), facilities, data, materials, techniques, and even services. Each of these product [[System Element (glossary)|system elements]] can be "engineered."<br />
<br />
:<I>Note 1. Even personnel are engineered in the sense that their roles and responsibilities are specified precisely and trade-offs are made about which functions are performed by these people versus by hardware or software. People are "produced" in the sense that untrained people are trained to perform their allocated system functions, unknowledgeable people are educated to find or create the information they need to do their assigned task, and uninformed people are taught how to get access to the data they need, and how to extract relevant information from that data.</I><br />
<br />
It is important to understand the difference between the services "enabled" by a service system versus the services that are the elements of a service system entity. See the [[Service Systems Engineering]] article for more information about services and how they are engineered.<br />
<br />
Likewise, a collection of services is not necessarily an enterprise system. An enterprise may be composed of service systems, along with product systems, as well as policies, procedures, properties, knowledge, financial capital, intellectual capital, and so on. An enterprise might even contain sub-enterprises. Enterprise SE must do the engineering not only across the enterprise itself, but may also get involved in the engineering of the service systems and products systems that the enterprise depends on in order to achieve its goals.<br />
<br />
===Enterprise Components===<br />
The above depictions of enterprise-related things do not show the [[Component (glossary)|components]] of an enterprise. The components of an enterprise when it is viewed as a “system” are different than the components of a product or service system (which is the focus of most literature on systems engineering). The figure below shows the typical kinds of components (shown here as “domains”) in an enterprise (Troux 2010) that could be utilized in achieving the desired enterprise <I>operational capability</I> as shown in Figure 1. It is this operational capability that drives ultimate value for the enterprise’s [[Customer (glossary)|customers]] and other stakeholders. Further discussion on enterprise components is provided by Reese (2010) and Lawson (2010, chap. 8).<br />
<br />
[[File:ESE-F03.png|thumb|550px|center|'''Figure 2. Categories of Enterprise Components (Troux Technologies, 2010).''' Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.]]<br />
<br />
The application/software and infrastructure/hardware domains (shown above) are likely the most familiar to systems engineers. The application/software domain contains things like the deployed software itself plus applications, modules, servers, patches, functions, and messages. The infrastructure/hardware domain contains things like the hardware itself plus networks and different kinds of hardware like computing hardware, cabinets, and network devices. There might different subtypes of computing hardware like computers, servers, desktops, laptops, and mainframes. <br />
<br />
This particular "semantic model" had its origins in the area of information technology (IT) management but has been successfully expanded beyond the IT domain (Martin 2003 and 2005). You can see from this elaboration of these domains that an enterprise architecture "schema" can be quite extensive in the kinds of things it can model. The less technical domains would be things like policy, market, strategy, transition, financial, knowledge and skill, and analysis. In a typical enterprise architecture schema like this there could be over a hundred types of modeling objects grouped into these domains. <br />
<br />
Various tools used in modeling the enterprise are described at http://www.enterprise-architecture.info/EA_Tools.htm (IEAD 2011). The TOGAF metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html) used in The Open Group Architecture Framework (TOGAF) is another useful depiction of the various modeling entities involved in modeling the enterprise (TOGAF 2009).<br />
<br />
==Scope of Enterprise SE==<br />
Computer and communications technologies make it easier to integrate activities across the enterprise, but this does not necessarily make the enterprise more effective and efficient. To enable this to happen, one needs to look at the whole enterprise as a system, rather than as a collection of functions connected solely by information systems and shared facilities.<br />
<br />
===Essential Challenges===<br />
Enterprises face strategic challenges that are essential to address in order to ensure that the enterprise will succeed (Rouse 2009):<br />
*'''Growth:''' Increasing impact, perhaps in saturated/declining “markets”,<br />
*'''Value:''' Enhancing relationships of processes to benefits and costs,<br />
*'''Focus:''' Pursuing opportunities and avoiding diversions,<br />
*'''Change:''' Competing creatively while maintaining continuity,<br />
*'''Future:''' Investing in inherently unpredictable outcomes,<br />
*'''Knowledge:''' Transforming information to insights to programs, and<br />
*'''Time:''' Carefully allocating the organization’s scarcest resource.<br />
<br />
To address these challenges, one recognizes that the central source of value in the enterprise is in its people. “Understanding and supporting the interests of an enterprise’s diverse stakeholders — and finding the ‘sweet spot’ among the many competing interests — is a central aspect of discerning the work of the enterprise as a system and creating mechanisms to enhance this work” (Rouse 2009).<br />
<br />
===Enterprise Transformation===<br />
Enterprises are constantly transforming, whether at the individual level (wherein individuals alter their work practices) or at the enterprise level (large-scale planned strategic changes) (Srinivasan 2010). These changes are a response on the part of the enterprise to evolving opportunities and emerging [[Threat (glossary)|threats]]. It is not merely a matter of doing work better, but doing different work, which is often a more important result. Value is created through the execution of business processes. However, not all processes necessarily contribute to overall value (Rouse 2005, 138-150). It is important to focus on process and how they contribute to the overall value stream. <br />
<br />
After gaining a good understanding of business processes, the next main concern is how best to deploy and manage the enterprise’s human, financial, and physical assets. The key challenge in transforming an enterprise is, in the midst of all this change, continuing to ''satisfice'' key stakeholders (see note 2).<br />
<br />
:<I>Note 2. “Satisfice” means to decide on and pursue a course of action satisfying the minimum requirements to achieve a goal. For the enterprise as a whole, it is often impossible to completely satisfy all stakeholders given their competing and conflicting concerns and interests. Therefore, the concept of “satisficing” is a very important element in the execution of ESE practices. It has less stringent criteria than the concept of "satisfaction," which is commonly used in product/service systems engineering.</I><br />
<br />
Systems engineers have to respond to an increased recognition of the ‘connectedness’ of products and systems, brought about by a number of trends, for example: the capability of (mainly digital) technology, working across multiple systems, to transform businesses and operational systems; the need to create systems in families to increase product diversity and reuse technology, in order to reduce development and operating costs; and the need to build systems which can be brought together flexibly in operations, even if such co-operation was not foreseen at the time of development.<br />
<br />
There has also been an increase in collaborative systems development activities, often spanning national boundaries. This has proceeded alongside a growth in the development of what might be called ''meta-systems,'' that is systems comprising parts which would previously have been considered as complex in their own right a generation ago, now conceived of and developed as a whole, and thus requiring fresh approaches, of the adaption of old ones.<br />
<br />
Tackling these issues requires an approach that transcends the technical and process domain. ESE needs to address integration at the organizational and value chain level.<br />
<br />
===Transformation Context===<br />
Enterprise transformation occurs in the external context of the economy and markets as shown in the figure below (Rouse 2009). The “market” for the enterprise can be thought of as the context in which the enterprise operates. Of course, in the public sector, the enterprise’s “market” is commonly known as its “constituency.” <br />
<br />
[[File:ESE-F04.png|thumb|center|500px|'''Figure 3. Context for Enterprise Transformation (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
The term “intraprise” is used here to denote the many systems internal to the enterprise. This includes "information systems such as... ERP [enterprise resource planning] systems, as well as social and cultural systems. More specifically, work assignments are pursued via work processes and yield work products, incurring costs" (Rouse 2009). The social and cultural aspects of an enterprise are addressed further in the article called [[Enabling Businesses and Enterprises]].<br />
<br />
==Modeling the Enterprise==<br />
[[Model (glossary)|Models]] of the enterprise can serve as the basis for understanding the enterprise in its context of markets and economies. The figure below shows the various drivers (or inputs) of an enterprise and its potential outcomes (or outputs) (Rouse 2009). [[Enterprise Architecture (glossary)|Enterprise architecture]] can be a key enabler for modeling and can serve as a basis for transformation (Vernadat 1996; Bernus, Laszlo, and Schmidt 2003; Nightingale and Rhodes 2004). Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010) (See also [[Representing Systems with Models]]). For a good review of the subject see Lillehagen (2008).<br />
<br />
[[File:ESE-F05.png|thumb|center|500px|center|'''Figure 4. Drivers and Outcomes for the Enterprise (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
==In Pursuit of Value==<br />
Based on his theory of enterprise transformation, Rouse (2005, 279-295) has identified four alternative perspectives that tend to drive the need for transformation:<br />
#'''Value Opportunities:''' The lure of greater success via market and/or technology opportunities prompts transformation initiatives.<br />
#'''Value Threats:''' The danger of anticipated [[Failure (glossary)|failure]] due to market and/or technology threats prompts transformation initiatives.<br />
#'''Value Competition:''' Other players’ transformation initiatives prompt recognition that transformation is necessary to continued success.<br />
#'''Value Crises:''' Steadily declining market performance, cash flow problems, etc., prompt recognition that transformation is necessary for the enterprise to survive.<br />
<br />
Work processes can be enhanced, streamlined, eliminated, and invented to help in the pursuit of enhanced value. These process changes should be aligned with enterprise strategy to maximize value produced by the enterprise (Hammer and Champy 1993). As shown below, there are many entities involved in helping the enterprise create value for society, participating organizations, and other stakeholders.<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 5. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hammer, M., and J. Champy. 1993. ''Reengineering the Corporation: A Manifesto for Business Revolution.'' New York, NY: Harper Business, HarperCollins Publishers. <br />
<br />
IEAD. 2011. "Enterprise Architecture Tools." Institute for Enterprise Architecture Developments. Accessed September 12, 2012. Available at: http://www.enterprise-architecture.info/EA_Tools.htm.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Lillehagen, F., and J. Krogstie. 2008. "State of the Art of Enterprise Modelling." Chapter 4 in ''Active Knowledge Management of Enterprises.'' New York, NY: Springer.<br />
<br />
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. <br />
<br />
Martin, J.N., 2003. "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. <br />
<br />
Miller, J., and S. Page. 2007. ''Complex Adaptive Systems: An Introduction to Computational Models of Social Life.'' Princeton, NJ, USA: Princeton University Press.<br />
<br />
OMG. 2009. "The Open Group Architecture Framework," version 9. The Open Architecture Group. Accessed on September 2, 2011. Available at: http://www.opengroup.org/togaf. <br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2):138-50. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
White, B.E. 2009. "Complex Adaptive Systems Engineering (CASE)." Presented at IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''[[Design of Enterprise Systems: Theory, Architecture, and Methods]].'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse (eds.), ''Handbook of systems engineering and management,'' 2nd ed. New York, NY: Wiley and Sons, Inc.<br />
<br />
Srinivasan, J. 2010. "[[Towards a Theory Sensitive Approach to Planning Enterprise Transformation]]." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
White, B.E. 2009. "[[Complex Adaptive Systems Engineering (CASE)]]." IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Additional References===<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"Systems of systems engineering: Principles and applications."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105.<br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering 38'' (1) (Spring 2008): 17-25. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In M.A. Somerville and D. Rappaport (eds.), ''Transdiciplinarity: Recreating Integrated Knowledge."' Oxford, UK: EOLSS Publishers: 158-169. <br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications,'' Revised ed. New York, NY: Braziller.<br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''"General Principles of Systems Design."'' New York, NY: Dorset House Publishing Company.<br />
<br />
White, B.E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[The Enterprise as a System|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46764
Enterprise Systems Engineering Process Activities
2012-11-28T15:31:29Z
<p>Janthony: /* Enterprise Architecture and Requirements */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
“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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
“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'''.”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.”</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; TOGAF 2009; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Capability_Engineering&diff=46761
Capability Engineering
2012-11-28T15:28:03Z
<p>Janthony: /* Services View of SoSE */</p>
<hr />
<div>==Capability Engineering Perspectives==<br />
The term [[Capability (glossary)|capability]] is widely used across many industrial sectors and has begun to take on various specific meanings across, and even within, those sectors. Terms such as capability-based acquisition, capability engineering and management, life capability management, capability sponsor, etc. are now ubiquitous in defense and elsewhere. Henshaw et al. (2011) have identified at least eight worldviews of capability and capability engineering and concluded that the task of capability engineering is not consistently defined across the different communities. <br />
<br />
Whilst most practitioners recognize that there is a strong relationship between capability and system of systems (SoS), there is no agreed position; however, there are two beliefs that are widely accepted among the different communities, including:<br />
* a capability comprises a range of systems, processes, people, information and organizations. (i.e. a system at levels three through five in Hitchin's (2003) five layer model, such as a Carrier-Strike capability) and<br />
* the capability is an emergent property of SoS (i.e. the capability of Carrier-Strike to engage targets within 300 miles of the sea.)<br />
<br />
==Services View of SoSE==<br />
<br />
As it has been discussed throughout the [[Systems of Systems (SoS)]] knowledge area, a ‘system of systems’ is typically approached from the viewpoint of bringing together multiple systems to provide broader capability. As is discussed in [[Architecting Approaches for Systems of Systems]], the networking of the constituent systems in a SoS is often a key part of an SoS. In some circumstances, the entire content of a SoS is information and the SoS brings together multiple information systems to support the information needs of a broader community. These ‘[[Information Technology (glossary)|information technology]] (IT)-based’ SoSs have the same set of characteristics of other SoSs and face many of the same challenges. Currently, IT has adopted a ‘services’ view of this type of SoS and increasingly applies a International Organization for Standaradization (ISO) 20000 series (Information technology -- Service management) or Information Technology Infrastructure Library (ITIL) v. 3 (OGC 2009) based approach to the design and management of information-based SoS. <br />
A service perspective simplifies SoSE as it:<br />
* is a more natural way for users to interact with and understand a SoS,<br />
* allows designers to design specific services to meet defined performance and effectiveness targets, and<br />
* enables specific service levels to be tested and monitored through life.<br />
<br />
Although it has not been proven to be universally applicable, the services view works well in both IT and transportation SoS.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Erl, T. 2008. "SOA Principles of Service Design." Boston, MA, USA: Prentice Hall Pearson Education. <br />
<br />
Hitchins, D.K. 2003. ''Advanced Systems Thinking, Engineering and Management''. Norwood, MA, USA: Artech House, Inc.<br />
<br />
OGC (Office of Government Commerce). 2009. ''[[ITIL Lifecycle Publication Suite Books]].'' London, UK: The Stationery Office.<br />
<br />
===Primary References===<br />
Henshaw, M., D. Kemp, P. Lister, A. Daw, A. Harding, A. Farncombe, and M. Touchin. 2011. "[[Capability Engineering - An Analysis of Perspectives]]." Presented at International Council on Systems Engineering (INCOSE) 21st International Symposium, 20-23 June 2011. Denver, US.<br />
<br />
===Additional References===<br />
Davies, J.K. 2011. ''Survey of Background Literature for Capability Engineering''. INCOSE UK Capability Working Group Report.<br />
<br />
----<br />
<center>[[Socio-Technical Features of Systems of Systems|< Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Enabling Systems Engineering|Next Article (Part 5) >]]</center><br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Systems of Systems (SoS)]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46759
Enterprise Capability Management
2012-11-28T15:25:05Z
<p>Janthony: /* Enterprise Architecture Formulation & Assessment */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The [ITIL]] is a set of concepts and practices for information technology services management (ITSM), information technology (IT) development and IT operations. ITIL gives detailed descriptions of a number of important IT practices and provides comprehensive checklists, tasks and procedures that any IT organization can tailor to its needs. ITIL is published in a series of books, each of which covers an IT management topic.'' (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC/IEEE 15288 (ISO/IEC/IEEE 2008) and architectural design process: ISO/IEC 42010 (ISO/IEC 2011) and ISO 15704 (ISO 2000)).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 2011. ''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:2011. <br />
<br />
ISO/IEC/IEEE 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46757
Enterprise Capability Management
2012-11-28T15:24:25Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The [ITIL]] is a set of concepts and practices for information technology services management (ITSM), information technology (IT) development and IT operations. ITIL gives detailed descriptions of a number of important IT practices and provides comprehensive checklists, tasks and procedures that any IT organization can tailor to its needs. ITIL is published in a series of books, each of which covers an IT management topic.'' (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC 15288 (ISO/IEC/IEEE 2008) and architectural design process: ISO/IEC 42010 (ISO/IEC 2011) and ISO 15704 (ISO 2000)).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 2011. ''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:2011. <br />
<br />
ISO/IEC/IEEE 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC/IEEE 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46753
Enterprise Capability Management
2012-11-28T15:23:04Z
<p>Janthony: /* Enterprise Architecture Formulation & Assessment */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The [ITIL]] is a set of concepts and practices for information technology services management (ITSM), information technology (IT) development and IT operations. ITIL gives detailed descriptions of a number of important IT practices and provides comprehensive checklists, tasks and procedures that any IT organization can tailor to its needs. ITIL is published in a series of books, each of which covers an IT management topic.'' (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC 15288 (ISO/IEC/IEEE 2008) and architectural design process: ISO/IEC 42010 (ISO/IEC 2011) and ISO 15704 (ISO 2000)).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
ISO/IEC 158288. 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=46752
Enterprise Capability Management
2012-11-28T15:21:12Z
<p>Janthony: /* Enterprise Architecture Formulation & Assessment */</p>
<hr />
<div>==Introduction==<br />
There are three different kinds of [[capability (glossary)|capability]]: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. Management of organizational capability is addressed in the article called [[Enabling Businesses and Enterprises]]. Management of system capability is addressed by the Systems Engineering (SE) management activities described in the articles called [[Systems Engineering Management]] and [[Product and Service Life Management]]. Management of operational capability is described herein.<br />
<br />
[[File:ESE-F02.png|thumb|800px|center|'''Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)|baseline]]) operational capability, based on its past activities and on its current [[Plan (glossary)|plans]] for change. The purpose of the enterprise [[Capability Management (glossary) | capability management]] function is to ensure the possibility of “vectoring” the enterprise away from the current baseline trajectory to a more desirable position where it can better meet its enterprise strategic goals and objectives, given all its resource [[Constraint (glossary)|constraints]] and other limitations. <br />
<br />
Operational capability may need to include elements identified in the Information Technology Infrastructure Library (ITIL) best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The [ITIL]] is a set of concepts and practices for information technology services management (ITSM), information technology (IT) development and IT operations. ITIL gives detailed descriptions of a number of important IT practices and provides comprehensive checklists, tasks and procedures that any IT organization can tailor to its needs. ITIL is published in a series of books, each of which covers an IT management topic.'' (http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library).<br />
</BLOCKQUOTE><br />
<br />
==Needs Identification & Assessment==<br />
The enterprise has key [[Stakeholder (glossary)|stakeholders]] that have [[operational (glossary)]] needs they would like the enterprise to address. These operational needs must be identified and assessed in terms of their relevance to the enterprise and the relative priorities of these needs compared to each other and to the priorities of the enterprise itself. The enterprise exists to meet these needs. An operational need is an expression of something desirable in direct support of the enterprise’s end [[user (glossary)]] activities. End user activities include such things as retail sales, entertainment, food services, and [[business (glossary)]] travel. An example of an operational need is: “Provide transportation services to commuters in the metropolitan area of London.”<br />
<br />
Enterprise needs can be much more than eliminating waste, and the challenge for ESE might relate to any or all of the following: countering a perceived threat (business or military), meeting a policy goal (as in government), doing existing business more efficiently, taking advantage of technological opportunities, meeting new operational needs, replacing obsolete systems, creating integrated enterprises with others (on a temporary or permanent basis), and so on.<br />
<br />
In addition to operational needs, there are enterprise needs that relate to enabling assets the enterprise has in place that allow the [[Mission (glossary)|mission]] to be accomplished. Enabling assets are things such as personnel, facilities, communication [[Network (glossary)|networks]], computing facilities, policies and practices, tools and methods, funding and partnerships, equipment and supplies, and so on. An enterprise need is an expression of something desirable in direct support of the enterprise’s internal activities. Internal activities include such things as market forecast, business development, [[product (glossary)]] development, manufacturing, and service delivery. <br />
<br />
The purpose of the enterprise’s enabling assets is to effect state changes to relevant elements of the enterprise necessary to achieve targeted levels of performance. The enterprise “state” shown in the figure below is a [[complex (glossary)]] web of past, current and future states (Rouse 2009). The enterprise work [[Process (glossary)|processes]] use these enabling assets to accomplish their work objectives in order to achieve the desired future states. [[Enterprise Architecture (glossary)|Enterprise architecture]] (EA) can be used to [[model (glossary)]] these states and the relative impact each enabling asset has on the desired state changes.<br />
<br />
[[File:ESE-F22.png|thumb|center|600px|'''Figure 2. Enterprise State Changes Through Work Process Activities (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise needs are related to the enterprise efficiencies achieved through the performance of enterprise activities. The main goal of enterprise needs is to maximize the efficient utilization of enterprise assets, or in other words, enhance productivity, and find and eliminate waste. Waste represents that which does not contribute to the enterprise mission or that cannot reasonably be expected to be accomplished by the enterprise. An example of an enterprise need is: “Decrease power required for operation of enterprise [[Data Center (glossary)|data centers]].” (Power is a limited asset that consumes scarce enterprise funds that could be used for delivery of other more valuable services to its customers.)<br />
<br />
==Capability Identification & Assessment==<br />
The capabilities of an enterprise should exist for the sole purpose of meeting mission and enterprise needs. Hence, there will be both mission and enterprise capabilities to identify and assess how well they meet these needs. An example of an operational capability is: “Transport 150,000 passengers per hour among 27 nodes in the network.” A supporting enterprise capability might be: “Process 200,000 tickets per hour during peak loading.” There is a baseline capability due to capability development up to that point in time, plus any additional capability planned for the future. The desired levels of capability (based on needs assessment) are compared to the baseline capability to determine the capability gaps for the enterprise. This activity will also determine points of excess capability.<br />
<br />
The gaps should be filled and the excesses should be eliminated. The projected gaps and excesses are sometimes mapped into several future timeframes to get a better understanding of the relative timing and intensity of change that might be required. It is typical to use time “buckets” like near-term, mid-term, and far-term, which, for some long-lasting capabilities, might correspond to five, ten, and twenty years out respectively. Of course, for fast-changing capabilities (like consumer products) these timeframes would necessarily be shorter in duration, for example, one, two and three years out.<br />
<br />
==Enterprise Architecture Formulation & Assessment==<br />
Enterprise architecture analysis can be used to determine how best to fill these capability gaps and minimize the excess capabilities (or “capacities”). Usually a baseline architecture is characterized for the purpose of understanding what one currently has and where the enterprise is headed under the current business [[Plan (glossary)|plans]]. The needs and gaps are used to determine where in the architecture elements need to be added, dropped, or changed. Each modification represents a potential benefit to various stakeholders, along with associated [[Cost (glossary)|costs]] and [[Risk (glossary)|risks]] for introducing that modification. Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010).<br />
<br />
The enterprise architecture effort supports the entire capability management activity with enterprise-wide views of strategy, priorities, plans, resources, activities, locations, facilities, products, services, and so on (ISO/IEC 15288 (ISO/IEC 2008) and architectural design process; ISO/IEC 42010 2011; ISO 15704 2000).<br />
<br />
==Opportunity Identification & Assessment==<br />
The enterprise architecture is used to help identify opportunities for improvement. Usually these opportunities require the investment of time, money, facilities, personnel, and so on. There might also be [[Opportunity (glossary)|opportunities]] for “divestment,” which could involve selling of assets, reducing [[capacity (glossary)|capacity]], canceling projects, and so on. Each opportunity can be assessed on its own merits, but usually these opportunities have dependencies and interfaces with other opportunities, with the current activities and operations of the enterprise, and with the enterprise's partners. Therefore, the opportunities may need to be assessed as a “[[Portfolio (glossary)|portfolio]],” or, at least, as sets of related opportunities. Typically, a business case assessment is required for each opportunity or set of opportunities.<br />
<br />
==Enterprise Portfolio Management==<br />
If the set of opportunities is large or has complicated relationships, it may be necessary to employ portfolio management techniques. The portfolio elements could be bids, projects, products, services, technologies, intellectual property, etc., or any combination of these items. Examples of an enterprise portfolio captured in an architecture [[Modeling Tool (glossary)|modeling tool]] can be found in Martin (2005), Martin et al. (2004), and Martin (2003). See Kaplan's work (2009) for more information on portfolio management, and ISO/IEC (2008) for information on projects portfolio management process.<br />
<br />
==Enterprise Improvement Planning & Execution==<br />
The results of the opportunity assessment are compiled and laid out in an enterprise plan that considers all relevant factors, including system capabilities, organizational capabilities, funding constraints, legal commitments and obligations, partner arrangements, intellectual property ownership, personnel development and retention, and so on. The plan usually goes out to some long horizon, typically more than a decade, depending on the nature of the enterprise’s business [[environment (glossary)| environment,]] technology volatility, market intensity, and so on. The enterprise plan needs to be in alignment with the enterprise’s strategic goals and objectives and with leadership priorities.<br />
<br />
The planned improvements are implemented across the enterprise and in parts of the [[Extended Enterprise (glossary)|extended enterprise (glossary)]] where appropriate, such as suppliers in the supply chain, distributors in the distribution chain, financiers in the investment arena, and so on. The planned changes should have associated performance targets and these [[Metric (glossary)|metrics]] should be monitored to ensure that progress is being made against the plan and that the intended improvements are being implemented. As necessary, the plan is adjusted to account for unforeseen circumstances and outcomes. Performance management of enterprise personnel is a key element of the improvement efforts.<br />
<br />
==Enterprise Capability Change Management ==<br />
In an operational [[context (glossary)]] (particularly in defense) the term “capability management” is associated with developing and maintaining all aspects of the ability to conduct certain types of missions in a given [[threat (glossary)]] environment. In an industrial context, capability refers to the ability to manage certain classes of product and service through those parts of their [[Life Cycle (glossary)|life cycle]] that are relevant to the business. Changes to enterprise capability should be carefully managed to ensure that current operations are not adversely affected (where possible) and that the long term viability of the enterprise is maintained. The following seven lenses can be used to facilitate change management: strategic objectives, stakeholders, processes, performance metrics, current state alignment, resources, and maturity assessment (Nightingale and Srinivasan 2011).<br />
<br />
Capability management is becoming more often recognized as a key component of the business management tool suite:<br />
<br />
<BLOCKQUOTE><br />
“Capability management aims to balance economy in meeting current operational requirements, with the sustainable use of current capabilities, and the development of future capabilities, to meet the sometimes competing strategic and current operational objectives of an enterprise. Accordingly, effective capability management assists organizations to better understand, and effectively integrate, re-align and apply the total enterprise ability or capacity to achieve strategic and current operational objectives; and develops and provides innovative solutions that focus on the holistic management of the defined array of interlinking functions and activities in the enterprise's strategic and current operational contexts.” (Saxena 2009, 1)<br />
</BLOCKQUOTE><br />
<br />
There is a widespread perception that capability management is only relevant to defense and aerospace domains. However, it is becoming more widely recognized as key to commercial and civil government efforts.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise — Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
ISO/IEC 158288. 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
Kaplan, J. 2009. ''Strategic IT Portfolio Management: Governing Enterprise Transformation.'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
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. <br />
<br />
Martin, J.N. 2003. "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. <br />
<br />
Martin, J.N., J. Conklin, J. Evans, C. Robinson, L. Doggrell, and J. Diehl. 2004. "The Capability Integration Framework: A New Way of doing Enterprise Architecture." Paper presented at 14th Annual International Council on Systems Engineering (INCOSE) International Symposium, 20-24 June, 2004, Toulouse, France. <br />
<br />
Nightingale, D. and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
OGC (Office of Government Commerce). 2009. ''ITIL Lifecycle Publication Suite Books.'' London, UK: The Stationery Office. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In A.P. Sage, W.B. Rouse (eds).''Handbook of Systems Engineering and Management'', 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Saxena, M.S. 2009. ''Capability Management: Monitoring & Improving Capabilities.'' New Dehli: Global India Publications Pvt Ltd.<br />
<br />
===Primary References===<br />
Kaplan, J. 2009. ''[[Strategic IT Portfolio Management: Governing Enterprise Transformation]].'' Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).<br />
<br />
Nightingale, D, and J. Srinivasan. 2011. ''[[Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation]]''. New York, NY, USA: AMACOM Press. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
===Additional References===<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering.'' November 2008. <br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc.<br />
<br />
Lillehagen, F., J. Kostie, S. Inella, H.G. Solheim, and D. Karlsen. 2003. "From enterprise modeling to enterprise visual scenes." Paper presented at International Society for Pharmaceutical Engineering (ISPE) Conference on Concurrent Engineering (CE), 26-30 July, 2003, Madeira Island, Portugal. <br />
<br />
McGovern, J., S. Ambler, M. Stevens, J. Linn, V. Sharan, and E. Jo. 2004. ''A Practical Guide to Enterprise Architecture.'' New York, NY: Prentice Hall. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46750
Enterprise Systems Engineering Process Activities
2012-11-28T15:17:31Z
<p>Janthony: /* Opportunity Assessment and Management */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
“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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
“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'''.”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.”</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46748
Enterprise Systems Engineering Process Activities
2012-11-28T15:16:27Z
<p>Janthony: /* Balancing Effectiveness versus Efficiency */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
“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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
“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'''.”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.”</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46746
Enterprise Systems Engineering Process Activities
2012-11-28T15:14:44Z
<p>Janthony: /* Systems Engineering Role in Transforming the Enterprise */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
“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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
<BLOCKQUOTE><br />
“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'''.<br />
<br />
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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.”</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=46745
Enterprise Systems Engineering Process Activities
2012-11-28T15:13:35Z
<p>Janthony: /* Enabling Systematic Enterprise Change */</p>
<hr />
<div>The application of the key concepts of Enterprise Systems Engineering requires processes. These processes span and can transform the enterprise.<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] (SE) process as applied to the [[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 [[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)|enterprise systems engineering]] (ESE) is that it “determines the balance between [[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:<br />
<BLOCKQUOTE><br />
“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><br />
<br />
===Balancing Effectiveness versus Efficiency===<br />
Ackoff tells us that:<br />
''<BLOCKQUOTE><br />
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'''.<br />
<br />
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)<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
===Value Stream Analysis===<br />
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. <br />
<br />
[[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.)]]<br />
<br />
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 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).<br />
<br />
==Enterprise Management Process Areas==<br />
Martin (2010) has determined that the following four processes are needed in ESE beyond the traditional SE processes in support of enterprise management activities:<br />
#Strategic technical planning,<br />
#Capability-based planning analysis,<br />
#Technology and standards planning, and<br />
#Enterprise evaluation and assessment.<br />
<br />
The interactions between these four processes are illustrated below, along with their interactions with other processes that deal with architecture, requirements, risk, and opportunity.<br />
<br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|600px|'''Figure 2. Enterprise Systems Engineering Process Activities.''' (SEBoK Original)]]<br />
<br />
===Strategic Technical Planning===<br />
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. <br />
<br />
This process uses the roadmaps developed during technology and standards planning (TSP). 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)|risk]] to avoid or an [[Opportunity (glossary)|opportunity]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
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.<br />
<br />
===Capability-Based Planning Analysis===<br />
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.<br />
<br />
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 (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.<br />
<br />
In some domains there may be [[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.)<br />
<br />
[[File:ESE-F02.png|thumb|center|800px|'''Figure 3. Organizational, System & Operational Capabilities.''' (SEBoK Original)]]<br />
<br />
===Technology and Standards Planning===<br />
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.<br />
<br />
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]]).<br />
<br />
===Enterprise Evaluation and Assessment===<br />
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.<br />
<br />
This process establishes a [[measurement (glossary)|measurement]] 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)|robustness]] and [[agility (glossary)|agility]] of the enterprise.<br />
<br />
Roberts states that EE&A must go beyond traditional system evaluation and assessment practices (Roberts 2006). He says that this process area:<br />
<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.”</BLOCKQUOTE><br />
Key characteristics of this activity are the following:<br />
<BLOCKQUOTE><br />
*Multi-scale analysis,<br />
*Early and continuous operational involvement,<br />
*Lightweight command and control (C2) capability representations,<br />
*Developmental versions available for assessment,<br />
*Minimal infrastructure,<br />
*Flexible modeling and simulation (M&S), operator-in-the-loop (OITL), and hardware-in-the-loop (HWIL) capabilities, and<br />
*In-line, continuous performance monitoring and selective forensics. (Roberts 2006)</BLOCKQUOTE><br />
<br />
[[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 [[model (glossary)|model]] to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010). The [[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). <br />
<br />
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 (glossary)|architecture]].<br />
<br />
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.<br />
<br />
==Enterprise Portfolio Considerations==<br />
===Opportunity Assessment and Management===<br />
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:<br />
<BLOCKQUOTE><br />
''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)<br />
</BLOCKQUOTE><br />
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.<br />
<br />
[[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.]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)|product]] 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 (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).<br />
<br />
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.<br />
<br />
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 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<br />
<br />
==ESE Process Elements==<br />
As a result of the synthesis outlined above, the ESE process elements to be used at the enterprise scale are as follows:<br />
#Strategic Technical Planning,<br />
#Capability-Based Planning Analysis,<br />
#Technology and Standards Planning,<br />
#Enterprise Evaluation and Assessment,<br />
#Opportunity and Risk Assessment and Management,<br />
#Enterprise Architecture and Conceptual Design,<br />
#Enterprise Requirements Definition and Management,<br />
#Program and Project Detailed Design and Implementation,<br />
#Program Integration and Interfaces,<br />
#Program Validation and Verification,<br />
#Portfolio and Program Deployment and Post Deployment, and<br />
#Portfolio and Program Life Cycle Support.<br />
<br />
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.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Ackoff, R.L. 1989. "From Data to Wisdom." ''Journal of Applied Systems Analysis,'' 16: 3-9. <br />
<br />
Bernus, P., L. Nemes, and G. Schmidt, eds. 2003. ''"Handbook on Enterprise Architecture"'', Berlin & Heidelberg, Germany: Springer-Verlag. <br />
<br />
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.<br />
<br />
DoD. 2010. "DoD architecture framework (DoDAF)". Version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hillson, D. 2004. ''Effective Opportunity Management for Projects: Exploiting Positive Risk.'' Petersfield, Hampshire, UK; New York, NY: Rick Doctor & Partners; Marcel Dekker, Inc. <br />
<br />
Hines, P. and N. Rich. 1997. "The Seven Value Stream Mapping Tools." ''International Journal of Operations & Production Management,'' 1(17).<br />
<br />
ISO 15704. 2000. ''Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 15704:2000. <br />
<br />
ISO/IEC 42010. 2011. ''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:2011. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Martin, J.N., 2006. "An Enterprise Architecture Process Incorporating Knowledge Modeling Methods." Ph. D. dissertation, George Mason University. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
NATO. 2010. "NATO Architecture Framework (NAF)." version 3.1. Brussels, Belgium: North Atlantic Treaty Organization. <br />
<br />
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. <br />
<br />
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. <br />
<br />
Rother, M. 2009. ''Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results.'' New York, NY, USA: McGraw-Hill.<br />
<br />
Rother, M. and J. Shook. 1999. ''Learning to See: Value-Stream Mapping to Create Value and Eliminate MUDA.'' Cambridge, MA, USA: Lean Enterprise Institute.<br />
<br />
Spewak, S.H. 1992. ''Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology.'' New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf Accessed on September 2, 2011. <br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html Accessed September 7, 2011.<br />
<br />
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. <br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal, 26(3): 276-92.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''"[[Design of Enterprise Systems: Theory, Architecture, and Methods]]."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
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. <br />
<br />
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.<br />
<br />
===Additional References===<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Holt, J. and S. Perry. 2010. ''Modelling enterprise architectures''. Stevenage: Institution of Engineering and Technology (IET).<br />
<br />
Kaplan, R. and D. Norton. 1996. ''The Balanced Scorecard: Translating Strategy into Action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
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.<br />
<br />
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. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=46744
Enterprise Systems Engineering Key Concepts
2012-11-28T15:11:29Z
<p>Janthony: /* Closing the Gap */</p>
<hr />
<div>The purpose of traditional systems engineering (TSE) is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[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 [[organization (glossary)|organization]] where information-intensive systems are becoming central elements of the organization’s [[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 [[context (glossary)|context]] of government [[acquisition (glossary)|acquisition]] of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control systems).<br />
<br />
ESE encompasses this traditional role in system acquisition, but also incorporates [[enterprise (glossary)|enterprise]] strategic [[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).<br />
<br />
==Closing the Gap==<br />
ESE practices have undergone significant development recently.<br />
<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
<br />
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 [[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:<br />
*strategic technical planning,<br />
*enterprise architecture,<br />
*capabilities-based planning analysis,<br />
*technology planning, and<br />
*enterprise analysis and assessment.<br />
<br />
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 15288 standard (2008).<br />
<br />
[[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.]]<br />
<br />
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)|project]]. In MITRE, this restricted definition was referred to as TSE. Many have taken a wider view seeking to apply SE to the “whole system” and “whole [[Life Cycle (glossary)|life cycle]].” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on [[operational (glossary)|operational]] purpose. Elliott and Deasley (2007) discuss the differences between development phase SE and in-service SE.<br />
<br />
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 [[portfolio (glossary)|portfolio]]. 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 a work by Rebovich and White (2011).<br />
<br />
==Role of Requirements in ESE==<br />
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).<br />
<br />
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)|governance]] priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:<br />
<br />
<BLOCKQUOTE><br />
“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.” (Swarz et al. 2006) (See also [[Complexity]])<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
==Enterprise Entities and Relationships==<br />
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. <br />
<br />
:<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 [[Data Center (glossary)|data center]], data warehouse, and other such facilities and equipment used across one or more organizations.</I><br />
<br />
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).<br />
<br />
{|<br />
|+'''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.<br />
!Asset Domains<br />
!Concept Domains<br />
|-<br />
|Application and Software Domain<br />
Data Domain<br />
Document Domain<br />
Infrastructure and Hardware Domain<br />
IT Product Domain<br />
IT Service Domain<br />
Location Domain<br />
Organization Domain<br />
Product and Service Domain<br />
Services Portfolio Management Domain<br />
|Analysis Domain<br />
Financial Domain<br />
General Domain<br />
Information Domain<br />
IT Architecture Domain<br />
Knowledge and Skill Domain<br />
Market Domain<br />
Policy Domain<br />
Process Domain<br />
Resource Domain<br />
Strategy Domain<br />
Timeline Domain<br />
Transition Domain<br />
|}<br />
<br />
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.<br />
<br />
[[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.]]<br />
<br />
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 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.<br />
<br />
==Enterprise Architecture Frameworks & Methodologies==<br />
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 informal, based on more rigorous modeling tools and methods. ISO/IEC 42010 (2011) specifies how to create architecture descriptions. <br />
<br />
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 Architecture (glossary)|enterprise architecture]]. <br />
<br />
Urbaczewski and Mrdalj (2006) provide an overview and comparison of five prominent architectural frameworks, including:<br />
* the Zachman Framework for Enterprise Architecture (Zachman 1992), <br />
* the Department of Defense Architecture Framework (DoDAF) (DoD 2010), <br />
* the Federal Enterprise Architecture Framework (FEAF) (FEA 2001), <br />
* the Treasury Enterprise Architecture Framework (TEAF) (US Treasury 2000), <br />
* and The Open Group Architectural Framework (TOGAF) (TOGAF 2009).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Carlock, P. and R. Fenton. 2001. “System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations,” ''Systems Engineering, 4(4): 242-261.<br />
<br />
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.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
DoD. 2010. ''DoD Architecture Framework (DoDAF)'', version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Elliott, C. and P. Deasley. 2007. "Creating Systems that Work--Principles of Engineering Systems for the 21st Century." (17). London, England, UK: Royal Academy of Engineering.<br />
<br />
FEA. 2001. "Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001." Available at [https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf].<br />
<br />
Friedman, G. and A.P. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." ''Systems Engineering,'' 7(1): 84-96. <br />
<br />
Hall, A.D. 1989. ''"Metasystems Methodology: A New Synthesis and Unification."'' International series on systems science and engineering. 1st ed. Vol. 3. Oxford, UK: Pergamon Press. <br />
<br />
Hitchins, D. 1993. ''"Putting Systems to Work."'' New York, NY, USA: John Wiley & Sons. <br />
<br />
ISO/IEC 158288. 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
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. <br />
<br />
MITRE. 2004. "MITRE 2004 Annual Report." McLean, VA, USA: MITRE Corporation. <br />
<br />
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. <br />
<br />
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.<br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Sage, A P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf/ Accessed September 7, 2011.<br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
Urbaczewski, L. and S. Mrdalj. 2006. "A Comparison of Enterprise Architecture Frameworks." ''Issues in Information Systems.'' 7(2):18-26.<br />
<br />
US Treasury. 2000. ''Treasury Enterprise Architecture Framework.,'' version 1. Washington, DC, USA: US Department of the Treasury Chief Information Officer Council. July 2000.<br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal,'' 26(3): 276-92.<br />
<br />
===Primary References===<br />
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. <br />
<br />
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.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “[[An Enterprise Systems Engineering Model]].” INCOSE Symposium Proceedings.<br />
<br />
===Additional References===<br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture.'' https://www.aogea.org/journal.<br />
<br />
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.<br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available at: http://trak.sourceforge.net/index.html.<br />
<br />
Vernadat, F.B. 1996. ''Enterprise Modelling and Integration - Principles and Applications.'' London, UK: Chapman and Hall. <br />
----<br />
<center>[[Related Business Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Process Activities|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=46743
Enterprise Systems Engineering Key Concepts
2012-11-28T15:10:58Z
<p>Janthony: /* Closing the Gap */</p>
<hr />
<div>The purpose of traditional systems engineering (TSE) is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[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 [[organization (glossary)|organization]] where information-intensive systems are becoming central elements of the organization’s [[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 [[context (glossary)|context]] of government [[acquisition (glossary)|acquisition]] of very large, complex military and civil systems (e.g., F22 fighter jet and air traffic control systems).<br />
<br />
ESE encompasses this traditional role in system acquisition, but also incorporates [[enterprise (glossary)|enterprise]] strategic [[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).<br />
<br />
==Closing the Gap==<br />
ESE practices have undergone significant development recently.<br />
<br />
<BLOCKQUOTE><br />
“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)<br />
</BLOCKQUOTE><br />
<br />
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 [[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:<br />
*strategic technical planning<br />
*enterprise architecture<br />
*capabilities-based planning analysis<br />
*technology planning<br />
*enterprise analysis and assessment<br />
<br />
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 15288 standard (2008).<br />
<br />
[[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.]]<br />
<br />
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)|project]]. In MITRE, this restricted definition was referred to as TSE. Many have taken a wider view seeking to apply SE to the “whole system” and “whole [[Life Cycle (glossary)|life cycle]].” For example, Hitchins (1993) sets out a holistic, whole-life, wider system view of SE centered on [[operational (glossary)|operational]] purpose. Elliott and Deasley (2007) discuss the differences between development phase SE and in-service SE.<br />
<br />
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 [[portfolio (glossary)|portfolio]]. 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 a work by Rebovich and White (2011).<br />
<br />
==Role of Requirements in ESE==<br />
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).<br />
<br />
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)|governance]] priorities, evolving technologies, and user expectations. An enterprise consists of people, processes, and technology where the people act as “agents” of the enterprise:<br />
<br />
<BLOCKQUOTE><br />
“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.” (Swarz et al. 2006) (See also [[Complexity]])<br />
</BLOCKQUOTE><br />
<br />
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.<br />
<br />
==Enterprise Entities and Relationships==<br />
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. <br />
<br />
:<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 [[Data Center (glossary)|data center]], data warehouse, and other such facilities and equipment used across one or more organizations.</I><br />
<br />
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).<br />
<br />
{|<br />
|+'''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.<br />
!Asset Domains<br />
!Concept Domains<br />
|-<br />
|Application and Software Domain<br />
Data Domain<br />
Document Domain<br />
Infrastructure and Hardware Domain<br />
IT Product Domain<br />
IT Service Domain<br />
Location Domain<br />
Organization Domain<br />
Product and Service Domain<br />
Services Portfolio Management Domain<br />
|Analysis Domain<br />
Financial Domain<br />
General Domain<br />
Information Domain<br />
IT Architecture Domain<br />
Knowledge and Skill Domain<br />
Market Domain<br />
Policy Domain<br />
Process Domain<br />
Resource Domain<br />
Strategy Domain<br />
Timeline Domain<br />
Transition Domain<br />
|}<br />
<br />
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.<br />
<br />
[[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.]]<br />
<br />
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 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.<br />
<br />
==Enterprise Architecture Frameworks & Methodologies==<br />
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 informal, based on more rigorous modeling tools and methods. ISO/IEC 42010 (2011) specifies how to create architecture descriptions. <br />
<br />
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 Architecture (glossary)|enterprise architecture]]. <br />
<br />
Urbaczewski and Mrdalj (2006) provide an overview and comparison of five prominent architectural frameworks, including:<br />
* the Zachman Framework for Enterprise Architecture (Zachman 1992), <br />
* the Department of Defense Architecture Framework (DoDAF) (DoD 2010), <br />
* the Federal Enterprise Architecture Framework (FEAF) (FEA 2001), <br />
* the Treasury Enterprise Architecture Framework (TEAF) (US Treasury 2000), <br />
* and The Open Group Architectural Framework (TOGAF) (TOGAF 2009).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Carlock, P. and R. Fenton. 2001. “System of Systems (SoS) Enterprise Systems Engineering for Information-Intensive Organizations,” ''Systems Engineering, 4(4): 242-261.<br />
<br />
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.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
DoD. 2010. ''DoD Architecture Framework (DoDAF)'', version 2.0. Washington, DC: U.S. Department of Defense (DoD). <br />
<br />
Elliott, C. and P. Deasley. 2007. "Creating Systems that Work--Principles of Engineering Systems for the 21st Century." (17). London, England, UK: Royal Academy of Engineering.<br />
<br />
FEA. 2001. "Federal Enterprise Architecture – Practical Guide, version 1.0, February 2001." Available at [https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf https://secure.cio.noaa.gov/hpcc/docita/files/a_practical_guide_to_federal_enterprise_architecture.pdf].<br />
<br />
Friedman, G. and A.P. Sage. 2004. "Case Studies of Systems Engineering and Management in Systems Acquisition." ''Systems Engineering,'' 7(1): 84-96. <br />
<br />
Hall, A.D. 1989. ''"Metasystems Methodology: A New Synthesis and Unification."'' International series on systems science and engineering. 1st ed. Vol. 3. Oxford, UK: Pergamon Press. <br />
<br />
Hitchins, D. 1993. ''"Putting Systems to Work."'' New York, NY, USA: John Wiley & Sons. <br />
<br />
ISO/IEC 158288. 2008. ''Systems and Software Engineering — System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
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. <br />
<br />
MITRE. 2004. "MITRE 2004 Annual Report." McLean, VA, USA: MITRE Corporation. <br />
<br />
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. <br />
<br />
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.<br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Sage, A P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework." Version 9. http://www.opengroup.org/togaf/ Accessed September 7, 2011.<br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
Urbaczewski, L. and S. Mrdalj. 2006. "A Comparison of Enterprise Architecture Frameworks." ''Issues in Information Systems.'' 7(2):18-26.<br />
<br />
US Treasury. 2000. ''Treasury Enterprise Architecture Framework.,'' version 1. Washington, DC, USA: US Department of the Treasury Chief Information Officer Council. July 2000.<br />
<br />
Zachman, J.A. 1992. "Extending and Formalizing the Framework for Information Systems Architecture." ''IBM Systems Journal,'' 31(3): 590-616. <br />
<br />
Zachman, J.A. 1987. "A Framework for Information Systems Architectures." ''IBM Systems Journal,'' 26(3): 276-92.<br />
<br />
===Primary References===<br />
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. <br />
<br />
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.<br />
<br />
Swarz, R.S., J.K. DeRosa, and G. Rebovich 2006. “[[An Enterprise Systems Engineering Model]].” INCOSE Symposium Proceedings.<br />
<br />
===Additional References===<br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture.'' https://www.aogea.org/journal.<br />
<br />
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.<br />
<br />
TRAK. 2011. "TRAK Enterprise Architecture Framework." Accessed September 7, 2011. Available at: http://trak.sourceforge.net/index.html.<br />
<br />
Vernadat, F.B. 1996. ''Enterprise Modelling and Integration - Principles and Applications.'' London, UK: Chapman and Hall. <br />
----<br />
<center>[[Related Business Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Process Activities|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=46742
Related Business Activities
2012-11-28T15:09:42Z
<p>Janthony: /* Multi-Level Enterprises */</p>
<hr />
<div><br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) activities:<br />
*mission and strategic planning,<br />
*business processes and information Management,<br />
*performance management,<br />
*portfolio management,<br />
*resource allocation and budgeting, and<br />
*program and project management.<br />
<br />
==Introduction==<br />
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product systems engineering (PSE) (Martin 2010 and 2011). PSE is mainly involved at the project level and collaborates with project management activities, and gets somewhat involved in program management and the resource allocation and budgeting activities. On the other hand, ESE is heavily involved in the higher level activities from the program management level and up. Both ESE and PSE have key roles to play in the enterprise.<br />
<br />
[[File:ESE-F09.png|thumb|center|600px|'''Figure 1. Related Business Activities (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Shown in this manner, these business activities can be considered to be separate processes with a clear precedence in terms of which process drives other processes. TSE uses “[[Requirement (glossary)|requirements]]” to specify the essential features and functions of a system. An [[Enterprise (glossary)|enterprise]], on the other hand, typically uses goals and objectives to specify the fundamental characteristics of desired enterprise operational capabilities. The enterprise objectives and strategies are used in [[Portfolio Management (glossary)|portfolio management]] to discriminate between options and to select the appropriate balanced [[Portfolio (glossary)|portfolio]] of systems and other enterprise resources.<br />
<br />
The first three activities listed above are covered in [[Enabling Businesses and Enterprises]]. The other business management activities are described in more detail below in regards to how they relate to ESE.<br />
<br />
==Business Management Cycles==<br />
PDCA stands for "plan-do-check-act" and is a commonly used iterative management process as seen in the figure below. It is also known as the Deming circle or the Shewhart cycle after its two key proponents (Deming 1986; Shewhart 1939). ESE should use the PDCA cycle as one of its fundamental tenets. For example, after ESE develops the enterprise transformation plan, execution of the planned improvements are monitored (i.e., “checked” in the PDCA cycle) to ensure they achieve the targeted performance levels. If not, then action needs to be taken (i.e., “act” in the PDCA cycle) to correct the situation and re-planning may be required. ESE can also use the PDCA cycle in its support of the 'business as usual' efforts, such as the annual budgeting and business development planning activities.<br />
<br />
[[File:ESE-F10.png|thumb|250px|center|'''Figure 2. PDCA Cycle.''' (Source: http://en.wikipedia.org/wiki/PDCA. Accessed July 2010 from the Public Domain. Diagram by Karn G. Bulsuk (http://blog.bulsuk.com))]]<br />
<br />
It is also worth mentioning the utility of using Boyd's OODA loop (observe, orient, decide, and act) to augment PDCA. This could be accomplished by first using the OODA loop (http://en.wikipedia.org/wiki/OODA_loop), which is continuous in situation awareness, and then followed by using the PDCA approach, which is discrete, having goals, resources, usually time limits, etc. (Lawson 2010).<br />
<br />
==Portfolio Management==<br />
[[Program (glossary)| Program]] and [[Project (glossary)|project]] managers direct their activities as they relate to the systems under their control. Enterprise management, on the other hand, is involved in directing the portfolio of items that are necessary to achieving the enterprise goals and objectives. This can be accomplished by using Portfolio Management:<br />
<br />
<BLOCKQUOTE><br />
“Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals―while honoring constraints imposed by customers, strategic objectives, or external real-world factors.” (http://en.wikipedia.org/wiki/Project_portfolio_management)</BLOCKQUOTE><br />
<br />
The enterprise may not actually own these portfolio items. They could rent or lease these items, or they could have permission to use them through licensing or assignment. The enterprise may only need part of a system (e.g., one bank of switching circuits in a system) or may need an entire [[System of Systems (SoS) (glossary)|system of systems]] (SoS) (e.g., switching systems, distribution systems, billing systems, provisioning systems, etc.). Notice that the portfolio items are not just those items related to the systems that [[Systems Engineering (glossary)|systems engineering]] (SE) deals with. These could also include platforms (like ships and oil drilling derricks), facilities (like warehouses and airports), land and rights of way (like railroad property easements and municipal covenants), and intellectual property (like patents and trademarks).<br />
<br />
The investment community has been using portfolio management for a long time to manage a set of investments to maximize return for a given level of acceptable [[risk (glossary)|risk]]. These techniques have also been applied to a portfolio of “projects” within the enterprise (Kaplan 2009). However, it should be noted that an enterprise is not merely a portfolio of projects. The enterprise portfolio consists of whatever systems, organizations, facilities, intellectual property, and other resources that are needed to help the enterprise achieve its goals and objectives.<br />
<br />
Portfolio management in the context of ESE is well addressed in the following article: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/enterprise_planning_management/portfolio_management.html (MITRE 2010).<br />
<br />
==Resource Allocation and Budgeting==<br />
The resource allocation and budgeting (RA&B) activity is driven by the portfolio management definition of the optimal set of portfolio elements. [[Capability (glossary)|Capability]] gaps are mapped to the elements of the portfolio, and resources are assigned to programs (or other organizational elements) based on the criticality of these gaps. Resources come in the form of people and facilities, policies and practices, money and energy, and platforms and infrastructure. Allocation of resources could also involve the distribution or assignment of corporate assets, like communication bandwidth, manufacturing floor space, computing power, intellectual property licenses, and so on. Resource allocation and budgeting is typically done on an annual basis, but more agile enterprises will make this a more continuous process. Some of the resource allocation decisions deal with base operational organizations that are not project related.<br />
<br />
It is sometimes the case that RA&B is part of portfolio management (PfM). But as can be seen in Figure 1, it is sometimes useful and practical to separate these two activities. PfM usually recommends changes to the enterprise portfolio, but RA&B takes these PfM considerations into mind along with inputs from the business process and information management and the performance management activities. Furthermore, PfM is usually an annual or biannual activity whereas RA&B is often done more frequently. RA&B may need to execute ''ad hoc'' when perturbations happen, such as funding cuts, schedule slips, performance targets missed, strategic goals changed, and so on.<br />
<br />
==Program and Project Management==<br />
Within the enterprise, TSE is typically applied inside a project to engineer a single system (or perhaps a small number of related systems). If there is a SoS or a large, [[complex (glossary)|complex]] individual system to be engineered, then this might be handled at the program level, but is sometimes handled at the project level, depending on the size and [[complexity (glossary)|complexity]] of the system of interest (See also [[Complexity]]). <br />
<br />
There are commonly three basic types of projects in an enterprise. A development project takes a conceptual notion of a system and turns this into a realizable design. A production project takes the realizable design for a system and turns this into physical copies (or instantiations). An operations “project” directly operates each system or supports the operation by others. (Base operations are sometimes called "line organizations" and are not typically called projects per se, but should nonetheless be considered as key elements to be considered when adjusting the enterprise portfolio.) The operations project can also be involved in maintaining the system or supporting maintenance by others. A program can have all three types of projects active simultaneously for the same system, as in this example:<br />
*Project A is developing System X version 3.<br />
*Project B is operating and maintaining System X version 2.<br />
*Project C is maintaining System X version 1 in a warehouse as a backup in case of emergencies.<br />
<br />
Project management uses TSE as a tool to ensure a well-structured project and to help identify and mitigate [[Cost (glossary)|cost]], schedule, and technical risks involved with system development and implementation. The project level is where the TSE process is most often employed (Martin 1997; ISO/IEC 15288 2008; Wasson 2006; INCOSE 2010; Blanchard and Fabrycky 2010).<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
"The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this, a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives..."<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
"A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters." (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enterprise Governance==<br />
ESE is also concerned with the way in which organizations and embedded management and technical functions work together to achieve success at the enterprise level. Governance frameworks provide the essential additional structure and controls needed to both ‘steer a steady ship’ (during business as usual) and to ‘plot a course to a new place’ (during business transformation). <br />
<br />
Such frameworks can be designed by recognizing that there are enduring management concerns that need to be addressed and by applying the principle of economy. For example, a particular concern for most organizations is linking the control of projects to business drivers and objectives. This leads to a requirement for a governance body to both approve the initiation of projects, and to regularly review their progress, continuing relevance, and if necessary, mutual coherence in the light of developments inside and outside the enterprise. <br />
<br />
This might be achieved by delegating some or all of the roles; depending on circumstances, the enterprise might be driven towards top-down or a more collective, peer-to-peer approach—or even a combination of the two for different functions. Governance bodies and management roles can be engineered in this way against a common set of management concerns. Governance may also include the maintenance of common technical standards and their promulgation and use throughout relevant projects. See Bryant (2012) for more information on governance.<br />
<br />
==Multi-Level Enterprises==<br />
An enterprise does not always have full control over the ESE processes. In some cases, an enterprise may have no direct control over the resources necessary to make programs and projects successful. For example, the Internet Engineering Task Force (IETF) is responsible for the “smooth operation of the Internet,” yet it controls none of the requisite resources.<br />
<br />
<BLOCKQUOTE><br />
“The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. … The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year.” (IETF 2010a)</BLOCKQUOTE><br />
<br />
The IETF has “influence” over these resources even though it does not have direct control: "The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues" (IETF 2010b).<br />
<br />
The ESE processes might be allocated between a “parent” enterprise and “children” enterprises, as shown in the figure below (Martin 2010). The parent enterprise, in this case, has no resources. These resources are owned by the subordinate child enterprises. Therefore, the parent enterprise does not implement the processes of resource allocation and budgeting, program management, and project management.<br />
<br />
The parent enterprise may have an explicit contract with the subordinate enterprises, or, as in some cases, there is merely a “working relationship” without the benefit of legal obligations. The parent enterprise will expect performance feedback from the lower level to ensure that it can meet its own objectives. Where the feedback indicates a deviation from the plan, the objectives can be adjusted or the portfolio is modified to compensate.<br />
<br />
[[File:ESE-F11.png|thumb|center|600px|'''Figure 3. Parent and Child Enterprise Relationships (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprises X, Y, and Z in the situation shown above will cooperate with each other to the extent that they honor the direction and guidance from the parent enterprise. These enterprises may not even be aware of each other, and, in this case, would be unwittingly cooperating with each other. The situation becomes more complex if each enterprise has its own set of strategic goals and objectives as shown in the figure below.<br />
<br />
[[File:ESE-F12.png|thumb|center|600px|'''Figure 4. Mission and Strategic Planning at All Levels of Cooperating Enterprises (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
These separate, sub-enterprise objectives will sometimes conflict with the objectives of the parent enterprise. Furthermore, each subordinate enterprise has its own strategic objectives that might conflict with those of its siblings. The situation shown here is not uncommon, and illustrates an enterprise of enterprises, so to speak. This highlights the need for the application of SE at the enterprise level to handle the complex interactions and understand the overall behavior of the enterprise as a whole. TSE practices can be used, to a certain extent, but these need to be expanded to incorporate additional tools and techniques.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Bryant, P., 2012. "Modelling Governance within Business Architecture using Topic Mapping." Paper presented at 22nd Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-12 July 2012, Rome, Italy.<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Deming, W.E. 1986. ''Out of the Crisis.'' Cambridge, MA, USA: MIT Press, MIT Center for Advance Engineering Study.<br />
<br />
IETF. 2010a. "Overview of the IETF." in Internet Engineering Task Force, Internet Society (ISOC) [database online]. 2010a Available from http://www.ietf.org/overview.html Accessed September 6, 2011. <br />
<br />
IETF. 2010b. "The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force (draft-hoffman-tao4677bix-10)". in Internet Engineering Task Force, Internet Society (ISOC) [database online]. http://www.ietf.org/tao.html#intro Accessed September 6, 2011. <br />
<br />
INCOSE. 2010. ''INCOSE systems engineering handbook, version 3.2.'' San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2. <br />
<br />
ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
Kaplan, J. 2009. ''Strategic IT portfolio management: Governing enterprise transformation.'' Waltham, Massachusetts,USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications<br />
<br />
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Paper presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
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.<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MITRE. 2012. "Enterprise Engineering." In ''Systems Engineering Guide.'' MITRE Corporation. http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Shewhart, W.A. 1939. ''Statistical Method from the Viewpoint of Quality Control.'' New York, NY, USA: Dover Publications.<br />
<br />
Wasson, C.S. 2006. ''System Analysis, Design and Development.'' Hoboken, NJ, USA: John Wiley and Sons Ltd.<br />
<br />
===Primary References===<br />
Martin, J.N. 2011. "[[Transforming the Enterprise Using a Systems Approach]]." Paper presented at 21st International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Paper presented at 20th International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA.<br />
<br />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Drucker, P.F. 1994. "The Theory of Business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Haeckel, S.H. 2003. "Leading on demand businesses–Executives as architects." ''IBM Systems Journal,'' 42(3): 405-13. <br />
<br />
Kaplan, R. and D. Norton. 1996. ''The balanced scorecard: Translating strategy into action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
Lissack, M.R. 2000. "Complexity Metaphors and the Management of a Knowledge Based Enterprise: An Exploration of Discovery." PhD Dissertation in Business Administration. Henley Management College. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
----<br />
<center>[[The Enterprise as a System|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Key Concepts|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=46741
Related Business Activities
2012-11-28T15:08:47Z
<p>Janthony: /* Program and Project Management */</p>
<hr />
<div><br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) activities:<br />
*mission and strategic planning,<br />
*business processes and information Management,<br />
*performance management,<br />
*portfolio management,<br />
*resource allocation and budgeting, and<br />
*program and project management.<br />
<br />
==Introduction==<br />
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product systems engineering (PSE) (Martin 2010 and 2011). PSE is mainly involved at the project level and collaborates with project management activities, and gets somewhat involved in program management and the resource allocation and budgeting activities. On the other hand, ESE is heavily involved in the higher level activities from the program management level and up. Both ESE and PSE have key roles to play in the enterprise.<br />
<br />
[[File:ESE-F09.png|thumb|center|600px|'''Figure 1. Related Business Activities (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Shown in this manner, these business activities can be considered to be separate processes with a clear precedence in terms of which process drives other processes. TSE uses “[[Requirement (glossary)|requirements]]” to specify the essential features and functions of a system. An [[Enterprise (glossary)|enterprise]], on the other hand, typically uses goals and objectives to specify the fundamental characteristics of desired enterprise operational capabilities. The enterprise objectives and strategies are used in [[Portfolio Management (glossary)|portfolio management]] to discriminate between options and to select the appropriate balanced [[Portfolio (glossary)|portfolio]] of systems and other enterprise resources.<br />
<br />
The first three activities listed above are covered in [[Enabling Businesses and Enterprises]]. The other business management activities are described in more detail below in regards to how they relate to ESE.<br />
<br />
==Business Management Cycles==<br />
PDCA stands for "plan-do-check-act" and is a commonly used iterative management process as seen in the figure below. It is also known as the Deming circle or the Shewhart cycle after its two key proponents (Deming 1986; Shewhart 1939). ESE should use the PDCA cycle as one of its fundamental tenets. For example, after ESE develops the enterprise transformation plan, execution of the planned improvements are monitored (i.e., “checked” in the PDCA cycle) to ensure they achieve the targeted performance levels. If not, then action needs to be taken (i.e., “act” in the PDCA cycle) to correct the situation and re-planning may be required. ESE can also use the PDCA cycle in its support of the 'business as usual' efforts, such as the annual budgeting and business development planning activities.<br />
<br />
[[File:ESE-F10.png|thumb|250px|center|'''Figure 2. PDCA Cycle.''' (Source: http://en.wikipedia.org/wiki/PDCA. Accessed July 2010 from the Public Domain. Diagram by Karn G. Bulsuk (http://blog.bulsuk.com))]]<br />
<br />
It is also worth mentioning the utility of using Boyd's OODA loop (observe, orient, decide, and act) to augment PDCA. This could be accomplished by first using the OODA loop (http://en.wikipedia.org/wiki/OODA_loop), which is continuous in situation awareness, and then followed by using the PDCA approach, which is discrete, having goals, resources, usually time limits, etc. (Lawson 2010).<br />
<br />
==Portfolio Management==<br />
[[Program (glossary)| Program]] and [[Project (glossary)|project]] managers direct their activities as they relate to the systems under their control. Enterprise management, on the other hand, is involved in directing the portfolio of items that are necessary to achieving the enterprise goals and objectives. This can be accomplished by using Portfolio Management:<br />
<br />
<BLOCKQUOTE><br />
“Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals―while honoring constraints imposed by customers, strategic objectives, or external real-world factors.” (http://en.wikipedia.org/wiki/Project_portfolio_management)</BLOCKQUOTE><br />
<br />
The enterprise may not actually own these portfolio items. They could rent or lease these items, or they could have permission to use them through licensing or assignment. The enterprise may only need part of a system (e.g., one bank of switching circuits in a system) or may need an entire [[System of Systems (SoS) (glossary)|system of systems]] (SoS) (e.g., switching systems, distribution systems, billing systems, provisioning systems, etc.). Notice that the portfolio items are not just those items related to the systems that [[Systems Engineering (glossary)|systems engineering]] (SE) deals with. These could also include platforms (like ships and oil drilling derricks), facilities (like warehouses and airports), land and rights of way (like railroad property easements and municipal covenants), and intellectual property (like patents and trademarks).<br />
<br />
The investment community has been using portfolio management for a long time to manage a set of investments to maximize return for a given level of acceptable [[risk (glossary)|risk]]. These techniques have also been applied to a portfolio of “projects” within the enterprise (Kaplan 2009). However, it should be noted that an enterprise is not merely a portfolio of projects. The enterprise portfolio consists of whatever systems, organizations, facilities, intellectual property, and other resources that are needed to help the enterprise achieve its goals and objectives.<br />
<br />
Portfolio management in the context of ESE is well addressed in the following article: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/enterprise_planning_management/portfolio_management.html (MITRE 2010).<br />
<br />
==Resource Allocation and Budgeting==<br />
The resource allocation and budgeting (RA&B) activity is driven by the portfolio management definition of the optimal set of portfolio elements. [[Capability (glossary)|Capability]] gaps are mapped to the elements of the portfolio, and resources are assigned to programs (or other organizational elements) based on the criticality of these gaps. Resources come in the form of people and facilities, policies and practices, money and energy, and platforms and infrastructure. Allocation of resources could also involve the distribution or assignment of corporate assets, like communication bandwidth, manufacturing floor space, computing power, intellectual property licenses, and so on. Resource allocation and budgeting is typically done on an annual basis, but more agile enterprises will make this a more continuous process. Some of the resource allocation decisions deal with base operational organizations that are not project related.<br />
<br />
It is sometimes the case that RA&B is part of portfolio management (PfM). But as can be seen in Figure 1, it is sometimes useful and practical to separate these two activities. PfM usually recommends changes to the enterprise portfolio, but RA&B takes these PfM considerations into mind along with inputs from the business process and information management and the performance management activities. Furthermore, PfM is usually an annual or biannual activity whereas RA&B is often done more frequently. RA&B may need to execute ''ad hoc'' when perturbations happen, such as funding cuts, schedule slips, performance targets missed, strategic goals changed, and so on.<br />
<br />
==Program and Project Management==<br />
Within the enterprise, TSE is typically applied inside a project to engineer a single system (or perhaps a small number of related systems). If there is a SoS or a large, [[complex (glossary)|complex]] individual system to be engineered, then this might be handled at the program level, but is sometimes handled at the project level, depending on the size and [[complexity (glossary)|complexity]] of the system of interest (See also [[Complexity]]). <br />
<br />
There are commonly three basic types of projects in an enterprise. A development project takes a conceptual notion of a system and turns this into a realizable design. A production project takes the realizable design for a system and turns this into physical copies (or instantiations). An operations “project” directly operates each system or supports the operation by others. (Base operations are sometimes called "line organizations" and are not typically called projects per se, but should nonetheless be considered as key elements to be considered when adjusting the enterprise portfolio.) The operations project can also be involved in maintaining the system or supporting maintenance by others. A program can have all three types of projects active simultaneously for the same system, as in this example:<br />
*Project A is developing System X version 3.<br />
*Project B is operating and maintaining System X version 2.<br />
*Project C is maintaining System X version 1 in a warehouse as a backup in case of emergencies.<br />
<br />
Project management uses TSE as a tool to ensure a well-structured project and to help identify and mitigate [[Cost (glossary)|cost]], schedule, and technical risks involved with system development and implementation. The project level is where the TSE process is most often employed (Martin 1997; ISO/IEC 15288 2008; Wasson 2006; INCOSE 2010; Blanchard and Fabrycky 2010).<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
"The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this, a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives..."<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
"A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters." (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enterprise Governance==<br />
ESE is also concerned with the way in which organizations and embedded management and technical functions work together to achieve success at the enterprise level. Governance frameworks provide the essential additional structure and controls needed to both ‘steer a steady ship’ (during business as usual) and to ‘plot a course to a new place’ (during business transformation). <br />
<br />
Such frameworks can be designed by recognizing that there are enduring management concerns that need to be addressed and by applying the principle of economy. For example, a particular concern for most organizations is linking the control of projects to business drivers and objectives. This leads to a requirement for a governance body to both approve the initiation of projects, and to regularly review their progress, continuing relevance, and if necessary, mutual coherence in the light of developments inside and outside the enterprise. <br />
<br />
This might be achieved by delegating some or all of the roles; depending on circumstances, the enterprise might be driven towards top-down or a more collective, peer-to-peer approach—or even a combination of the two for different functions. Governance bodies and management roles can be engineered in this way against a common set of management concerns. Governance may also include the maintenance of common technical standards and their promulgation and use throughout relevant projects. See Bryant (2012) for more information on governance.<br />
<br />
==Multi-Level Enterprises==<br />
An enterprise does not always have full control over the ESE processes. In some cases, an enterprise may have no direct control over the resources necessary to make programs and projects successful. For example, the Internet Engineering Task Force (IETF) is responsible for the “smooth operation of the Internet,” yet it controls none of the requisite resources.<br />
<br />
<BLOCKQUOTE><br />
''The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. … The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year.'' (IETF 2010a)</BLOCKQUOTE><br />
<br />
The IETF has “influence” over these resources even though it does not have direct control: "The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues" (IETF 2010b).<br />
<br />
The ESE processes might be allocated between a “parent” enterprise and “children” enterprises, as shown in the figure below (Martin 2010). The parent enterprise, in this case, has no resources. These resources are owned by the subordinate child enterprises. Therefore, the parent enterprise does not implement the processes of resource allocation and budgeting, program management, and project management.<br />
<br />
The parent enterprise may have an explicit contract with the subordinate enterprises, or, as in some cases, there is merely a “working relationship” without the benefit of legal obligations. The parent enterprise will expect performance feedback from the lower level to ensure that it can meet its own objectives. Where the feedback indicates a deviation from the plan, the objectives can be adjusted or the portfolio is modified to compensate.<br />
<br />
[[File:ESE-F11.png|thumb|center|600px|'''Figure 3. Parent and Child Enterprise Relationships (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprises X, Y, and Z in the situation shown above will cooperate with each other to the extent that they honor the direction and guidance from the parent enterprise. These enterprises may not even be aware of each other, and, in this case, would be unwittingly cooperating with each other. The situation becomes more complex if each enterprise has its own set of strategic goals and objectives as shown in the figure below.<br />
<br />
[[File:ESE-F12.png|thumb|center|600px|'''Figure 4. Mission and Strategic Planning at All Levels of Cooperating Enterprises (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
These separate, sub-enterprise objectives will sometimes conflict with the objectives of the parent enterprise. Furthermore, each subordinate enterprise has its own strategic objectives that might conflict with those of its siblings. The situation shown here is not uncommon, and illustrates an enterprise of enterprises, so to speak. This highlights the need for the application of SE at the enterprise level to handle the complex interactions and understand the overall behavior of the enterprise as a whole. TSE practices can be used, to a certain extent, but these need to be expanded to incorporate additional tools and techniques.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Bryant, P., 2012. "Modelling Governance within Business Architecture using Topic Mapping." Paper presented at 22nd Annual International Council on Systems Engineering (INCOSE) International Symposium, 9-12 July 2012, Rome, Italy.<br />
<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''Systems Engineering and Analysis'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Deming, W.E. 1986. ''Out of the Crisis.'' Cambridge, MA, USA: MIT Press, MIT Center for Advance Engineering Study.<br />
<br />
IETF. 2010a. "Overview of the IETF." in Internet Engineering Task Force, Internet Society (ISOC) [database online]. 2010a Available from http://www.ietf.org/overview.html Accessed September 6, 2011. <br />
<br />
IETF. 2010b. "The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force (draft-hoffman-tao4677bix-10)". in Internet Engineering Task Force, Internet Society (ISOC) [database online]. http://www.ietf.org/tao.html#intro Accessed September 6, 2011. <br />
<br />
INCOSE. 2010. ''INCOSE systems engineering handbook, version 3.2.'' San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2. <br />
<br />
ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
Kaplan, J. 2009. ''Strategic IT portfolio management: Governing enterprise transformation.'' Waltham, Massachusetts,USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM). <br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications<br />
<br />
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Paper presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
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.<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MITRE. 2012. "Enterprise Engineering." In ''Systems Engineering Guide.'' MITRE Corporation. http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Shewhart, W.A. 1939. ''Statistical Method from the Viewpoint of Quality Control.'' New York, NY, USA: Dover Publications.<br />
<br />
Wasson, C.S. 2006. ''System Analysis, Design and Development.'' Hoboken, NJ, USA: John Wiley and Sons Ltd.<br />
<br />
===Primary References===<br />
Martin, J.N. 2011. "[[Transforming the Enterprise Using a Systems Approach]]." Paper presented at 21st International Council on Systems Engineering (INCOSE) International Symposium, 20-23 June, 2011, Denver, CO, USA.<br />
<br />
Martin, J.N. 2010. "[[An Enterprise Systems Engineering Framework]]." Paper presented at 20th International Council on Systems Engineering (INCOSE) International Symposium, 12-15 July, 2010, Chicago, IL, USA.<br />
<br />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Drucker, P.F. 1994. "The Theory of Business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Haeckel, S.H. 2003. "Leading on demand businesses–Executives as architects." ''IBM Systems Journal,'' 42(3): 405-13. <br />
<br />
Kaplan, R. and D. Norton. 1996. ''The balanced scorecard: Translating strategy into action.'' Cambridge, MA, USA: Harvard Business School Press. <br />
<br />
Lissack, M.R. 2000. "Complexity Metaphors and the Management of a Knowledge Based Enterprise: An Exploration of Discovery." PhD Dissertation in Business Administration. Henley Management College. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
----<br />
<center>[[The Enterprise as a System|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Key Concepts|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=The_Enterprise_as_a_System&diff=46737
The Enterprise as a System
2012-11-28T15:06:09Z
<p>Janthony: /* Enterprise Engineering */</p>
<hr />
<div>To enable more efficient and effective [[enterprise (glossary)]] transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than as a collection of functions connected solely by information systems and shared facilities (Rouse 2005 and 2009; Lawson 2010). What distinguishes the [[design (glossary)]] of enterprise systems from product systems is the inclusion of people as a [[component (glossary)]] of the system, not merely as a [[user (glossary)|user]]/operator of the system. <br />
<br />
<blockquote>“The term 'enterprise system' has taken on a narrow meaning of only the information system an organization uses. Research and [[Project (glossary)|project]] experience has taught us that to design a good enterprise system, we need to adopt a much broader understanding of enterprise systems. The greater view of enterprise systems is inclusive of the [[Process (glossary)|processes]] the system supports, the people who work in the system, and the information [and knowledge] content of the system.” (Giachetti 2010) </blockquote><br />
<br />
It is worth noting that the concept of "service" systems also includes people in the system. The thoughts above do not take this into account, primarily since their perspectives come mainly from a product system experience. The practice of service systems engineering is relatively new and is an emerging discipline. For more information on this, see the articles on [[Service Systems Engineering]].<br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process. These elements in the enterprise can be treated as a "system" and the processes, methods, and tools ESE can be applied.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 1). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 1. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs, and Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enabling the Enterprise==<br />
ESE, by virtue of its inherent trans-disciplinarity (Sage 2000, 158-169) in dealing with problems that are large in scale and scope, can better enable the enterprise to become more effective and efficient. The [[Complex (glossary)|complex]] nature of many enterprise problems and situations usually goes beyond the abilities of standard tools and techniques provided to business school graduates (See also [[Complexity]]). ESE can augment the standard business management methods using the tools and methods from the SE discipline to more robustly analyze and evaluate the enterprise as a holistic system. A more general viewpoint, or “view,” for dealing with the enterprise consisting of scale, granularity, mindset, and time frame is provided by White (2007) and by McCarter and White (2009, 71-105).<br />
<br />
ESE can provide the enablers to address the concerns of enterprise executives as shown in Table 1 (Rouse 2009). The methods for dealing with, and the special characteristics of, complex adaptive systems must be properly considered when adapting traditional systems engineering (TSE) practices for use at the enterprise level—many of which come out of the systems science and systems thinking domains (von Bertalanffy 1968; Weinberg and Weinberg 1988; Miller and Page 2007; Rouse 2008, 17-25). For an approach to [[Complex Adaptive System (CAS) (glossary)|complex adaptive systems (CAS)]] engineering, refer to White (2009, 1-16) and to McCarter and White (2009, 71-105).<br />
<br />
{|<br />
|+'''Table 1. Executive Concerns and SE Enablers (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.<br />
!Executive Concerns<br />
!SE Enablers<br />
|-<br />
|'''Identifying ends, means, and scope and candidate changes'''<br />
|System complexity analysis to compare "as is" and "to be" enterprises<br />
|-<br />
|'''Evaluating changes in terms of process behaviors and performance'''<br />
|Organizational simulation of process flows and relationships<br />
|-<br />
|'''Assessing economics in terms of investments, operating costs, and returns'''<br />
|Economic modeling in terms of cash flows, volatility, and options<br />
|-<br />
|'''Defining the new enterprise in terms of processes and their integration'''<br />
|Enterprise architecting in terms of workflow, processes, and levels of maturity<br />
|-<br />
|'''Designing a strategy to change the culture for selected changes'''<br />
|Organizational and cultural change via leadership, vision, strategy, and incentives<br />
|-<br />
|'''Developing transformation action plans in terms of what, when, and who'''<br />
|Implementation planning in terms of tasks, schedule, people, and information<br />
|}<br />
<br />
==Enterprise Engineering==<br />
Another distinction is that “enterprise [[design (glossary)|design]] does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly ''being designed''” (Giachetti 2010) [emphasis in original]. Giachetti calls this new discipline “enterprise engineering.” We consider the enterprise engineering set of practices to be equivalent to what we call [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) in this article. <br />
<br />
<BLOCKQUOTE><br />
“The body of knowledge for enterprise engineering is evolving under such titles as enterprise engineering, business engineering, and [[Enterprise Architecture (glossary)|enterprise architecture]]…. Many systems and software engineering principles are applicable to enterprise engineering, but enterprise engineering’s unique complexities require additional principles…. Enterprise engineering’s intent is to deliver a targeted level of enterprise performance in terms of shareholder value or customer satisfaction…. Enterprise engineering methods include modeling; simulation; total quality management; change management; and bottleneck, cost, workflow, and value-added analysis.” (Joannou 2007)<br />
</BLOCKQUOTE><br />
<br />
==Supersystem Constructs==<br />
===System of Systems (SoS) ===<br />
The phrase "[[System of Systems (SoS) (glossary)|system of systems]]” (SoS) is commonly used, but there is no widespread agreement on its exact meaning, nor on how it can be distinguished from a conventional system. A system is generally understood to be a collection of elements that interact in such a manner that it exhibits behavior that the elements themselves cannot exhibit. Each element (or component) of the system can be regarded as a system in its own right. Therefore, the phrase “system of systems” can technically be used for any system and, as such, would be a superfluous term. However, the meaning of this phrase has been examined in detail by (Maier 1998, 267-284), and his definition has been adopted by some people (AFSAB 2005). Maier provides this definition:<br />
<br />
<BLOCKQUOTE><br />
A SoS is an assemblage of components which individually may be regarded as systems, and which possess two additional properties:<br />
*<B>Operational Independence of the Components:</B> If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own; and<br />
*<B>Managerial Independence of the Components:</B> The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems (Maier 1998, 267-284).<br />
</BLOCKQUOTE><br />
<br />
Maier goes on further saying that “the commonly cited characteristics of systems-of-systems ([[Complexity (glossary)|complexity]] of the component systems and geographic distribution) are not the appropriate taxonomic classifiers” (Maier 1998, 267-284). Four kinds of SoS have been defined (Dahmann, Lane, and Rebovich 2008).<br />
<br />
For further details on SoS, see the ''Systems Engineering Guide for SoS'' developed by the US Department of Defense (DoD) (DUS(AT) 2008). Also, see the [[Systems of Systems (SoS)]] knowledge area.<br />
<br />
===Federation of Systems (FoS)===<br />
Different from the SoS concept, but related to it in several ways, is the concept called “federation of systems” (FoS). This concept might apply when there is a very limited amount of centralized control and authority (Sage and Cuppan 2001, 325-345; Sage and Rouse 2009). Each system in an FoS is very strongly in control of its own destiny, but “chooses” to participate in the FOS for its own good and the good of the “country,” so to speak. It is a coalition of the willing. An FoS is generally characterized by significant autonomy, heterogeneity, and geographic distribution or dispersion (Krygiel 1999). Krygiel defined a taxonomy of systems showing the relationships among conventional systems, SoSs, and FOSs. <br />
<br />
This taxonomy has three dimensions: autonomy, heterogeneity, and dispersion. An FoS would have a larger value on each of these three dimensions than a non-federated SoS. An “Enterprise System,” as described above, could be considered to be an FoS if it rates highly on these three dimensions. However, it is possible for an enterprise to have components that are not highly autonomous, that are relatively homogeneous, and are geographically close together. Therefore, it would be incorrect to say that an enterprise is necessarily the same as an FoS.<br />
<br />
Dove points out that in order for a large enterprise to survive in the twenty-first century, it must be more [[Agile (glossary)|agile]] and [[Robustness (glossary)|robust]] (Dove 1999 and 2001). Handy (1992, 59-67) describes a federalist approach called “New Federalism” which identifies the need for structuring of [[Loose Coupling (glossary)|loosely coupled]] organizations to help them adapt to the rapid changes inherent in the Information Age. This leads to the need for virtual organizations where alliances can be quickly formed to handle the challenges of newly identified [[Threat (glossary)|threats]] and a rapidly changing marketplace (Handy 1995, 2-8). Handy sets out to define a number of federalist political principles that could be applicable to an FoS. Handy’s principles have been tailored to the domain of systems engineering (SE) and management by Sage and Cuppan (2001, 325-345):<br />
*Subsidiarity,<br />
*Interdependence,<br />
*Uniform and standardized way of doing business,<br />
*Separation of powers,<br />
*Dual citizenship, and<br />
*Scales of SE.<br />
<br />
===Scales of SE===<br />
According to Maier’s definition, not every enterprise would be called a SoS since the systems within the enterprise do not usually meet the criteria of operational and managerial independence. In fact, one of the key purposes of an enterprise is to explicitly establish operational dependence between systems that the enterprise owns and/or operates in order to maximize the efficiency and effectiveness of the enterprise as a whole. Therefore, it is more proper to treat an enterprise system and an SoS as different types of things, with different properties and characteristics. This distinction is illustrated in the figure below, where three corresponding categories of SE are shown (DeRosa 2005; Swarz et al. 2006).<br />
<br />
It is true that an enterprise can be treated as a system itself and is comprised of many systems within the enterprise, but this discussion will reserve the term SoS to those systems that meet the criteria of operational and managerial independence. This distinction was also used within the MITRE Corporation in their ESE Office (Rebovich and White 2011).<br />
<br />
[[File:ESE-F07.png|thumb|center|600px|'''Figure 2. Different Groupings and Patterns Revealed at Different Scales (DeRosa 2005).''' Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved. All other rights are reserved by the copyright owner.]]<br />
<br />
===Relationships between Enterprise and SoS===<br />
An enterprise may require a particular [[Operational Capability (glossary)|operational capability]] that is brought into being by connecting together a chain of systems that together achieve that [[Capability (glossary)|capability]]. Any one of these systems in the chain cannot by itself provide this capability. The desired capability is the emergent property of this chain of systems. This chain of systems is sometimes called an SoS. However, the enterprise that requires this capability rarely has direct control over all the systems necessary to provide this full capability. This situation is illustrated in the figure below (Martin 2010).<br />
<br />
[[File:ESE-F08.png|thumb|center|500px|'''Figure 3. Relationships Between an Enterprise and SoSs (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise E1 (in the example above) has full control over SoS2, but not full control over SoS1. TSE can be applied to the individual systems (S1, S2, …, S53) shown within each enterprise, but needs to be augmented with additional activities to handle SoS and enterprise kinds of issues.<br />
<br />
There is a general issue regarding dealing with enterprises in this situation: there are at least two enterprises related to any particular SoS. First, there is the enterprise of builders/developers comprising projects and programs, which have to be organized appropriately and adopt special types of architectural principles. Second, there is the enterprise of users (those who use the products and service provided by the first enterprise), which has to exercise its own sort of agility. How the first enterprise designs systems to allow the second to operate is the core issue.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
AFSAB. 2005. "Report on System-of-Systems Engineering for Air Force Capability Development." Washington, DC: U.S. Air Force Scientific Advisory Board (AFSAB), U.S. Air Force, SAB-TR-05-04.<br />
<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering''. November 2008.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Dove, R. 2001. ''Response Ability: The Language, Structure, and Culture of the Agile Organization.'' New York, NY, USA: John Wiley & Sons. <br />
<br />
Dove, R. 1999. "Knowledge Management, Response Ability, and the Agile Enterprise." in Paradigm Shift International [database online]. Questa, NM, USA. Available from http://www.parshift.com/docs/KmRaAeX.htm Accessed September 6, 2011.<br />
<br />
DUS(AT). 2008. ''Systems Engineering Guide for Systems of Systems, Version 1.0.'' Washington, D.C.: Deputy Under Secretary of Defense for Acquisition and Technology (DUS(AT))/U.S. Department of Defense (DoD) http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed September 6, 2011.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Handy, C. 1995. "Trust and the Virtual Organization." ''Harvard Business Review'' 73(3) (May-June): 2-8. <br />
<br />
Handy, C. 1992. "Balancing Corporate Power: A New Federalist Paper." ''Harvard Business Review 70'' (6) (November/December): 59-67.<br />
<br />
Joannou, P. 2007. "Enterprise, Systems, and Software — the Need for Integration." ''Computer'', IEEE, May 2007.<br />
<br />
Krygiel, A.J. 1999. "Behind the Wizard's Curtain: An Integration Environment for a System of Systems." Arlington, VA, USA: C4ISR Cooperative Research Program (CCRP).<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 1'' (4): 267-84.<br />
<br />
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.<br />
<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"ystems of systems engineering: Principles and applications.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105 <br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the enterprise as a system." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering,'' 38(1) (Spring 2008): 17-25. <br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation. ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE), 8(2): 138-50. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In eds. M. A. Somerville, D. Rappaport ''Transdiciplinarity: Recreating Integrated Knowledge.'' 158-169. Oxford, UK: EOLSS Publishers. <br />
<br />
Sage, A., and C. Cuppan. 2001. "On the Systems Engineering and Management of Systems of Systems and Federations of Systems." ''Information-Knowledge-Systems Management Journal,'' 2(4) (December 2001): 325-45.<br />
<br />
Sage, A.P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S. , J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings.<br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications.'' Revised ed. New York, NY: Braziller. <br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''General Principles of Systems Design.'' New York, NY: Dorset House Publishing Company. <br />
<br />
White, B. E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA.<br />
<br />
===Primary References===<br />
<br />
Giachetti, R.E. 2010. [[Design of Enterprise Systems: Theory, Architecture, and Methods]]. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Joannou, P. 2007. [[Enterprise, Systems, and Software—The Need for Integration]]. IEEE ''Computer'', May 2007.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE)'' 8(2): 138-50.<br />
<br />
===Additional References===<br />
<br />
Arnold, S. and H. Lawson. 2004. "Viewing Systems From a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Nightingale, D., and D. Rhodes. 2004. "Enterprise systems architecting: Emerging art and science within engineering systems." Paper presented at Engineering Systems Symposium, Massachusetts Institute of Technology (MIT), 29-31 March, 2004, Boston, MA, USA. <br />
<br />
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. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
Ring, J. 2004. "Intelligent Enterprises." INCOSE ''INSIGHT,'' 6(2) (January 2004). <br />
<br />
Ring, J. 2004. "Seeing an Enterprise as a System." 'INCOSE 'INSIGHT,'' 6(2) (January 2004). <br />
<br />
Valerdi, R., D. Nightingale, and C. Blackburn. 2009. "Enterprises as Systems: Context, Boundaries, and Practical Implications." ''Information-Knowledge-Systems Management Journal.'' 7(4) (December 2008): 377-99. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Background|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Related Business Activities|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=The_Enterprise_as_a_System&diff=46735
The Enterprise as a System
2012-11-28T15:03:56Z
<p>Janthony: /* Projects, Programs, and Businesses */</p>
<hr />
<div>To enable more efficient and effective [[enterprise (glossary)]] transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than as a collection of functions connected solely by information systems and shared facilities (Rouse 2005 and 2009; Lawson 2010). What distinguishes the [[design (glossary)]] of enterprise systems from product systems is the inclusion of people as a [[component (glossary)]] of the system, not merely as a [[user (glossary)|user]]/operator of the system. <br />
<br />
<blockquote>“The term 'enterprise system' has taken on a narrow meaning of only the information system an organization uses. Research and [[Project (glossary)|project]] experience has taught us that to design a good enterprise system, we need to adopt a much broader understanding of enterprise systems. The greater view of enterprise systems is inclusive of the [[Process (glossary)|processes]] the system supports, the people who work in the system, and the information [and knowledge] content of the system.” (Giachetti 2010) </blockquote><br />
<br />
It is worth noting that the concept of "service" systems also includes people in the system. The thoughts above do not take this into account, primarily since their perspectives come mainly from a product system experience. The practice of service systems engineering is relatively new and is an emerging discipline. For more information on this, see the articles on [[Service Systems Engineering]].<br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process. These elements in the enterprise can be treated as a "system" and the processes, methods, and tools ESE can be applied.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 1). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 1. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs, and Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”<br />
</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enabling the Enterprise==<br />
ESE, by virtue of its inherent trans-disciplinarity (Sage 2000, 158-169) in dealing with problems that are large in scale and scope, can better enable the enterprise to become more effective and efficient. The [[Complex (glossary)|complex]] nature of many enterprise problems and situations usually goes beyond the abilities of standard tools and techniques provided to business school graduates (See also [[Complexity]]). ESE can augment the standard business management methods using the tools and methods from the SE discipline to more robustly analyze and evaluate the enterprise as a holistic system. A more general viewpoint, or “view,” for dealing with the enterprise consisting of scale, granularity, mindset, and time frame is provided by White (2007) and by McCarter and White (2009, 71-105).<br />
<br />
ESE can provide the enablers to address the concerns of enterprise executives as shown in Table 1 (Rouse 2009). The methods for dealing with, and the special characteristics of, complex adaptive systems must be properly considered when adapting traditional systems engineering (TSE) practices for use at the enterprise level—many of which come out of the systems science and systems thinking domains (von Bertalanffy 1968; Weinberg and Weinberg 1988; Miller and Page 2007; Rouse 2008, 17-25). For an approach to [[Complex Adaptive System (CAS) (glossary)|complex adaptive systems (CAS)]] engineering, refer to White (2009, 1-16) and to McCarter and White (2009, 71-105).<br />
<br />
{|<br />
|+'''Table 1. Executive Concerns and SE Enablers (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.<br />
!Executive Concerns<br />
!SE Enablers<br />
|-<br />
|'''Identifying ends, means, and scope and candidate changes'''<br />
|System complexity analysis to compare "as is" and "to be" enterprises<br />
|-<br />
|'''Evaluating changes in terms of process behaviors and performance'''<br />
|Organizational simulation of process flows and relationships<br />
|-<br />
|'''Assessing economics in terms of investments, operating costs, and returns'''<br />
|Economic modeling in terms of cash flows, volatility, and options<br />
|-<br />
|'''Defining the new enterprise in terms of processes and their integration'''<br />
|Enterprise architecting in terms of workflow, processes, and levels of maturity<br />
|-<br />
|'''Designing a strategy to change the culture for selected changes'''<br />
|Organizational and cultural change via leadership, vision, strategy, and incentives<br />
|-<br />
|'''Developing transformation action plans in terms of what, when, and who'''<br />
|Implementation planning in terms of tasks, schedule, people, and information<br />
|}<br />
<br />
==Enterprise Engineering==<br />
Another distinction is that “enterprise [[design (glossary)|design]] does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly ''being designed''” (Giachetti 2010) [emphasis in original]. Giachetti calls this new discipline “enterprise engineering.” We consider the enterprise engineering set of practices to be equivalent to what we call [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) in this article. <br />
<br />
<BLOCKQUOTE><br />
''The body of knowledge for enterprise engineering is evolving under such titles as enterprise engineering, business engineering, and [[Enterprise Architecture (glossary)|enterprise architecture]]…. Many systems and software engineering principles are applicable to enterprise engineering, but enterprise engineering’s unique complexities require additional principles…. Enterprise engineering’s intent is to deliver a targeted level of enterprise performance in terms of shareholder value or customer satisfaction…. Enterprise engineering methods include modeling; simulation; total quality management; change management; and bottleneck, cost, workflow, and value-added analysis.'' (Joannou 2007)<br />
</BLOCKQUOTE><br />
<br />
==Supersystem Constructs==<br />
===System of Systems (SoS) ===<br />
The phrase "[[System of Systems (SoS) (glossary)|system of systems]]” (SoS) is commonly used, but there is no widespread agreement on its exact meaning, nor on how it can be distinguished from a conventional system. A system is generally understood to be a collection of elements that interact in such a manner that it exhibits behavior that the elements themselves cannot exhibit. Each element (or component) of the system can be regarded as a system in its own right. Therefore, the phrase “system of systems” can technically be used for any system and, as such, would be a superfluous term. However, the meaning of this phrase has been examined in detail by (Maier 1998, 267-284), and his definition has been adopted by some people (AFSAB 2005). Maier provides this definition:<br />
<br />
<BLOCKQUOTE><br />
A SoS is an assemblage of components which individually may be regarded as systems, and which possess two additional properties:<br />
*<B>Operational Independence of the Components:</B> If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own; and<br />
*<B>Managerial Independence of the Components:</B> The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems (Maier 1998, 267-284).<br />
</BLOCKQUOTE><br />
<br />
Maier goes on further saying that “the commonly cited characteristics of systems-of-systems ([[Complexity (glossary)|complexity]] of the component systems and geographic distribution) are not the appropriate taxonomic classifiers” (Maier 1998, 267-284). Four kinds of SoS have been defined (Dahmann, Lane, and Rebovich 2008).<br />
<br />
For further details on SoS, see the ''Systems Engineering Guide for SoS'' developed by the US Department of Defense (DoD) (DUS(AT) 2008). Also, see the [[Systems of Systems (SoS)]] knowledge area.<br />
<br />
===Federation of Systems (FoS)===<br />
Different from the SoS concept, but related to it in several ways, is the concept called “federation of systems” (FoS). This concept might apply when there is a very limited amount of centralized control and authority (Sage and Cuppan 2001, 325-345; Sage and Rouse 2009). Each system in an FoS is very strongly in control of its own destiny, but “chooses” to participate in the FOS for its own good and the good of the “country,” so to speak. It is a coalition of the willing. An FoS is generally characterized by significant autonomy, heterogeneity, and geographic distribution or dispersion (Krygiel 1999). Krygiel defined a taxonomy of systems showing the relationships among conventional systems, SoSs, and FOSs. <br />
<br />
This taxonomy has three dimensions: autonomy, heterogeneity, and dispersion. An FoS would have a larger value on each of these three dimensions than a non-federated SoS. An “Enterprise System,” as described above, could be considered to be an FoS if it rates highly on these three dimensions. However, it is possible for an enterprise to have components that are not highly autonomous, that are relatively homogeneous, and are geographically close together. Therefore, it would be incorrect to say that an enterprise is necessarily the same as an FoS.<br />
<br />
Dove points out that in order for a large enterprise to survive in the twenty-first century, it must be more [[Agile (glossary)|agile]] and [[Robustness (glossary)|robust]] (Dove 1999 and 2001). Handy (1992, 59-67) describes a federalist approach called “New Federalism” which identifies the need for structuring of [[Loose Coupling (glossary)|loosely coupled]] organizations to help them adapt to the rapid changes inherent in the Information Age. This leads to the need for virtual organizations where alliances can be quickly formed to handle the challenges of newly identified [[Threat (glossary)|threats]] and a rapidly changing marketplace (Handy 1995, 2-8). Handy sets out to define a number of federalist political principles that could be applicable to an FoS. Handy’s principles have been tailored to the domain of systems engineering (SE) and management by Sage and Cuppan (2001, 325-345):<br />
*Subsidiarity,<br />
*Interdependence,<br />
*Uniform and standardized way of doing business,<br />
*Separation of powers,<br />
*Dual citizenship, and<br />
*Scales of SE.<br />
<br />
===Scales of SE===<br />
According to Maier’s definition, not every enterprise would be called a SoS since the systems within the enterprise do not usually meet the criteria of operational and managerial independence. In fact, one of the key purposes of an enterprise is to explicitly establish operational dependence between systems that the enterprise owns and/or operates in order to maximize the efficiency and effectiveness of the enterprise as a whole. Therefore, it is more proper to treat an enterprise system and an SoS as different types of things, with different properties and characteristics. This distinction is illustrated in the figure below, where three corresponding categories of SE are shown (DeRosa 2005; Swarz et al. 2006).<br />
<br />
It is true that an enterprise can be treated as a system itself and is comprised of many systems within the enterprise, but this discussion will reserve the term SoS to those systems that meet the criteria of operational and managerial independence. This distinction was also used within the MITRE Corporation in their ESE Office (Rebovich and White 2011).<br />
<br />
[[File:ESE-F07.png|thumb|center|600px|'''Figure 2. Different Groupings and Patterns Revealed at Different Scales (DeRosa 2005).''' Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved. All other rights are reserved by the copyright owner.]]<br />
<br />
===Relationships between Enterprise and SoS===<br />
An enterprise may require a particular [[Operational Capability (glossary)|operational capability]] that is brought into being by connecting together a chain of systems that together achieve that [[Capability (glossary)|capability]]. Any one of these systems in the chain cannot by itself provide this capability. The desired capability is the emergent property of this chain of systems. This chain of systems is sometimes called an SoS. However, the enterprise that requires this capability rarely has direct control over all the systems necessary to provide this full capability. This situation is illustrated in the figure below (Martin 2010).<br />
<br />
[[File:ESE-F08.png|thumb|center|500px|'''Figure 3. Relationships Between an Enterprise and SoSs (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise E1 (in the example above) has full control over SoS2, but not full control over SoS1. TSE can be applied to the individual systems (S1, S2, …, S53) shown within each enterprise, but needs to be augmented with additional activities to handle SoS and enterprise kinds of issues.<br />
<br />
There is a general issue regarding dealing with enterprises in this situation: there are at least two enterprises related to any particular SoS. First, there is the enterprise of builders/developers comprising projects and programs, which have to be organized appropriately and adopt special types of architectural principles. Second, there is the enterprise of users (those who use the products and service provided by the first enterprise), which has to exercise its own sort of agility. How the first enterprise designs systems to allow the second to operate is the core issue.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
AFSAB. 2005. "Report on System-of-Systems Engineering for Air Force Capability Development." Washington, DC: U.S. Air Force Scientific Advisory Board (AFSAB), U.S. Air Force, SAB-TR-05-04.<br />
<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering''. November 2008.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Dove, R. 2001. ''Response Ability: The Language, Structure, and Culture of the Agile Organization.'' New York, NY, USA: John Wiley & Sons. <br />
<br />
Dove, R. 1999. "Knowledge Management, Response Ability, and the Agile Enterprise." in Paradigm Shift International [database online]. Questa, NM, USA. Available from http://www.parshift.com/docs/KmRaAeX.htm Accessed September 6, 2011.<br />
<br />
DUS(AT). 2008. ''Systems Engineering Guide for Systems of Systems, Version 1.0.'' Washington, D.C.: Deputy Under Secretary of Defense for Acquisition and Technology (DUS(AT))/U.S. Department of Defense (DoD) http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed September 6, 2011.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Handy, C. 1995. "Trust and the Virtual Organization." ''Harvard Business Review'' 73(3) (May-June): 2-8. <br />
<br />
Handy, C. 1992. "Balancing Corporate Power: A New Federalist Paper." ''Harvard Business Review 70'' (6) (November/December): 59-67.<br />
<br />
Joannou, P. 2007. "Enterprise, Systems, and Software — the Need for Integration." ''Computer'', IEEE, May 2007.<br />
<br />
Krygiel, A.J. 1999. "Behind the Wizard's Curtain: An Integration Environment for a System of Systems." Arlington, VA, USA: C4ISR Cooperative Research Program (CCRP).<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 1'' (4): 267-84.<br />
<br />
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.<br />
<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"ystems of systems engineering: Principles and applications.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105 <br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the enterprise as a system." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering,'' 38(1) (Spring 2008): 17-25. <br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation. ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE), 8(2): 138-50. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In eds. M. A. Somerville, D. Rappaport ''Transdiciplinarity: Recreating Integrated Knowledge.'' 158-169. Oxford, UK: EOLSS Publishers. <br />
<br />
Sage, A., and C. Cuppan. 2001. "On the Systems Engineering and Management of Systems of Systems and Federations of Systems." ''Information-Knowledge-Systems Management Journal,'' 2(4) (December 2001): 325-45.<br />
<br />
Sage, A.P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S. , J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings.<br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications.'' Revised ed. New York, NY: Braziller. <br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''General Principles of Systems Design.'' New York, NY: Dorset House Publishing Company. <br />
<br />
White, B. E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA.<br />
<br />
===Primary References===<br />
<br />
Giachetti, R.E. 2010. [[Design of Enterprise Systems: Theory, Architecture, and Methods]]. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Joannou, P. 2007. [[Enterprise, Systems, and Software—The Need for Integration]]. IEEE ''Computer'', May 2007.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE)'' 8(2): 138-50.<br />
<br />
===Additional References===<br />
<br />
Arnold, S. and H. Lawson. 2004. "Viewing Systems From a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Nightingale, D., and D. Rhodes. 2004. "Enterprise systems architecting: Emerging art and science within engineering systems." Paper presented at Engineering Systems Symposium, Massachusetts Institute of Technology (MIT), 29-31 March, 2004, Boston, MA, USA. <br />
<br />
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. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
Ring, J. 2004. "Intelligent Enterprises." INCOSE ''INSIGHT,'' 6(2) (January 2004). <br />
<br />
Ring, J. 2004. "Seeing an Enterprise as a System." 'INCOSE 'INSIGHT,'' 6(2) (January 2004). <br />
<br />
Valerdi, R., D. Nightingale, and C. Blackburn. 2009. "Enterprises as Systems: Context, Boundaries, and Practical Implications." ''Information-Knowledge-Systems Management Journal.'' 7(4) (December 2008): 377-99. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Background|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Related Business Activities|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=The_Enterprise_as_a_System&diff=46733
The Enterprise as a System
2012-11-28T15:02:13Z
<p>Janthony: </p>
<hr />
<div>To enable more efficient and effective [[enterprise (glossary)]] transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than as a collection of functions connected solely by information systems and shared facilities (Rouse 2005 and 2009; Lawson 2010). What distinguishes the [[design (glossary)]] of enterprise systems from product systems is the inclusion of people as a [[component (glossary)]] of the system, not merely as a [[user (glossary)|user]]/operator of the system. <br />
<br />
<blockquote>“The term 'enterprise system' has taken on a narrow meaning of only the information system an organization uses. Research and [[Project (glossary)|project]] experience has taught us that to design a good enterprise system, we need to adopt a much broader understanding of enterprise systems. The greater view of enterprise systems is inclusive of the [[Process (glossary)|processes]] the system supports, the people who work in the system, and the information [and knowledge] content of the system.” (Giachetti 2010) </blockquote><br />
<br />
It is worth noting that the concept of "service" systems also includes people in the system. The thoughts above do not take this into account, primarily since their perspectives come mainly from a product system experience. The practice of service systems engineering is relatively new and is an emerging discipline. For more information on this, see the articles on [[Service Systems Engineering]].<br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process. These elements in the enterprise can be treated as a "system" and the processes, methods, and tools ESE can be applied.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 1). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 1. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs, and Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
''The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...''<br />
<br />
''A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.'' (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Enabling the Enterprise==<br />
ESE, by virtue of its inherent trans-disciplinarity (Sage 2000, 158-169) in dealing with problems that are large in scale and scope, can better enable the enterprise to become more effective and efficient. The [[Complex (glossary)|complex]] nature of many enterprise problems and situations usually goes beyond the abilities of standard tools and techniques provided to business school graduates (See also [[Complexity]]). ESE can augment the standard business management methods using the tools and methods from the SE discipline to more robustly analyze and evaluate the enterprise as a holistic system. A more general viewpoint, or “view,” for dealing with the enterprise consisting of scale, granularity, mindset, and time frame is provided by White (2007) and by McCarter and White (2009, 71-105).<br />
<br />
ESE can provide the enablers to address the concerns of enterprise executives as shown in Table 1 (Rouse 2009). The methods for dealing with, and the special characteristics of, complex adaptive systems must be properly considered when adapting traditional systems engineering (TSE) practices for use at the enterprise level—many of which come out of the systems science and systems thinking domains (von Bertalanffy 1968; Weinberg and Weinberg 1988; Miller and Page 2007; Rouse 2008, 17-25). For an approach to [[Complex Adaptive System (CAS) (glossary)|complex adaptive systems (CAS)]] engineering, refer to White (2009, 1-16) and to McCarter and White (2009, 71-105).<br />
<br />
{|<br />
|+'''Table 1. Executive Concerns and SE Enablers (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.<br />
!Executive Concerns<br />
!SE Enablers<br />
|-<br />
|'''Identifying ends, means, and scope and candidate changes'''<br />
|System complexity analysis to compare "as is" and "to be" enterprises<br />
|-<br />
|'''Evaluating changes in terms of process behaviors and performance'''<br />
|Organizational simulation of process flows and relationships<br />
|-<br />
|'''Assessing economics in terms of investments, operating costs, and returns'''<br />
|Economic modeling in terms of cash flows, volatility, and options<br />
|-<br />
|'''Defining the new enterprise in terms of processes and their integration'''<br />
|Enterprise architecting in terms of workflow, processes, and levels of maturity<br />
|-<br />
|'''Designing a strategy to change the culture for selected changes'''<br />
|Organizational and cultural change via leadership, vision, strategy, and incentives<br />
|-<br />
|'''Developing transformation action plans in terms of what, when, and who'''<br />
|Implementation planning in terms of tasks, schedule, people, and information<br />
|}<br />
<br />
==Enterprise Engineering==<br />
Another distinction is that “enterprise [[design (glossary)|design]] does not occur at a single point in time like the design of most systems. Instead, enterprises evolve over time and are constantly changing, or are constantly ''being designed''” (Giachetti 2010) [emphasis in original]. Giachetti calls this new discipline “enterprise engineering.” We consider the enterprise engineering set of practices to be equivalent to what we call [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE) in this article. <br />
<br />
<BLOCKQUOTE><br />
''The body of knowledge for enterprise engineering is evolving under such titles as enterprise engineering, business engineering, and [[Enterprise Architecture (glossary)|enterprise architecture]]…. Many systems and software engineering principles are applicable to enterprise engineering, but enterprise engineering’s unique complexities require additional principles…. Enterprise engineering’s intent is to deliver a targeted level of enterprise performance in terms of shareholder value or customer satisfaction…. Enterprise engineering methods include modeling; simulation; total quality management; change management; and bottleneck, cost, workflow, and value-added analysis.'' (Joannou 2007)<br />
</BLOCKQUOTE><br />
<br />
==Supersystem Constructs==<br />
===System of Systems (SoS) ===<br />
The phrase "[[System of Systems (SoS) (glossary)|system of systems]]” (SoS) is commonly used, but there is no widespread agreement on its exact meaning, nor on how it can be distinguished from a conventional system. A system is generally understood to be a collection of elements that interact in such a manner that it exhibits behavior that the elements themselves cannot exhibit. Each element (or component) of the system can be regarded as a system in its own right. Therefore, the phrase “system of systems” can technically be used for any system and, as such, would be a superfluous term. However, the meaning of this phrase has been examined in detail by (Maier 1998, 267-284), and his definition has been adopted by some people (AFSAB 2005). Maier provides this definition:<br />
<br />
<BLOCKQUOTE><br />
A SoS is an assemblage of components which individually may be regarded as systems, and which possess two additional properties:<br />
*<B>Operational Independence of the Components:</B> If the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently. That is, the components fulfill customer-operator purposes on their own; and<br />
*<B>Managerial Independence of the Components:</B> The component systems not only can operate independently, they do operate independently. The component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems (Maier 1998, 267-284).<br />
</BLOCKQUOTE><br />
<br />
Maier goes on further saying that “the commonly cited characteristics of systems-of-systems ([[Complexity (glossary)|complexity]] of the component systems and geographic distribution) are not the appropriate taxonomic classifiers” (Maier 1998, 267-284). Four kinds of SoS have been defined (Dahmann, Lane, and Rebovich 2008).<br />
<br />
For further details on SoS, see the ''Systems Engineering Guide for SoS'' developed by the US Department of Defense (DoD) (DUS(AT) 2008). Also, see the [[Systems of Systems (SoS)]] knowledge area.<br />
<br />
===Federation of Systems (FoS)===<br />
Different from the SoS concept, but related to it in several ways, is the concept called “federation of systems” (FoS). This concept might apply when there is a very limited amount of centralized control and authority (Sage and Cuppan 2001, 325-345; Sage and Rouse 2009). Each system in an FoS is very strongly in control of its own destiny, but “chooses” to participate in the FOS for its own good and the good of the “country,” so to speak. It is a coalition of the willing. An FoS is generally characterized by significant autonomy, heterogeneity, and geographic distribution or dispersion (Krygiel 1999). Krygiel defined a taxonomy of systems showing the relationships among conventional systems, SoSs, and FOSs. <br />
<br />
This taxonomy has three dimensions: autonomy, heterogeneity, and dispersion. An FoS would have a larger value on each of these three dimensions than a non-federated SoS. An “Enterprise System,” as described above, could be considered to be an FoS if it rates highly on these three dimensions. However, it is possible for an enterprise to have components that are not highly autonomous, that are relatively homogeneous, and are geographically close together. Therefore, it would be incorrect to say that an enterprise is necessarily the same as an FoS.<br />
<br />
Dove points out that in order for a large enterprise to survive in the twenty-first century, it must be more [[Agile (glossary)|agile]] and [[Robustness (glossary)|robust]] (Dove 1999 and 2001). Handy (1992, 59-67) describes a federalist approach called “New Federalism” which identifies the need for structuring of [[Loose Coupling (glossary)|loosely coupled]] organizations to help them adapt to the rapid changes inherent in the Information Age. This leads to the need for virtual organizations where alliances can be quickly formed to handle the challenges of newly identified [[Threat (glossary)|threats]] and a rapidly changing marketplace (Handy 1995, 2-8). Handy sets out to define a number of federalist political principles that could be applicable to an FoS. Handy’s principles have been tailored to the domain of systems engineering (SE) and management by Sage and Cuppan (2001, 325-345):<br />
*Subsidiarity,<br />
*Interdependence,<br />
*Uniform and standardized way of doing business,<br />
*Separation of powers,<br />
*Dual citizenship, and<br />
*Scales of SE.<br />
<br />
===Scales of SE===<br />
According to Maier’s definition, not every enterprise would be called a SoS since the systems within the enterprise do not usually meet the criteria of operational and managerial independence. In fact, one of the key purposes of an enterprise is to explicitly establish operational dependence between systems that the enterprise owns and/or operates in order to maximize the efficiency and effectiveness of the enterprise as a whole. Therefore, it is more proper to treat an enterprise system and an SoS as different types of things, with different properties and characteristics. This distinction is illustrated in the figure below, where three corresponding categories of SE are shown (DeRosa 2005; Swarz et al. 2006).<br />
<br />
It is true that an enterprise can be treated as a system itself and is comprised of many systems within the enterprise, but this discussion will reserve the term SoS to those systems that meet the criteria of operational and managerial independence. This distinction was also used within the MITRE Corporation in their ESE Office (Rebovich and White 2011).<br />
<br />
[[File:ESE-F07.png|thumb|center|600px|'''Figure 2. Different Groupings and Patterns Revealed at Different Scales (DeRosa 2005).''' Reprinted with permission of © 2011. The MITRE Corporation. All Rights Reserved. All other rights are reserved by the copyright owner.]]<br />
<br />
===Relationships between Enterprise and SoS===<br />
An enterprise may require a particular [[Operational Capability (glossary)|operational capability]] that is brought into being by connecting together a chain of systems that together achieve that [[Capability (glossary)|capability]]. Any one of these systems in the chain cannot by itself provide this capability. The desired capability is the emergent property of this chain of systems. This chain of systems is sometimes called an SoS. However, the enterprise that requires this capability rarely has direct control over all the systems necessary to provide this full capability. This situation is illustrated in the figure below (Martin 2010).<br />
<br />
[[File:ESE-F08.png|thumb|center|500px|'''Figure 3. Relationships Between an Enterprise and SoSs (Martin 2010).''' Reprinted with permission of The Aerospace Corporation. All other rights are reserved by the copyright owner.]]<br />
<br />
Enterprise E1 (in the example above) has full control over SoS2, but not full control over SoS1. TSE can be applied to the individual systems (S1, S2, …, S53) shown within each enterprise, but needs to be augmented with additional activities to handle SoS and enterprise kinds of issues.<br />
<br />
There is a general issue regarding dealing with enterprises in this situation: there are at least two enterprises related to any particular SoS. First, there is the enterprise of builders/developers comprising projects and programs, which have to be organized appropriately and adopt special types of architectural principles. Second, there is the enterprise of users (those who use the products and service provided by the first enterprise), which has to exercise its own sort of agility. How the first enterprise designs systems to allow the second to operate is the core issue.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
AFSAB. 2005. "Report on System-of-Systems Engineering for Air Force Capability Development." Washington, DC: U.S. Air Force Scientific Advisory Board (AFSAB), U.S. Air Force, SAB-TR-05-04.<br />
<br />
Dahmann, J.S., J.A. Lane, and G. Rebovich. 2008. "Systems Engineering for Capabilities." ''CROSSTALK: The Journal of Defense Software Engineering''. November 2008.<br />
<br />
DeRosa, J.K. 2005. “Enterprise Systems Engineering,” Presented at Air Force Association, Industry Day, Day 1, Danvers, MA, USA. 4 August 2005.<br />
<br />
Dove, R. 2001. ''Response Ability: The Language, Structure, and Culture of the Agile Organization.'' New York, NY, USA: John Wiley & Sons. <br />
<br />
Dove, R. 1999. "Knowledge Management, Response Ability, and the Agile Enterprise." in Paradigm Shift International [database online]. Questa, NM, USA. Available from http://www.parshift.com/docs/KmRaAeX.htm Accessed September 6, 2011.<br />
<br />
DUS(AT). 2008. ''Systems Engineering Guide for Systems of Systems, Version 1.0.'' Washington, D.C.: Deputy Under Secretary of Defense for Acquisition and Technology (DUS(AT))/U.S. Department of Defense (DoD) http://www.acq.osd.mil/se/docs/SE-Guide-for-SoS.pdf. Accessed September 6, 2011.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Handy, C. 1995. "Trust and the Virtual Organization." ''Harvard Business Review'' 73(3) (May-June): 2-8. <br />
<br />
Handy, C. 1992. "Balancing Corporate Power: A New Federalist Paper." ''Harvard Business Review 70'' (6) (November/December): 59-67.<br />
<br />
Joannou, P. 2007. "Enterprise, Systems, and Software — the Need for Integration." ''Computer'', IEEE, May 2007.<br />
<br />
Krygiel, A.J. 1999. "Behind the Wizard's Curtain: An Integration Environment for a System of Systems." Arlington, VA, USA: C4ISR Cooperative Research Program (CCRP).<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Maier, M.W. 1998. "Architecting Principles for Systems-of-Systems." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE) 1'' (4): 267-84.<br />
<br />
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.<br />
<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"ystems of systems engineering: Principles and applications.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105 <br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the enterprise as a system." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering,'' 38(1) (Spring 2008): 17-25. <br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation. ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE), 8(2): 138-50. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In eds. M. A. Somerville, D. Rappaport ''Transdiciplinarity: Recreating Integrated Knowledge.'' 158-169. Oxford, UK: EOLSS Publishers. <br />
<br />
Sage, A., and C. Cuppan. 2001. "On the Systems Engineering and Management of Systems of Systems and Federations of Systems." ''Information-Knowledge-Systems Management Journal,'' 2(4) (December 2001): 325-45.<br />
<br />
Sage, A.P. and W.B. Rouse, eds. 2009. ''Handbook of System Engineering and Management.'' 2nd ed. New York, NY, USA: John Wiley & Sons.<br />
<br />
Swarz, R.S. , J.K. DeRosa, and G. Rebovich 2006. “An Enterprise Systems Engineering Model,” INCOSE Symposium Proceedings.<br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications.'' Revised ed. New York, NY: Braziller. <br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''General Principles of Systems Design.'' New York, NY: Dorset House Publishing Company. <br />
<br />
White, B. E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA.<br />
<br />
===Primary References===<br />
<br />
Giachetti, R.E. 2010. [[Design of Enterprise Systems: Theory, Architecture, and Methods]]. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
Joannou, P. 2007. [[Enterprise, Systems, and Software—The Need for Integration]]. IEEE ''Computer'', May 2007.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse. eds. ''Handbook of systems engineering and management.'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE)'' 8(2): 138-50.<br />
<br />
===Additional References===<br />
<br />
Arnold, S. and H. Lawson. 2004. "Viewing Systems From a Business Management Perspective." ''Systems Engineering,'' 7(3): 229. <br />
<br />
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." ''Systems Engineering,'' 4(2): 118-33. <br />
<br />
Nightingale, D., and D. Rhodes. 2004. "Enterprise systems architecting: Emerging art and science within engineering systems." Paper presented at Engineering Systems Symposium, Massachusetts Institute of Technology (MIT), 29-31 March, 2004, Boston, MA, USA. <br />
<br />
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. <br />
<br />
Rechtin, E. 1999. ''Systems Architecting of Organizations: Why Eagles can't Swim.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group. <br />
<br />
Ring, J. 2004. "Intelligent Enterprises." INCOSE ''INSIGHT,'' 6(2) (January 2004). <br />
<br />
Ring, J. 2004. "Seeing an Enterprise as a System." 'INCOSE 'INSIGHT,'' 6(2) (January 2004). <br />
<br />
Valerdi, R., D. Nightingale, and C. Blackburn. 2009. "Enterprises as Systems: Context, Boundaries, and Practical Implications." ''Information-Knowledge-Systems Management Journal.'' 7(4) (December 2008): 377-99. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering Background|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Related Business Activities|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Background&diff=46732
Enterprise Systems Engineering Background
2012-11-28T15:01:22Z
<p>Janthony: /* Works Cited */</p>
<hr />
<div>This article provides a common context for the succeeding topics in the knowledge area. <br />
<br />
==Capabilities in the Enterprise==<br />
The enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems or system elements. Since there could possibly be several organizations involved in this enterprise venture, each organization could be responsible for particular systems or perhaps for certain kinds of elements. Each organization brings their own organizational capability with them and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are illustrated below.<br />
<br />
[[File:ESE-F02.png|thumb|650px|center|'''Figure 1. Individual Competence Leads to Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
Organizational capabilities are addressed in the article on [[Systems Engineering Organizational Strategy]], and individual competencies are addressed in the article on [[Enabling Individuals]] as they relate to the principles, theories, and practices of organizational [[Behavior (glossary)|behavior]]. <br />
<br />
===Organizational Capabilities and Competencies===<br />
The word "[[capability (glossary)|capability]]" is used in [[Systems Engineering (glossary)|systems engineering]] (SE) in the sense of “the ability to do something useful under a particular set of conditions.” This article discusses three different kinds of capabilities: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. It uses the word “competence” to refer to the ability of people relative to the SE task. [[Competency (glossary)|Individual competence]], (sometimes called "competency"), contributes to, but is not the sole determinant of, organizational capability. This competence is translated to organizational capabilities through the work practices that are adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance [[Enterprise (glossary)|enterprise]] operational capability in response to [[Stakeholder (glossary)|stakeholder’s]] concerns about a problem situation. <br />
<br />
Enterprise stakeholders are the ultimate arbiters of [[value (glossary)]] for the system to be delivered. Organizational, system, and operational capabilities cannot be designed, improved, and implemented independently. The key to understanding the dependencies between capabilities is through [[Architecture (glossary)|architecture]] modeling and analysis as part of the activities described in the article called [[Enterprise Capability Management]]. “Capability engineering” is an emerging discipline that could enhance the [[Effectiveness (glossary)|effectiveness]] of [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE), which is further discussed in the article on [[Systems of Systems (SoS)]].<br />
<br />
===Organizational Design===<br />
The competencies of individuals are important to the overall organizational capability as discussed in the article on [[Enabling Individuals]]. The organizational capability is also a function of how the people, [[Team (glossary)|teams]], [[Project (glossary)|projects]], and [[Business (glossary)|businesses]] are organized. The organizational [[Design (glossary)|design]] should specify the roles, authorities, responsibilities, and accountabilities (RARA) of the organizational units to ensure the most efficient and effective operations. Effectiveness of enterprise operations is certainly driven by management principles, concepts, and approaches, but it is also largely driven by its leadership principles, concepts, and approaches. These factors are discussed in the article on [[Systems Engineering Organizational Strategy]] that discusses how to organize for effective performance of SE.<br />
<br />
Organizational [[Structure (glossary)|structure]] is tightly tied to creating value for the enterprise’s various stakeholders. Since the enterprise is made up of various elements including people, processes, technologies, and assets, the organizational structure of the people and the allocation of responsibilities for executing portions of the value stream is a “design decision” for the enterprise and hence is a key element of properly performing ESE. Organizational design is increasingly influenced by the portfolio of products and services and the degree of coupling between them. This organizational design will be based on organizational design patterns and their tradeoffs, as discussed in the article on [[Systems Engineering Organizational Strategy]]. Browning (2009) discusses one approach for modeling and analysis of an organization.<br />
<br />
===Operational Capabilities & Operational Services===<br />
As you can see in this figure, operational capabilities provide operational services that are enabled by system capabilities. These system capabilities are inherent in the system that is conceived, developed, created and/or operated by an enterprise. ESE concentrates its efforts on maximizing operational value for various stakeholders, some of whom may be interested in the improvement of some problem situation. <br />
<br />
ESE, however, addresses more than just solving problems; it also deals with the exploitation of [[Opportunity (glossary)|opportunities]] for better ways to achieve the enterprise goals. This opportunity might involve lowering of operating [[Cost (glossary)|costs]], increasing market share, decreasing deployment risk, reducing time to market, and any number of other enterprise goals. The importance of addressing opportunity potentials should not be underestimated in the execution of ESE practices. <br />
<br />
This article focuses on the ''operational capabilities'' of an enterprise and the contribution of these capabilities to ''operational value'' (as perceived by the stakeholders). Notice that the organization or enterprise can deal with either the system as a whole or with only one (or a few) of its elements. These elements are not necessarily hard items, like hardware and [[Software (glossary)|software]], but can also include “soft” items, like people, [[Process (glossary) |processes]], principles, policies, practices, organizations, doctrine, theories, beliefs, and so on.<br />
<br />
===Services vs. Products vs. Enterprises===<br />
A [[Service System (glossary)|service system]] is a collection of items (or entities) that perform the operations, administration, management and provisioning (OAM&P) of resources that together provide the opportunities to co-create [[value (glossary)]] by both the service provider and the service consumer.<br />
<br />
A collection of services is not necessarily a service system. In fact, this collection of services is often merely a product system that is one of the resources being OAM&P'ed by the service system. A product system can be composed of hardware, software, personnel (see note 1), facilities, data, materials, techniques, and even services. Each of these product [[System Element (glossary)|system elements]] can be "engineered."<br />
<br />
:<I>Note 1. Even personnel are engineered in the sense that their roles and responsibilities are specified precisely and trade-offs are made about which functions are performed by these people versus by hardware or software. People are "produced" in the sense that untrained people are trained to perform their allocated system functions, unknowledgeable people are educated to find or create the information they need to do their assigned task, and uninformed people are taught how to get access to the data they need, and how to extract relevant information from that data.</I><br />
<br />
It is important to understand the difference between the services "enabled" by a service system versus the services that are the elements of a service system entity. See the [[Service Systems Engineering]] article for more information about services and how they are engineered.<br />
<br />
Likewise, a collection of services is not necessarily an enterprise system. An enterprise may be composed of service systems, along with product systems, as well as policies, procedures, properties, knowledge, financial capital, intellectual capital, and so on. An enterprise might even contain sub-enterprises. Enterprise SE must do the engineering not only across the enterprise itself, but may also get involved in the engineering of the service systems and products systems that the enterprise depends on in order to achieve its goals.<br />
<br />
===Enterprise Components===<br />
The above depictions of enterprise-related things do not show the [[Component (glossary)|components]] of an enterprise. The components of an enterprise when it is viewed as a “system” are different than the components of a product or service system (which is the focus of most literature on systems engineering). The figure below shows the typical kinds of components (shown here as “domains”) in an enterprise (Troux 2010) that could be utilized in achieving the desired enterprise <I>operational capability</I> as shown in Figure 1. It is this operational capability that drives ultimate value for the enterprise’s [[Customer (glossary)|customers]] and other stakeholders. Further discussion on enterprise components is provided by Reese (2010) and Lawson (2010, chap. 8).<br />
<br />
[[File:ESE-F03.png|thumb|550px|center|'''Figure 2. Categories of Enterprise Components (Troux Technologies, 2010).''' Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.]]<br />
<br />
The application/software and infrastructure/hardware domains (shown above) are likely the most familiar to systems engineers. The application/software domain contains things like the deployed software itself plus applications, modules, servers, patches, functions, and messages. The infrastructure/hardware domain contains things like the hardware itself plus networks and different kinds of hardware like computing hardware, cabinets, and network devices. There might different subtypes of computing hardware like computers, servers, desktops, laptops, and mainframes. <br />
<br />
This particular "semantic model" had its origins in the area of information technology (IT) management but has been successfully expanded beyond the IT domain (Martin 2003 and 2005). You can see from this elaboration of these domains that an enterprise architecture "schema" can be quite extensive in the kinds of things it can model. The less technical domains would be things like policy, market, strategy, transition, financial, knowledge and skill, and analysis. In a typical enterprise architecture schema like this there could be over a hundred types of modeling objects grouped into these domains. <br />
<br />
Various tools used in modeling the enterprise are described at http://www.enterprise-architecture.info/EA_Tools.htm (IEAD 2011). The TOGAF metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html) used in The Open Group Architecture Framework (TOGAF) is another useful depiction of the various modeling entities involved in modeling the enterprise (OMG 2009).<br />
<br />
==Scope of Enterprise SE==<br />
Computer and communications technologies make it easier to integrate activities across the enterprise, but this does not necessarily make the enterprise more effective and efficient. To enable this to happen, one needs to look at the whole enterprise as a system, rather than as a collection of functions connected solely by information systems and shared facilities.<br />
<br />
===Essential Challenges===<br />
Enterprises face strategic challenges that are essential to address in order to ensure that the enterprise will succeed (Rouse 2009):<br />
*'''Growth:''' Increasing impact, perhaps in saturated/declining “markets”,<br />
*'''Value:''' Enhancing relationships of processes to benefits and costs,<br />
*'''Focus:''' Pursuing opportunities and avoiding diversions,<br />
*'''Change:''' Competing creatively while maintaining continuity,<br />
*'''Future:''' Investing in inherently unpredictable outcomes,<br />
*'''Knowledge:''' Transforming information to insights to programs, and<br />
*'''Time:''' Carefully allocating the organization’s scarcest resource.<br />
<br />
To address these challenges, one recognizes that the central source of value in the enterprise is in its people. “Understanding and supporting the interests of an enterprise’s diverse stakeholders — and finding the ‘sweet spot’ among the many competing interests — is a central aspect of discerning the work of the enterprise as a system and creating mechanisms to enhance this work” (Rouse 2009).<br />
<br />
===Enterprise Transformation===<br />
Enterprises are constantly transforming, whether at the individual level (wherein individuals alter their work practices) or at the enterprise level (large-scale planned strategic changes) (Srinivasan 2010). These changes are a response on the part of the enterprise to evolving opportunities and emerging [[Threat (glossary)|threats]]. It is not merely a matter of doing work better, but doing different work, which is often a more important result. Value is created through the execution of business processes. However, not all processes necessarily contribute to overall value (Rouse 2005, 138-150). It is important to focus on process and how they contribute to the overall value stream. <br />
<br />
After gaining a good understanding of business processes, the next main concern is how best to deploy and manage the enterprise’s human, financial, and physical assets. The key challenge in transforming an enterprise is, in the midst of all this change, continuing to ''satisfice'' key stakeholders (see note 2).<br />
<br />
:<I>Note 2. “Satisfice” means to decide on and pursue a course of action satisfying the minimum requirements to achieve a goal. For the enterprise as a whole, it is often impossible to completely satisfy all stakeholders given their competing and conflicting concerns and interests. Therefore, the concept of “satisficing” is a very important element in the execution of ESE practices. It has less stringent criteria than the concept of "satisfaction," which is commonly used in product/service systems engineering.</I><br />
<br />
Systems engineers have to respond to an increased recognition of the ‘connectedness’ of products and systems, brought about by a number of trends, for example: the capability of (mainly digital) technology, working across multiple systems, to transform businesses and operational systems; the need to create systems in families to increase product diversity and reuse technology, in order to reduce development and operating costs; and the need to build systems which can be brought together flexibly in operations, even if such co-operation was not foreseen at the time of development.<br />
<br />
There has also been an increase in collaborative systems development activities, often spanning national boundaries. This has proceeded alongside a growth in the development of what might be called ''meta-systems,'' that is systems comprising parts which would previously have been considered as complex in their own right a generation ago, now conceived of and developed as a whole, and thus requiring fresh approaches, of the adaption of old ones.<br />
<br />
Tackling these issues requires an approach that transcends the technical and process domain. ESE needs to address integration at the organizational and value chain level.<br />
<br />
===Transformation Context===<br />
Enterprise transformation occurs in the external context of the economy and markets as shown in the figure below (Rouse 2009). The “market” for the enterprise can be thought of as the context in which the enterprise operates. Of course, in the public sector, the enterprise’s “market” is commonly known as its “constituency.” <br />
<br />
[[File:ESE-F04.png|thumb|center|500px|'''Figure 3. Context for Enterprise Transformation (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
The term “intraprise” is used here to denote the many systems internal to the enterprise. This includes "information systems such as... ERP [enterprise resource planning] systems, as well as social and cultural systems. More specifically, work assignments are pursued via work processes and yield work products, incurring costs" (Rouse 2009). The social and cultural aspects of an enterprise are addressed further in the article called [[Enabling Businesses and Enterprises]].<br />
<br />
==Modeling the Enterprise==<br />
[[Model (glossary)|Models]] of the enterprise can serve as the basis for understanding the enterprise in its context of markets and economies. The figure below shows the various drivers (or inputs) of an enterprise and its potential outcomes (or outputs) (Rouse 2009). [[Enterprise Architecture (glossary)|Enterprise architecture]] can be a key enabler for modeling and can serve as a basis for transformation (Vernadat 1996; Bernus, Laszlo, and Schmidt 2003; Nightingale and Rhodes 2004). Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010) (See also [[Representing Systems with Models]]). For a good review of the subject see Lillehagen (2008).<br />
<br />
[[File:ESE-F05.png|thumb|center|500px|center|'''Figure 4. Drivers and Outcomes for the Enterprise (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
==In Pursuit of Value==<br />
Based on his theory of enterprise transformation, Rouse (2005, 279-295) has identified four alternative perspectives that tend to drive the need for transformation:<br />
#'''Value Opportunities:''' The lure of greater success via market and/or technology opportunities prompts transformation initiatives.<br />
#'''Value Threats:''' The danger of anticipated [[Failure (glossary)|failure]] due to market and/or technology threats prompts transformation initiatives.<br />
#'''Value Competition:''' Other players’ transformation initiatives prompt recognition that transformation is necessary to continued success.<br />
#'''Value Crises:''' Steadily declining market performance, cash flow problems, etc., prompt recognition that transformation is necessary for the enterprise to survive.<br />
<br />
Work processes can be enhanced, streamlined, eliminated, and invented to help in the pursuit of enhanced value. These process changes should be aligned with enterprise strategy to maximize value produced by the enterprise (Hammer and Champy 1993). As shown below, there are many entities involved in helping the enterprise create value for society, participating organizations, and other stakeholders.<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 5. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hammer, M., and J. Champy. 1993. ''Reengineering the Corporation: A Manifesto for Business Revolution.'' New York, NY: Harper Business, HarperCollins Publishers. <br />
<br />
IEAD. 2011. "Enterprise Architecture Tools." Institute for Enterprise Architecture Developments. Accessed September 12, 2012. Available at: http://www.enterprise-architecture.info/EA_Tools.htm.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Lillehagen, F., and J. Krogstie. 2008. "State of the Art of Enterprise Modelling." Chapter 4 in ''Active Knowledge Management of Enterprises.'' New York, NY: Springer.<br />
<br />
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. <br />
<br />
Martin, J.N., 2003. "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. <br />
<br />
Miller, J., and S. Page. 2007. ''Complex Adaptive Systems: An Introduction to Computational Models of Social Life.'' Princeton, NJ, USA: Princeton University Press.<br />
<br />
OMG. 2009. "The Open Group Architecture Framework," version 9. The Open Architecture Group. Accessed on September 2, 2011. Available at: http://www.opengroup.org/togaf. <br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2):138-50. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
White, B.E. 2009. "Complex Adaptive Systems Engineering (CASE)." Presented at IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''[[Design of Enterprise Systems: Theory, Architecture, and Methods]].'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse (eds.), ''Handbook of systems engineering and management,'' 2nd ed. New York, NY: Wiley and Sons, Inc.<br />
<br />
Srinivasan, J. 2010. "[[Towards a Theory Sensitive Approach to Planning Enterprise Transformation]]." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
White, B.E. 2009. "[[Complex Adaptive Systems Engineering (CASE)]]." IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Additional References===<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"Systems of systems engineering: Principles and applications."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105.<br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering 38'' (1) (Spring 2008): 17-25. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In M.A. Somerville and D. Rappaport (eds.), ''Transdiciplinarity: Recreating Integrated Knowledge."' Oxford, UK: EOLSS Publishers: 158-169. <br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications,'' Revised ed. New York, NY: Braziller.<br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''"General Principles of Systems Design."'' New York, NY: Dorset House Publishing Company.<br />
<br />
White, B.E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[The Enterprise as a System|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Background&diff=46731
Enterprise Systems Engineering Background
2012-11-28T15:00:40Z
<p>Janthony: /* Enterprise Components */</p>
<hr />
<div>This article provides a common context for the succeeding topics in the knowledge area. <br />
<br />
==Capabilities in the Enterprise==<br />
The enterprise acquires or develops systems or individual elements of a system. The enterprise can also create, supply, use, and operate systems or system elements. Since there could possibly be several organizations involved in this enterprise venture, each organization could be responsible for particular systems or perhaps for certain kinds of elements. Each organization brings their own organizational capability with them and the unique combination of these organizations leads to the overall operational capability of the whole enterprise. These concepts are illustrated below.<br />
<br />
[[File:ESE-F02.png|thumb|650px|center|'''Figure 1. Individual Competence Leads to Organizational, System & Operational Capability.''' (SEBoK Original)]]<br />
<br />
Organizational capabilities are addressed in the article on [[Systems Engineering Organizational Strategy]], and individual competencies are addressed in the article on [[Enabling Individuals]] as they relate to the principles, theories, and practices of organizational [[Behavior (glossary)|behavior]]. <br />
<br />
===Organizational Capabilities and Competencies===<br />
The word "[[capability (glossary)|capability]]" is used in [[Systems Engineering (glossary)|systems engineering]] (SE) in the sense of “the ability to do something useful under a particular set of conditions.” This article discusses three different kinds of capabilities: [[Organizational Capability (glossary)|organizational capability]], [[System Capability (glossary)|system capability]], and [[Operational Capability (glossary)|operational capability]]. It uses the word “competence” to refer to the ability of people relative to the SE task. [[Competency (glossary)|Individual competence]], (sometimes called "competency"), contributes to, but is not the sole determinant of, organizational capability. This competence is translated to organizational capabilities through the work practices that are adopted by the organizations. New systems (with new or enhanced system capabilities) are developed to enhance [[Enterprise (glossary)|enterprise]] operational capability in response to [[Stakeholder (glossary)|stakeholder’s]] concerns about a problem situation. <br />
<br />
Enterprise stakeholders are the ultimate arbiters of [[value (glossary)]] for the system to be delivered. Organizational, system, and operational capabilities cannot be designed, improved, and implemented independently. The key to understanding the dependencies between capabilities is through [[Architecture (glossary)|architecture]] modeling and analysis as part of the activities described in the article called [[Enterprise Capability Management]]. “Capability engineering” is an emerging discipline that could enhance the [[Effectiveness (glossary)|effectiveness]] of [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] (ESE), which is further discussed in the article on [[Systems of Systems (SoS)]].<br />
<br />
===Organizational Design===<br />
The competencies of individuals are important to the overall organizational capability as discussed in the article on [[Enabling Individuals]]. The organizational capability is also a function of how the people, [[Team (glossary)|teams]], [[Project (glossary)|projects]], and [[Business (glossary)|businesses]] are organized. The organizational [[Design (glossary)|design]] should specify the roles, authorities, responsibilities, and accountabilities (RARA) of the organizational units to ensure the most efficient and effective operations. Effectiveness of enterprise operations is certainly driven by management principles, concepts, and approaches, but it is also largely driven by its leadership principles, concepts, and approaches. These factors are discussed in the article on [[Systems Engineering Organizational Strategy]] that discusses how to organize for effective performance of SE.<br />
<br />
Organizational [[Structure (glossary)|structure]] is tightly tied to creating value for the enterprise’s various stakeholders. Since the enterprise is made up of various elements including people, processes, technologies, and assets, the organizational structure of the people and the allocation of responsibilities for executing portions of the value stream is a “design decision” for the enterprise and hence is a key element of properly performing ESE. Organizational design is increasingly influenced by the portfolio of products and services and the degree of coupling between them. This organizational design will be based on organizational design patterns and their tradeoffs, as discussed in the article on [[Systems Engineering Organizational Strategy]]. Browning (2009) discusses one approach for modeling and analysis of an organization.<br />
<br />
===Operational Capabilities & Operational Services===<br />
As you can see in this figure, operational capabilities provide operational services that are enabled by system capabilities. These system capabilities are inherent in the system that is conceived, developed, created and/or operated by an enterprise. ESE concentrates its efforts on maximizing operational value for various stakeholders, some of whom may be interested in the improvement of some problem situation. <br />
<br />
ESE, however, addresses more than just solving problems; it also deals with the exploitation of [[Opportunity (glossary)|opportunities]] for better ways to achieve the enterprise goals. This opportunity might involve lowering of operating [[Cost (glossary)|costs]], increasing market share, decreasing deployment risk, reducing time to market, and any number of other enterprise goals. The importance of addressing opportunity potentials should not be underestimated in the execution of ESE practices. <br />
<br />
This article focuses on the ''operational capabilities'' of an enterprise and the contribution of these capabilities to ''operational value'' (as perceived by the stakeholders). Notice that the organization or enterprise can deal with either the system as a whole or with only one (or a few) of its elements. These elements are not necessarily hard items, like hardware and [[Software (glossary)|software]], but can also include “soft” items, like people, [[Process (glossary) |processes]], principles, policies, practices, organizations, doctrine, theories, beliefs, and so on.<br />
<br />
===Services vs. Products vs. Enterprises===<br />
A [[Service System (glossary)|service system]] is a collection of items (or entities) that perform the operations, administration, management and provisioning (OAM&P) of resources that together provide the opportunities to co-create [[value (glossary)]] by both the service provider and the service consumer.<br />
<br />
A collection of services is not necessarily a service system. In fact, this collection of services is often merely a product system that is one of the resources being OAM&P'ed by the service system. A product system can be composed of hardware, software, personnel (see note 1), facilities, data, materials, techniques, and even services. Each of these product [[System Element (glossary)|system elements]] can be "engineered."<br />
<br />
:<I>Note 1. Even personnel are engineered in the sense that their roles and responsibilities are specified precisely and trade-offs are made about which functions are performed by these people versus by hardware or software. People are "produced" in the sense that untrained people are trained to perform their allocated system functions, unknowledgeable people are educated to find or create the information they need to do their assigned task, and uninformed people are taught how to get access to the data they need, and how to extract relevant information from that data.</I><br />
<br />
It is important to understand the difference between the services "enabled" by a service system versus the services that are the elements of a service system entity. See the [[Service Systems Engineering]] article for more information about services and how they are engineered.<br />
<br />
Likewise, a collection of services is not necessarily an enterprise system. An enterprise may be composed of service systems, along with product systems, as well as policies, procedures, properties, knowledge, financial capital, intellectual capital, and so on. An enterprise might even contain sub-enterprises. Enterprise SE must do the engineering not only across the enterprise itself, but may also get involved in the engineering of the service systems and products systems that the enterprise depends on in order to achieve its goals.<br />
<br />
===Enterprise Components===<br />
The above depictions of enterprise-related things do not show the [[Component (glossary)|components]] of an enterprise. The components of an enterprise when it is viewed as a “system” are different than the components of a product or service system (which is the focus of most literature on systems engineering). The figure below shows the typical kinds of components (shown here as “domains”) in an enterprise (Troux 2010) that could be utilized in achieving the desired enterprise <I>operational capability</I> as shown in Figure 1. It is this operational capability that drives ultimate value for the enterprise’s [[Customer (glossary)|customers]] and other stakeholders. Further discussion on enterprise components is provided by Reese (2010) and Lawson (2010, chap. 8).<br />
<br />
[[File:ESE-F03.png|thumb|550px|center|'''Figure 2. Categories of Enterprise Components (Troux Technologies, 2010).''' Reprinted with permission of Copyright © 2010 Troux Technologies. All other rights are reserved by the copyright owner.]]<br />
<br />
The application/software and infrastructure/hardware domains (shown above) are likely the most familiar to systems engineers. The application/software domain contains things like the deployed software itself plus applications, modules, servers, patches, functions, and messages. The infrastructure/hardware domain contains things like the hardware itself plus networks and different kinds of hardware like computing hardware, cabinets, and network devices. There might different subtypes of computing hardware like computers, servers, desktops, laptops, and mainframes. <br />
<br />
This particular "semantic model" had its origins in the area of information technology (IT) management but has been successfully expanded beyond the IT domain (Martin 2003 and 2005). You can see from this elaboration of these domains that an enterprise architecture "schema" can be quite extensive in the kinds of things it can model. The less technical domains would be things like policy, market, strategy, transition, financial, knowledge and skill, and analysis. In a typical enterprise architecture schema like this there could be over a hundred types of modeling objects grouped into these domains. <br />
<br />
Various tools used in modeling the enterprise are described at http://www.enterprise-architecture.info/EA_Tools.htm (IEAD 2011). The TOGAF metamodel (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html) used in The Open Group Architecture Framework (TOGAF) is another useful depiction of the various modeling entities involved in modeling the enterprise (OMG 2009).<br />
<br />
==Scope of Enterprise SE==<br />
Computer and communications technologies make it easier to integrate activities across the enterprise, but this does not necessarily make the enterprise more effective and efficient. To enable this to happen, one needs to look at the whole enterprise as a system, rather than as a collection of functions connected solely by information systems and shared facilities.<br />
<br />
===Essential Challenges===<br />
Enterprises face strategic challenges that are essential to address in order to ensure that the enterprise will succeed (Rouse 2009):<br />
*'''Growth:''' Increasing impact, perhaps in saturated/declining “markets”,<br />
*'''Value:''' Enhancing relationships of processes to benefits and costs,<br />
*'''Focus:''' Pursuing opportunities and avoiding diversions,<br />
*'''Change:''' Competing creatively while maintaining continuity,<br />
*'''Future:''' Investing in inherently unpredictable outcomes,<br />
*'''Knowledge:''' Transforming information to insights to programs, and<br />
*'''Time:''' Carefully allocating the organization’s scarcest resource.<br />
<br />
To address these challenges, one recognizes that the central source of value in the enterprise is in its people. “Understanding and supporting the interests of an enterprise’s diverse stakeholders — and finding the ‘sweet spot’ among the many competing interests — is a central aspect of discerning the work of the enterprise as a system and creating mechanisms to enhance this work” (Rouse 2009).<br />
<br />
===Enterprise Transformation===<br />
Enterprises are constantly transforming, whether at the individual level (wherein individuals alter their work practices) or at the enterprise level (large-scale planned strategic changes) (Srinivasan 2010). These changes are a response on the part of the enterprise to evolving opportunities and emerging [[Threat (glossary)|threats]]. It is not merely a matter of doing work better, but doing different work, which is often a more important result. Value is created through the execution of business processes. However, not all processes necessarily contribute to overall value (Rouse 2005, 138-150). It is important to focus on process and how they contribute to the overall value stream. <br />
<br />
After gaining a good understanding of business processes, the next main concern is how best to deploy and manage the enterprise’s human, financial, and physical assets. The key challenge in transforming an enterprise is, in the midst of all this change, continuing to ''satisfice'' key stakeholders (see note 2).<br />
<br />
:<I>Note 2. “Satisfice” means to decide on and pursue a course of action satisfying the minimum requirements to achieve a goal. For the enterprise as a whole, it is often impossible to completely satisfy all stakeholders given their competing and conflicting concerns and interests. Therefore, the concept of “satisficing” is a very important element in the execution of ESE practices. It has less stringent criteria than the concept of "satisfaction," which is commonly used in product/service systems engineering.</I><br />
<br />
Systems engineers have to respond to an increased recognition of the ‘connectedness’ of products and systems, brought about by a number of trends, for example: the capability of (mainly digital) technology, working across multiple systems, to transform businesses and operational systems; the need to create systems in families to increase product diversity and reuse technology, in order to reduce development and operating costs; and the need to build systems which can be brought together flexibly in operations, even if such co-operation was not foreseen at the time of development.<br />
<br />
There has also been an increase in collaborative systems development activities, often spanning national boundaries. This has proceeded alongside a growth in the development of what might be called ''meta-systems,'' that is systems comprising parts which would previously have been considered as complex in their own right a generation ago, now conceived of and developed as a whole, and thus requiring fresh approaches, of the adaption of old ones.<br />
<br />
Tackling these issues requires an approach that transcends the technical and process domain. ESE needs to address integration at the organizational and value chain level.<br />
<br />
===Transformation Context===<br />
Enterprise transformation occurs in the external context of the economy and markets as shown in the figure below (Rouse 2009). The “market” for the enterprise can be thought of as the context in which the enterprise operates. Of course, in the public sector, the enterprise’s “market” is commonly known as its “constituency.” <br />
<br />
[[File:ESE-F04.png|thumb|center|500px|'''Figure 3. Context for Enterprise Transformation (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
The term “intraprise” is used here to denote the many systems internal to the enterprise. This includes "information systems such as... ERP [enterprise resource planning] systems, as well as social and cultural systems. More specifically, work assignments are pursued via work processes and yield work products, incurring costs" (Rouse 2009). The social and cultural aspects of an enterprise are addressed further in the article called [[Enabling Businesses and Enterprises]].<br />
<br />
==Modeling the Enterprise==<br />
[[Model (glossary)|Models]] of the enterprise can serve as the basis for understanding the enterprise in its context of markets and economies. The figure below shows the various drivers (or inputs) of an enterprise and its potential outcomes (or outputs) (Rouse 2009). [[Enterprise Architecture (glossary)|Enterprise architecture]] can be a key enabler for modeling and can serve as a basis for transformation (Vernadat 1996; Bernus, Laszlo, and Schmidt 2003; Nightingale and Rhodes 2004). Enterprise architecture can be used to provide a model to understand how the parts of the enterprise fit together (or do not) (Giachetti 2010) (See also [[Representing Systems with Models]]). For a good review of the subject see Lillehagen (2008).<br />
<br />
[[File:ESE-F05.png|thumb|center|500px|center|'''Figure 4. Drivers and Outcomes for the Enterprise (Rouse 2009).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
==In Pursuit of Value==<br />
Based on his theory of enterprise transformation, Rouse (2005, 279-295) has identified four alternative perspectives that tend to drive the need for transformation:<br />
#'''Value Opportunities:''' The lure of greater success via market and/or technology opportunities prompts transformation initiatives.<br />
#'''Value Threats:''' The danger of anticipated [[Failure (glossary)|failure]] due to market and/or technology threats prompts transformation initiatives.<br />
#'''Value Competition:''' Other players’ transformation initiatives prompt recognition that transformation is necessary to continued success.<br />
#'''Value Crises:''' Steadily declining market performance, cash flow problems, etc., prompt recognition that transformation is necessary for the enterprise to survive.<br />
<br />
Work processes can be enhanced, streamlined, eliminated, and invented to help in the pursuit of enhanced value. These process changes should be aligned with enterprise strategy to maximize value produced by the enterprise (Hammer and Champy 1993). As shown below, there are many entities involved in helping the enterprise create value for society, participating organizations, and other stakeholders.<br />
<br />
[[File:ESE-F01.png|thumb|center|650px|'''Figure 5. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Hammer, M., and J. Champy. 1993. ''Reengineering the Corporation: A Manifesto for Business Revolution.'' New York, NY: Harper Business, HarperCollins Publishers. <br />
<br />
IEAD. 2011. "Enterprise Architecture Tools." Institute for Enterprise Architecture Developments. Accessed September 12, 2012. Available at: http://www.enterprise-architecture.info/EA_Tools.htm.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' Kings College, UK: College Publications.<br />
<br />
Lillehagen, F., and J. Krogstie. 2008. "State of the Art of Enterprise Modelling." Chapter 4 in ''Active Knowledge Management of Enterprises.'' New York, NY: Springer.<br />
<br />
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. <br />
<br />
Martin, J.N., 2003. "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. <br />
<br />
Miller, J., and S. Page. 2007. ''Complex Adaptive Systems: An Introduction to Computational Models of Social Life.'' Princeton, NJ, USA: Princeton University Press. <br />
<br />
Reese, R.J. 2010. ''Troux Enterprise Architecture Solutions.'' Birmingham, UK: Packt Publishing Ltd.<br />
<br />
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation." ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2):138-50. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In eds. A. P. Sage, W. B. Rouse. 2nd ed. ''Handbook of systems engineering and management.'' New York, NY: Wiley and Sons, Inc. <br />
<br />
Srinivasan, J. 2010. "Towards a Theory Sensitive Approach to Planning Enterprise Transformation." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
TOGAF. 2009. "The Open Group Architecture Framework," version 9. The Open Architecture Group. Accessed on September 2, 2011. Available at: http://www.opengroup.org/togaf.<br />
<br />
Troux. 2010. ''Metamodeling and modeling with Troux Semantics.'' Austin, TX, USA: Troux Technologies. Version 9, July 2010.<br />
<br />
White, B.E. 2009. "Complex Adaptive Systems Engineering (CASE)." Presented at IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Primary References===<br />
Giachetti, R.E. 2010. ''[[Design of Enterprise Systems: Theory, Architecture, and Methods]].'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group.<br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A. P. Sage, W. B. Rouse (eds.), ''Handbook of systems engineering and management,'' 2nd ed. New York, NY: Wiley and Sons, Inc.<br />
<br />
Srinivasan, J. 2010. "[[Towards a Theory Sensitive Approach to Planning Enterprise Transformation]]." Paper presented at 5th European Institute for Advanced Studies in Management (EIASM) Workshop on Organizational Change and Development, September 23-24, 2010, Vienna, Austria. <br />
<br />
White, B.E. 2009. "[[Complex Adaptive Systems Engineering (CASE)]]." IEEE Systems Conference 2009, Vancouver, Canada, 23-26 March 2009.<br />
<br />
===Additional References===<br />
McCarter, B.G. and B.E. White. 2009. "Emergence of SoS, sociocognitive aspects." In Jamshidi, M. ed. ''"Systems of systems engineering: Principles and applications."'' Boca Raton, FL, USA: CRC Press, Taylor & Francis Group: 71-105.<br />
<br />
Rouse, W.B. 2008. "Health Care as a Complex Adaptive System: Implications for design and management." ''The Bridge, National Academy of Engineering 38'' (1) (Spring 2008): 17-25. <br />
<br />
Sage, A.P. 2000. "Transdisciplinarity Perspectives in Systems Engineering and Management." In M.A. Somerville and D. Rappaport (eds.), ''Transdiciplinarity: Recreating Integrated Knowledge."' Oxford, UK: EOLSS Publishers: 158-169. <br />
<br />
von Bertalanffy, L. 1968. ''General System Theory: Foundations, Development, Applications,'' Revised ed. New York, NY: Braziller.<br />
<br />
Weinberg, G. and D. Weinberg. 1988. ''"General Principles of Systems Design."'' New York, NY: Dorset House Publishing Company.<br />
<br />
White, B.E. 2007. "On Interpreting Scale (or View) and Emergence in Complex Systems Engineering." Paper presented at 1st Annual IEEE Systems Conference, 9-12 April, 2007, Honolulu, HI, USA. <br />
<br />
----<br />
<center>[[Enterprise Systems Engineering|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[The Enterprise as a System|Next Article >]]</center><br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46728
Enterprise Systems Engineering
2012-11-28T14:58:40Z
<p>Janthony: /* Enterprise */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
''One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]].'' (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
"Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user." (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed September 12, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46726
Enterprise Systems Engineering
2012-11-28T14:56:32Z
<p>Janthony: /* Extended Enterprise */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 15704 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
''One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]].'' (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
"Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user." (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed September 12, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46724
Enterprise Systems Engineering
2012-11-28T14:55:38Z
<p>Janthony: /* Projects, Programs & Businesses */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 15704 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
''One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]].'' (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
''Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user.'' (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”</BLOCKQUOTE><br />
<br />
<BLOCKQUOTE><br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed September 12, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering&diff=46722
Enterprise Systems Engineering
2012-11-28T14:54:35Z
<p>Janthony: /* Projects, Programs & Businesses */</p>
<hr />
<div>[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering ]] (ESE) is the application of systems engineering principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Enterprise Systems Engineering Background]]<br />
*[[The Enterprise as a System]]<br />
*[[Related Business Activities]]<br />
*[[Enterprise Systems Engineering Key Concepts]]<br />
*[[Enterprise Systems Engineering Process Activities]]<br />
*[[Enterprise Capability Management]]<br />
<br />
==Introduction==<br />
This knowledge area provides an introduction to [[Systems Engineering (glossary)|systems engineering]] (SE) at the [[Enterprise (glossary)|enterprise]] level in contrast to “traditional” SE (TSE) (sometimes called “conventional” or “classical” SE) performed in a development [[Project (glossary)|project]] or to “product” engineering (often called product development in the SE literature). <br />
<br />
The concept of enterprise was instrumental in the great expansion of world trade in the 17th century (see note 1) and again during the Industrial Revolution of the 18th and 19th centuries. The world may be at the cusp of another global revolution enabled by the information age and the technologies and [[Culture (glossary)|cultures]] of the Internet (see note 2). The discipline of SE now has the unique opportunity of providing the tools and methods for the next round of enterprise transformations. <br />
<br />
:<I>Note 1. “The Dutch East India Company… was a chartered company established in 1602, when the States-General of the Netherlands granted it a 21-year monopoly to carry out colonial activities in Asia. It was the <u>first multinational corporation</u> in the world and the first company to issue stock. It was also arguably the '''world's first mega-corporation''', possessing quasi-governmental powers, including the ability to wage war, negotiate treaties, coin money, and establish colonies.” (emphasis added, National Library of the Netherlands 2010)<br />
<br />
:Note 2. This new revolution is being enabled by cheap and easily usable technology, global availability of information and knowledge, and increased mobility and adaptability of human capital. The enterprise level of analysis is only feasible now because [[Organization (glossary)|organizations]] can work together to form enterprises in a much more fluid manner.<br />
</I><br />
<br />
ESE is an emerging discipline that focuses on frameworks, tools, and problem-solving approaches for dealing with the inherent [[Complexity (glossary)|complexities]] of the enterprise. Furthermore, ESE addresses more than just solving problems; it also deals with the exploitation of opportunities for better ways to achieve the enterprise goals. A good overall description of ESE is provided by in the book by Rebovich and White (2011).<br />
<br />
==Key Terms==<br />
===Enterprise===<br />
An enterprise consists of a purposeful combination (e.g., a [[Network (glossary)|network]]) of interdependent resources (e.g., people, [[Process (glossary)|processes]], organizations, supporting technologies, and funding) that interact with <br />
<br />
* each other to coordinate functions, share information, allocate funding, create workflows, and make decisions, etc.; and<br />
* their [[Environment (glossary)|environment(s)]] to achieve [[Business (glossary)|business]] and [[Operational (glossary)|operational]] goals through a [[Complex (glossary)|complex]] web of interactions distributed across geography and time (Rebovich and White 2011, 4-35).<br />
<br />
The term enterprise has been defined as follows:<br />
<br />
<blockquote>(1) ''One or more [[Organization (glossary)|organizations]] sharing a definite [[Mission (glossary)|mission]], goals, and objectives to offer an [[Output (glossary)|output]] such as a [[Product (glossary)|product]] or [[Service (glossary)|service]].'' (ISO 15704 2000);</blockquote><br />
<br />
<blockquote>(2) ''An organization (or cross organizational entity) supporting a defined [[Business (glossary)|business]] scope and mission that includes interdependent resources (people, organizations and technologies) that must coordinate their [[Function (glossary)|functions]] and share information in support of a common mission (or set of related missions).'' (CIO Council 1999);</blockquote><br />
<br />
<blockquote>(3) ''The term enterprise can be defined in one of two ways. The first is when the entity being considered is tightly bounded and directed by a single executive function. The second is when organizational [[Boundary (glossary)|boundaries]] are less well defined and where there may be multiple owners in terms of direction of the resources being employed. The common factor is that both entities exist to achieve specified outcomes.'' (MOD 2004); and </blockquote><br />
<br />
<blockquote>(4) ''A complex, (adaptive) socio-technical system that comprises interdependent resources of people, processes, information, and technology that must interact with each other and their environment in support of a common mission. '' (Giachetti 2010) </blockquote><br />
<br />
An enterprise must do two things: (1) develop things within the enterprise to serve as either external offerings or as internal mechanisms to enable achievement of enterprise operations, and (2) transform the enterprise itself so that it can most effectively and efficiently perform its operations and survive in its competitive and constrained environment.<br />
<br />
===Enterprise vs Organization===<br />
It is worth noting that an enterprise is not equivalent to an "organization” according to the definition above. This is a frequent misuse of the term enterprise. The figure below shows that an enterprise includes not only the organizations that participate in it, but also people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, intellectual property, and so on. <br />
<br />
Some enterprises are organizations, but not all enterprises are organizations. Likewise, not all organizations are enterprises. Some enterprises have no readily identifiable "organizations" in them. Some enterprises are self-organizing (i.e., not organized by mandate) in that the sentient beings in the enterprise will find for themselves some way in which they can interact to produce greater results than can be done by the individuals alone. Self-organizing enterprises are often more [[Flexibility (glossary)|flexible]] and [[Agile (glossary)|agile]] than if they were organized from above (Dyer and Ericksen 2009; Stacey 2006).<br />
<br />
<blockquote><br />
''One type of enterprise [[Architecture (glossary)|architecture]] that supports [[Agility (glossary)|agility]] is a non-hierarchical organization without a single point of [[Control (glossary)|control]]. Individuals function autonomously, constantly interacting with each other to define the work that needs to be done. Roles and responsibilities are not predetermined but rather [[Emergence (glossary)|emerge]] from individuals’ self-organizing activities and are constantly in flux. Similarly, projects are generated everywhere in the enterprise, sometimes even from outside affiliates. Key decisions are made collaboratively, on the spot, and on the fly. Because of this, knowledge, power, and intelligence are spread through the enterprise, making it uniquely capable of quickly recovering and adapting to the loss of any key enterprise [[Component (glossary)|component]].'' (http://en.wikipedia.org/wiki/Business_agility)<br />
</blockquote><br />
<br />
In spite of this lack of "organization" in some enterprises, SE can still contribute much in the engineering of the enterprise, as described in the articles below. However, SE must be prepared to apply some non-traditional approaches in doing so. Hence the need for embracing the new discipline called enterprise systems engineering (ESE).<br />
<br />
Giachetti (2010) distinguishes between enterprise and organization by saying that an organization is a view of the enterprise. The organization view defines the structure and relationships of the organizational units, people, and other actors in an enterprise. Using this definition, we would say that all enterprises have some type of organization, whether formal, informal, hierarchical or self-organizing network.<br />
<br />
===Extended Enterprise===<br />
Sometimes it is prudent to consider a broader scope than merely the "boundaries" of the organizations involved in an enterprise. In some cases, it is necessary (and wise) to consider the "extended enterprise" in modeling, assessment, and decision making. This could include upstream suppliers, downstream consumers, and end [[User (glossary)|user]] organizations, and perhaps even "sidestream" partners and key [[Stakeholder (glossary)|stakeholders]]. The [[Extended Enterprise (glossary)|extended enterprise]] can be defined as:<br />
<blockquote><br />
''Wider organization representing all associated entities - [[Customer (glossary)|customers]], employees, suppliers, distributors, etc. - who directly or indirectly, formally or informally, collaborate in the [[Design (glossary)|design]], development, production, and delivery of a product (or [[Service (glossary)|service]]) to the end user.'' (http://www.businessdictionary.com)<br />
</blockquote><br />
<br />
===Enterprise Systems Engineering===<br />
[[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] (ESE), for the purpose of this article, is defined as the application of SE principles, concepts, and methods to the planning, design, improvement, and operation of an enterprise (see note 3). To enable more efficient and effective enterprise transformation, the enterprise needs to be looked at “as a [[System (glossary)|system]],” rather than merely as a collection of functions connected solely by information systems and shared facilities (Rouse 2009). While a systems perspective is required for dealing with the enterprise, this is rarely the task or responsibility of people who call themselves systems engineers.<br />
<br />
:<I>Note 3. This form of systems engineering (i.e., ESE) includes (1) those traditional principles, concepts, and methods that work well in an enterprise environment, plus (2) an evolving set of newer ideas, precepts, and initiatives derived from [[Complexity (glossary)|complexity]] theory and the behavior of complex systems (such as those observed in nature and human languages).</I><br />
<br />
==Creating Value==<br />
The primary purpose of an enterprise is to create value for society, other stakeholders, and for the organizations that participate in that enterprise. This is illustrated in Figure 1 that shows all the key elements that contribute to this value creation process.<br />
<br />
There are three types of organizations of interest: businesses, projects, and [[Team (glossary)|teams]] (see note 4). A typical business participates in multiple enterprises through its [[Portfolio (glossary)|portfolio]] of projects. Large SE projects can be enterprises in their own right, with participation by many different businesses, and may be organized as a number of sub-projects.<br />
<br />
:<I>Note 4. The use of the word “business” is not intended to mean only for-profit commercial ventures. As used here, it also includes government agencies and not-for-profit organizations, as well as commercial ventures. Business is the activity of providing goods and services involving financial, commercial, and industrial aspects.</I><br />
<br />
[[File:ESE-F01.png|thumb|center|600px|'''Figure 1. Organizations Manage Resources to Create Enterprise Value.''' (SEBoK Original)]]<br />
<br />
===Resource Optimization===<br />
A key choice for businesses that conduct SE is to what extent, if at all, they seek to optimize their use of resources (people, knowledge, assets) across teams, projects, and business units. Optimization of resources is not the goal in itself, but rather a means to achieve the goal of maximizing value for the enterprise and its [[stakeholder (glossary)|stakeholders]]. At one extreme, in a product-oriented organization, projects may be responsible for hiring, training, and firing their own staff, as well as managing all assets required for their delivery of products or services. (The term "product-oriented organization" is not meant in the sense of product-oriented SE, but rather in the sense of this being one of the basic constructs available when formulating organizational strategy.)<br />
<br />
At the other extreme, in a functional organization, the projects delegate almost all their work to functional groups. In between these two extremes is a matrix organization that is used to give functional specialists a “home” between project assignments. A full discussion of organizational approaches and situations along with their applicability in enabling SE for the organization is provided in the article called [[Systems Engineering Organizational Strategy]].<br />
<br />
The optimization debate can be handled as described in the book called "Enterprise Architecture as Strategy" (Ross, Weill, and Robertson 2006). In other words, an enterprise can choose (or not) to unify its operations and can choose (or not) to unify its information base. There are different strategies the enterprise might adopt to achieve and sustain value creation (and how ESE helps an enterprise to choose). This is further addressed in the section on Enterprise Architecture Formulation & Assessment in the article called [[Enterprise Capability Management]].<br />
<br />
===Enabling Systems Engineering in the Organization===<br />
SE skills, techniques, and resources are relevant to many enterprise functions, and a well-founded SE [[Capability (glossary)|capability]] can make a substantial contribution at the enterprise level, as well as at the project level. The article called [[ Systems Engineering Organizational Strategy]] discusses enabling SE in the organization, while the article called [[Enabling Businesses and Enterprises]] focuses on the cross-organizational functions at the business and enterprise levels. The [[Competency (glossary)|competence]] of individuals is discussed in the article called [[Enabling Individuals]].<br />
<br />
===Kinds of Knowledge Used by the Enterprise===<br />
Knowledge is a key resource for ESE. There are generally two kinds of knowledge: explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes. Much of the relevant knowledge, however, is “tacit knowledge” that only exists within the heads of people and in the context of relationships that people form with each other (e.g., team, project, and business level knowledge). The ability of an organization to create value is critically dependent on the people it employs, on what they know, how they work together, and how well they are organized and motivated to contribute to the organization’s purpose.<br />
<br />
=== Projects, Programs & Businesses===<br />
The term “[[program (glossary)|program]]” is used in various ways in different domains. In some domains a team can be called a program (e.g., a customer support team is their customer relationship "program"). In others, an entire business is called a program (e.g., a wireless communications business unit program), and in others the whole enterprise is called a program (e.g., the Joint Strike Fighter program and the Apollo Space program). And in many cases, the terms [[project (glossary)|project]] and [[program (glossary)|program]] are used interchangeably with no discernible distinction in their meaning or scope. Typically, but not always, there are program managers who have profit and loss (P&L) responsibility and are the ultimate program decision makers. A program manager may have a portfolio of items ([[service (glossary)|services]], [[product (glossary)|products]], facilities, intellectual property, etc.) that are usually provided, implemented, or acquired through projects.<br />
<br />
The Office of Government Commerce provides a useful distinction between programs and projects:<br />
<BLOCKQUOTE><br />
“The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...”<br />
<br />
<br />
“A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters.” (OGC 2010)<br />
</BLOCKQUOTE><br />
<br />
==Practical Considerations ==<br />
When it comes to performing SE at the enterprise level, there are several good practices to keep in mind (Rebovich and White 2011):<br />
*Set enterprise fitness as the key [[Measure (glossary)|measure]] of system success. Leverage game theory and ecology, along with the practices of satisfying and governing the commons.<br />
*Deal with uncertainty and conflict in the enterprise through adaptation: variety, selection, exploration, and experimentation.<br />
*Leverage the practice of layered [[architecture (glossary)|architectures]] with [[Loose Coupling (glossary)|loose coupler]]s and the theory of order and [[Chaos (glossary)|chaos]] in networks.<br />
<br />
Enterprise [[governance (glossary)|governance]] involves shaping the political, operational, economic, and technical (POET) landscape. One should not try to control the enterprise like one would in a TSE effort at the project level.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
BusinessDictionary.com, s.v. "Extended Enterprise." Accessed September 12, 2012. Available at: http://www.businessdictionary.com/definition/extended-enterprise.html.<br />
<br />
CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
Dyer, L. and J. Ericksen. 2009. "Complexity-based Agile Enterprises: Putting Self-Organizing Emergence to Work." In A. Wilkinson et al (eds.). ''The Sage Handbook of Human Resource Management.'' London, UK: Sage: 436–457.<br />
<br />
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.<br />
<br />
ISO. 2000. ''Industrial Automation Systems -- Requirements for Enterprise-Reference Architectures and Methodologies''. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 15704:2000. <br />
<br />
MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
National Library of the the Netherlands. 2010. "Dossier VOC (1602-1799)." (in Dutch) Accessed September 12, 2012. Available at: http://www.kb.nl/dossiers/voc/voc.html.<br />
<br />
OGC (Office of Government Commerce). 2010. ''Guidelines for Managing Programmes: Understanding programmes and programme management.'' London, UK: The Stationery Office. <br />
<br />
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. <br />
<br />
Ross, J.W., P. Weill, and D. Robertson. 2006, ''Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.'' Boston, MA, USA: Harvard Business Review Press. <br />
<br />
Rouse, W.B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management.'', eds. A. P. Sage, W. B. Rouse. 2nd ed. New York, NY, USA: Wiley and Sons, Inc. <br />
<br />
Stacey, R. 2006. "The Science of Complexity: An Alternative Perspective for Strategic Change Processes." In R. MacIntosh et al (eds.). ''Complexity and Organization: Readings and Conversations.'' London, UK: Routledge: 74–100.<br />
<br />
Wikipedia contributors, "Business agility," ''Wikipedia, The Free Encyclopedia''. Accessed September 12, 2012. Available at: http://en.wikipedia.org/w/index.php?title=Business_agility&oldid=503858042.<br />
<br />
===Primary References===<br />
<br />
Bernus, P., L. Nemes, and G. Schmidt G. (eds). 2003. ''[[Handbook on Enterprise Architecture]].'' Berlin & Heidelberg, Germany: Springer-Verlag.<br />
<br />
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. <br />
<br />
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering, the Journal of the International Council on Systems Engineering (INCOSE).'' 8(2): 138-50. <br />
<br />
Rouse, W.B. 2009. "[[Engineering the Enterprise as a System]]." In A.P. Sage, W.B. Rouse (eds.) ''Handbook of Systems Engineering and Management,'' 2nd ed. New York, NY, USA: Wiley and Sons, Inc.<br />
<br />
Valerdi, R. and D.J. Nightingale. 2011. "[[An Introduction to the Journal of Enterprise Transformation]]," ''Journal of Enterprise Transformation.'' 1(1), 1-6, 2011.<br />
<br />
===Additional References===<br />
Drucker, P.F. 1994. "The theory of business." ''Harvard Business Review'' (September/October 1994): 95-104. <br />
<br />
Fox, M., J.F. Chionglo, and F.G. Fadel. 1993. "A common sense model of the enterprise." Paper presented at the 3rd Industrial Engineering Research Conference, Norcross, GA, USA. <br />
<br />
Gøtze, J. (ed). ''Journal of Enterprise Architecture''. https://www.aogea.org/journal.<br />
<br />
Joannou, P. 2007. "Enterprise, systems, and software—the need for integration." IEEE ''Computer'', May 2007.<br />
<br />
MITRE. 2012. "Enterprise Engineering." In MITRE Corporation, ''Systems Engineering Guide.'' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/. Accessed 8 July 2012.<br />
<br />
Nightingale, D., and J. Srinivasan. 2011. ''Beyond the Lean Revolution: Achieving Successful and Sustainable Enterprise Transformation.'' New York, NY, USA: AMACOM Press. <br />
<br />
Nightingale, D. and R. Valerdi (eds). ''Journal of Enterprise Transformation''. London, UK: Taylor & Francis. http://www.tandf.co.uk/journals/UJET.<br />
<br />
Saenz, O.A. 2005. "Framework for Enterprise Systems Engineering" in ''FIU Electronic Theses and Dissertations''. Miami, FL, USA: Florida International University. Accessed September 12, 2012. Available at: http://digitalcommons.fiu.edu/cgi/viewcontent.cgi?article=1055&context=etd.<br />
<br />
----<br />
<center>[[Service Systems Engineering Stages|< Previous Article]] | [[Applications of Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering Background|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
<br />
[[Category: Part 4]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Janthony