https://sebokwiki.org/w/api.php?action=feedcontributions&user=Jgercken&feedformat=atom
SEBoK - User contributions [en]
2024-03-28T23:47:40Z
User contributions
MediaWiki 1.35.13
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36426
Enterprise Capability Management
2012-07-23T06:46:22Z
<p>Jgercken: /* Needs Identification & 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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)]], 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)]], 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, distributers 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36425
Enterprise Capability Management
2012-07-23T06:45:48Z
<p>Jgercken: /* Enterprise Capability Change Management */</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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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)]], 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)]], 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, distributers 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36424
Enterprise Capability Management
2012-07-23T06:42:20Z
<p>Jgercken: /* Enterprise Portfolio Management */</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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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)]], 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36423
Enterprise Capability Management
2012-07-23T06:41:07Z
<p>Jgercken: /* Enterprise Portfolio Management */</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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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)]], 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; 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36422
Enterprise Capability Management
2012-07-23T06:39:41Z
<p>Jgercken: /* Opportunity Identification & 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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)]], 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; Martin 2003). See (Kaplan 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36421
Enterprise Capability Management
2012-07-23T06:38:37Z
<p>Jgercken: /* 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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 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)]], 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; Martin 2003). See (Kaplan 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36420
Enterprise Capability Management
2012-07-23T06:37:24Z
<p>Jgercken: /* Capability Identification & 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 don’t) (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 2008, 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 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)]], 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; Martin 2003). See (Kaplan 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36419
Enterprise Capability Management
2012-07-23T06:35:02Z
<p>Jgercken: /* Needs Identification & 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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 as to 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 don’t) (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 2008, 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 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)]], 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; Martin 2003). See (Kaplan 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36418
Enterprise Capability Management
2012-07-23T06:31:37Z
<p>Jgercken: /* 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 [[element (glossary)|elements]] identified in the Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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. 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 as to 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 don’t) (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 2008, 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 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)]], 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; Martin 2003). See (Kaplan 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Capability_Management&diff=36417
Enterprise Capability Management
2012-07-23T06:29:03Z
<p>Jgercken: /* 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 to Perform Systems Engineering]]. 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 />
<br />
[[File:ESE-F02.png|thumb|800px|center|Figure 1. Three Kinds of Capability in the Enterprise: Organizational, System & Operational Capability (Figure Developed for BKCASE)]]<br />
<br />
The [[enterprise (glossary)]] has a current and planned ([[baseline (glossary)]]) 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 (glossary)]] 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 [[element (glossary)|elements]] identified in Information Technology Infrastructure Library [[Acronyms|(ITIL)]] best practices for operations management, starting with strategic operation planning (OGC 2009).<br />
<br />
<BLOCKQUOTE><br />
''The Information Technology Infrastructure Library [[Acronyms|(ITIL)]] is a set of concepts and practices for Information Technology Services Management [[Acronyms|(ITSM)]], Information Technology [[Acronyms|(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)]] 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]] [[Acronyms|(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.]]<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. 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 as to 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 don’t) (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 2008, 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 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)]], 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; Martin 2003). See (Kaplan 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)]], 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, distributers 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. These 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. ISBN 978-0-11331-050-0.<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 />
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 />
<center>[[Enterprise Systems Engineering Process Activities|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Systems of Systems (SoS)|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36416
Enterprise Systems Engineering Process Activities
2012-07-23T06:21:04Z
<p>Jgercken: /* Enterprise Architecture and Requirements */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 [[Element (glossary)|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<br />
*enterprise evaluation and assessment<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 transdisciplinary 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 timeframe. 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 (glossary)|business]] capability roadmaps [[Acronyms|(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 to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<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><br />
''must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics.''<br />
(Roberts 2006)</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(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 don’t) (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 [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown 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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<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 [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36415
Enterprise Systems Engineering Process Activities
2012-07-23T06:20:07Z
<p>Jgercken: /* Enterprise Portfolio Considerations */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 [[Element (glossary)|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<br />
*enterprise evaluation and assessment<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 transdisciplinary 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 timeframe. 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 (glossary)|business]] capability roadmaps [[Acronyms|(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 to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<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><br />
''must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics.''<br />
(Roberts 2006)</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(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 don’t) (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 [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown 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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<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 [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 systems engineering to solve some of their agency-level (i.e., enterprise) problems. This has sometimes led to the use of an architecture-based investment process, especially for information technology procurements. This approach imposes a requirement for linking business strategies to the development of EAs. The Federal Enterprise Architecture Framework [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36414
Enterprise Systems Engineering Process Activities
2012-07-23T06:15:38Z
<p>Jgercken: /* Enterprise Management Process Areas */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 [[Element (glossary)|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<br />
*enterprise evaluation and assessment<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 transdisciplinary 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 timeframe. 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 (glossary)|business]] capability roadmaps [[Acronyms|(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 to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<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><br />
''must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics.''<br />
(Roberts 2006)</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(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 don’t) (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 [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown 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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)]] systems to include additional items such as strategic goals and objectives, operators and [[User (glossary)|users]], organizations and other [[Stakeholder (glossary)|stakeholders]], funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36413
Enterprise Systems Engineering Process Activities
2012-07-23T05:56:56Z
<p>Jgercken: /* Value Stream Analysis */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 [[Element (glossary)|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<br />
*Enterprise Evaluation and Assessment<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 transdisciplinary 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)]] to avoid or an [[Opportunity (glossary)]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
One reason that STP and TSP are separate processes is that these 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 timeframe. 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 (glossary)]] capability roadmaps [[Acronyms|(BCRMs)]] are related the [[operational (glossary)]] capabilities of the enterprise as a whole (ref: Business-Capability Mapping: Staying Ahead of the Joneses, http://msdn.microsoft.com/en-us/library/bb402954.aspx). The BCRM development is usually done as part of Enterprise Strategic Planning, which is one level higher than, and a key driver for, the Strategic Technical Planning activity described above.<br />
<br />
In some domains there may be [[competency (glossary)]] roadmaps dealing with the organizational capabilities, with perhaps the desired competency levels of individuals mapped out in terms of the jobs or roles used in the enterprise or perhaps in terms of the knowledge and skills required for certain activities. (For more information on SE competency, see the [[ Enabling Individuals to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<br />
<br />
This process establishes a [[measurement (glossary)]] program as the means for collecting data for use in the evaluation and assessment of the enterprise. These [[Measure (glossary)|measures]] help determine whether the strategy and its implementation are working as intended. Measures are projected into the future as the basis for determining discrepancies between what is observed and what had been predicted to occur. This process helps to identify risks and opportunities, diagnose problems, and prescribe appropriate actions. Sensitivity analysis is performed to determine the degree of [[robustness (glossary)]] and [[agility (glossary)]] of the enterprise.<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><br />
must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics (Roberts 2006).<br />
</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(EA)]] can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a [[model (glossary)]] to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The [[structure (glossary)]] and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process in (Martin 2005), the architecture should be driven by the “business questions” to be addressed by the architecture). <br />
<br />
The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown in (Martin 2003a and 2003b). The measures are shown, in this example, as success factors, key performance indicators, and information needs in the business strategy layer of the [[Architecture (glossary)|architecture]].<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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)]] systems to include additional items such as strategic goals and objectives, operators and [[User (glossary)|users]], organizations and other [[Stakeholder (glossary)|stakeholders]], funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36412
Enterprise Systems Engineering Process Activities
2012-07-23T05:55:19Z
<p>Jgercken: /* Balancing Effectiveness vs. Efficiency */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 additional to direct costs, there may also be indirect costs due to overhead factors or infrastructure [[Element (glossary)|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<br />
*Enterprise Evaluation and Assessment<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 transdisciplinary 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)]] to avoid or an [[Opportunity (glossary)]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
One reason that STP and TSP are separate processes is that these 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 timeframe. 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 (glossary)]] capability roadmaps [[Acronyms|(BCRMs)]] are related the [[operational (glossary)]] capabilities of the enterprise as a whole (ref: Business-Capability Mapping: Staying Ahead of the Joneses, http://msdn.microsoft.com/en-us/library/bb402954.aspx). The BCRM development is usually done as part of Enterprise Strategic Planning, which is one level higher than, and a key driver for, the Strategic Technical Planning activity described above.<br />
<br />
In some domains there may be [[competency (glossary)]] roadmaps dealing with the organizational capabilities, with perhaps the desired competency levels of individuals mapped out in terms of the jobs or roles used in the enterprise or perhaps in terms of the knowledge and skills required for certain activities. (For more information on SE competency, see the [[ Enabling Individuals to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<br />
<br />
This process establishes a [[measurement (glossary)]] program as the means for collecting data for use in the evaluation and assessment of the enterprise. These [[Measure (glossary)|measures]] help determine whether the strategy and its implementation are working as intended. Measures are projected into the future as the basis for determining discrepancies between what is observed and what had been predicted to occur. This process helps to identify risks and opportunities, diagnose problems, and prescribe appropriate actions. Sensitivity analysis is performed to determine the degree of [[robustness (glossary)]] and [[agility (glossary)]] of the enterprise.<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><br />
must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics (Roberts 2006).<br />
</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(EA)]] can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a [[model (glossary)]] to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The [[structure (glossary)]] and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process in (Martin 2005), the architecture should be driven by the “business questions” to be addressed by the architecture). <br />
<br />
The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown in (Martin 2003a and 2003b). The measures are shown, in this example, as success factors, key performance indicators, and information needs in the business strategy layer of the [[Architecture (glossary)|architecture]].<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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)]] systems to include additional items such as strategic goals and objectives, operators and [[User (glossary)|users]], organizations and other [[Stakeholder (glossary)|stakeholders]], funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36411
Enterprise Systems Engineering Process Activities
2012-07-23T05:53:43Z
<p>Jgercken: /* Balancing Effectiveness vs. Efficiency */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 additional to direct costs, there may also be indirect costs due to overhead factors or infrastructure [[Element (glossary)|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<br />
*Enterprise Evaluation and Assessment<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 transdisciplinary 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)]] to avoid or an [[Opportunity (glossary)]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
One reason that STP and TSP are separate processes is that these 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 timeframe. 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 (glossary)]] capability roadmaps [[Acronyms|(BCRMs)]] are related the [[operational (glossary)]] capabilities of the enterprise as a whole (ref: Business-Capability Mapping: Staying Ahead of the Joneses, http://msdn.microsoft.com/en-us/library/bb402954.aspx). The BCRM development is usually done as part of Enterprise Strategic Planning, which is one level higher than, and a key driver for, the Strategic Technical Planning activity described above.<br />
<br />
In some domains there may be [[competency (glossary)]] roadmaps dealing with the organizational capabilities, with perhaps the desired competency levels of individuals mapped out in terms of the jobs or roles used in the enterprise or perhaps in terms of the knowledge and skills required for certain activities. (For more information on SE competency, see the [[ Enabling Individuals to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<br />
<br />
This process establishes a [[measurement (glossary)]] program as the means for collecting data for use in the evaluation and assessment of the enterprise. These [[Measure (glossary)|measures]] help determine whether the strategy and its implementation are working as intended. Measures are projected into the future as the basis for determining discrepancies between what is observed and what had been predicted to occur. This process helps to identify risks and opportunities, diagnose problems, and prescribe appropriate actions. Sensitivity analysis is performed to determine the degree of [[robustness (glossary)]] and [[agility (glossary)]] of the enterprise.<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><br />
must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics (Roberts 2006).<br />
</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(EA)]] can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a [[model (glossary)]] to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The [[structure (glossary)]] and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process in (Martin 2005), the architecture should be driven by the “business questions” to be addressed by the architecture). <br />
<br />
The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown in (Martin 2003a and 2003b). The measures are shown, in this example, as success factors, key performance indicators, and information needs in the business strategy layer of the [[Architecture (glossary)|architecture]].<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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)]] systems to include additional items such as strategic goals and objectives, operators and [[User (glossary)|users]], organizations and other [[Stakeholder (glossary)|stakeholders]], funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Process_Activities&diff=36410
Enterprise Systems Engineering Process Activities
2012-07-23T05:52:16Z
<p>Jgercken: /* Enabling Systematic Enterprise Change */</p>
<hr />
<div><br />
[[File:ESE-F30_Process_Breakdown.png|thumb|center|700px|Figure 1. Enterprise Systems Engineering Process Activities (Figure Developed for SEBoK)]]<br />
<br />
==Systems Engineering Role in Transforming the Enterprise==<br />
<br />
===Enabling Systematic Enterprise Change===<br />
The [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(SE)]] [[Process (glossary)|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]] [[Acronyms|(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 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.'' (2006)</BLOCKQUOTE><br />
<br />
===Balancing Effectiveness vs. 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 additional to direct costs, there may also be indirect costs due to overhead factors or infrastructure [[Element (glossary)|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<br />
*Enterprise Evaluation and Assessment<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 transdisciplinary 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)]] to avoid or an [[Opportunity (glossary)]] to pursue in the technical strategy. The technical strategy is defined in terms of implementation guidance for the programs and [[Project (glossary)|projects]].<br />
<br />
One reason that STP and TSP are separate processes is that these 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 timeframe. 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 (glossary)]] capability roadmaps [[Acronyms|(BCRMs)]] are related the [[operational (glossary)]] capabilities of the enterprise as a whole (ref: Business-Capability Mapping: Staying Ahead of the Joneses, http://msdn.microsoft.com/en-us/library/bb402954.aspx). The BCRM development is usually done as part of Enterprise Strategic Planning, which is one level higher than, and a key driver for, the Strategic Technical Planning activity described above.<br />
<br />
In some domains there may be [[competency (glossary)]] roadmaps dealing with the organizational capabilities, with perhaps the desired competency levels of individuals mapped out in terms of the jobs or roles used in the enterprise or perhaps in terms of the knowledge and skills required for certain activities. (For more information on SE competency, see the [[ Enabling Individuals to Perform Systems Engineering ]] article.)<br />
<br />
[[File:ESE-F20.png|thumb|center|800px|Figure 1. Organizational, System & Operational Capabilities (Figure Developed for BKCASE)]]<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 [[Acronyms|(EE&A)]] is to determine if the enterprise is heading in the right direction. It does this by measuring progress towards realizing the enterprise vision. This process helps to “shape the environment” and to select among the program, project, and system opportunities. This is the primary means by which the technical dimensions of the enterprise are integrated into the business decisions.<br />
<br />
This process establishes a [[measurement (glossary)]] program as the means for collecting data for use in the evaluation and assessment of the enterprise. These [[Measure (glossary)|measures]] help determine whether the strategy and its implementation are working as intended. Measures are projected into the future as the basis for determining discrepancies between what is observed and what had been predicted to occur. This process helps to identify risks and opportunities, diagnose problems, and prescribe appropriate actions. Sensitivity analysis is performed to determine the degree of [[robustness (glossary)]] and [[agility (glossary)]] of the enterprise.<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><br />
must de-emphasize the utility of comparing detailed [[Metric (glossary)|metrics]] against specific individual [[Requirement (glossary)|requirement]] [[Value (glossary)|values]], whether the metrics are derived from measurement, [[Simulation (glossary)|simulation]] or estimation… [it] must instead look for break points where capabilities are either significantly enhanced or totally disabled. Key characteristics of this activity are the following:<br />
*Multi-scale analysis<br />
*Early and continuous operational involvement<br />
*Lightweight command and [[Control (glossary)|control]] [[Acronyms|(C2)]] capability representations<br />
*Developmental versions available for assessment<br />
*Minimal infrastructure<br />
*Flexible modeling and simulation [[Acronyms|(M&S)]], operator-in-the-loop [[Acronyms|(OITL)]], and hardware-in-the-loop [[Acronyms|(HWIL)]] capabilities<br />
*In-line, continuous performance monitoring and selective forensics (Roberts 2006).<br />
</BLOCKQUOTE><br />
[[Enterprise Architecture (glossary)|Enterprise architecture]] [[Acronyms|(EA)]] can be used as a primary tool in support of evaluation and assessment. EA can be used to provide a [[model (glossary)]] to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The [[structure (glossary)]] and contents of the EA should be driven by the key business decisions (or, as shown in the six-step process in (Martin 2005), the architecture should be driven by the “business questions” to be addressed by the architecture). <br />
<br />
The evaluation and assessment success measures can be put into the EA models and views directly and mapped to the [[Element (glossary)|elements]] that are being measured. An example of this can be seen in the US National Oceanographic and Atmospheric Agency [[Acronyms|(NOAA)]] EA shown in (Martin 2003a and 2003b). The measures are shown, in this example, as success factors, key performance indicators, and information needs in the business strategy layer of the [[Architecture (glossary)|architecture]].<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 [[Acronyms|(SoS)]], and an enterprise. The implication is that, at the enterprise level, there should be more focus on opportunity management than on risk management.<br />
<br />
[[File:ESE-F21.png|thumb|center|500px||Figure 2. Risk & Opportunity at the Enterprise Scale versus the Systems Scale (Rebovich and White 2011) Reprinted, by permission, from George Rebovich, Jr. and Brian E. White (eds), Enterprise Systems Engineering: Advances in the Theory and Practice, Figure ___. Boca Raton, FL: CRC Press, 2011. CRC Press URL: http://www.crcpress.com/product/isbn/9781420073294]]<br />
<br />
===Enterprise Architecture and Requirements===<br />
EA goes above and beyond the technical components of [[product (glossary)]] systems to include additional items such as strategic goals and objectives, operators and [[User (glossary)|users]], organizations and other [[Stakeholder (glossary)|stakeholders]], funding sources and methods, policies and practices, processes and procedures, facilities and platforms, infrastructure, and real estate. EA can be used to provide a model to understand how the parts of the enterprise fit together (or don’t) (Giachetti 2010). The EA is not strictly the province of the chief information officer [[Acronyms|(CIO)]], and is not only concerned with information technology. Likewise, enterprise requirements need to focus on the cross-cutting measures necessary to ensure overall enterprise success. Some of these enterprise requirements will apply to product systems, but they may also apply to business processes, inter-organizational commitments, hiring practices, investment directions, and so on (Bernus, Laszlo, and Schmidt 2003).<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 [[Acronyms|(FEAF)]] (CIO Council 1999) and the DoD Architecture Framework [[Acronyms|(DoDAF)]] (DoD 2010) were developed to support such an architecture-based investment process. There have been several other architecture frameworks also developed for this purpose (ISO 15704 2000; ISO/IEC 10746 1998; NATO 2004; MOD 2010; TRAK 2010).<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<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. PhD., 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 />
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. <br />
----<br />
<center>[[Enterprise Systems Engineering Key Concepts|< Previous Article]] | [[Enterprise Systems Engineering|Parent Article]] | [[Enterprise Capability Management|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=36409
Enterprise Systems Engineering Key Concepts
2012-07-23T05:46:19Z
<p>Jgercken: /* Enterprise Architecture Frameworks & Methodologies */</p>
<hr />
<div>==Introduction==<br />
The purpose of traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(TSE)]] is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] ([[Acronyms|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 [[Element (glossary)|elements]] of the organization’s [[business (glossary)|business]] strategy” (Carlock and Fenton 2001, 242-261). The traditional role of systems engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[context (glossary)|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 />
The MITRE Corporation has significantly developed ESE practices.<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.” 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 />
*[[Capability (glossary)|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.]]<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 />
[[File:ESE-F14.png|thumb|center|500px|Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities(Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies]]<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|1000px|Figure 3. Example of Enterprise Entities & Relationships (Troux 2010)Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 (glossary)]]. Some of these are described below.<br />
<br />
===TRAK Framework===<br />
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011). This framework was developed primarily for the rail industry in the United Kingdom but has been used in other domains as well.<br />
<br />
[[File:ESE-F16.png|thumb|center|800px|Figure 4.TRAK Metamodel (TRAK 2011) Released under the GNU Free Documentation License of Copyright (C) 2010 - 2011 UK Department for Transport. Source is available at http://trakmetamodel.sourceforge.net]]<br />
<br />
===DODAF Framework===<br />
The figure below shows the metamodel for the United States Department of Defense [[Acronyms|(DoD)]] Architecture framework (DoD 2010). <br />
<br />
<blockquote>"DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of 'operational views' detailing the external customer's operating domain in which the developing system will operate." (http://en.wikipedia.org/wiki/DODAF)</blockquote><br />
<br />
A related framework is the Ministry of Defense (MOD) Architecture Framework (MODAF): <br />
<br />
<blockquote>"Initially the purpose of MODAF was to provide rigour and structure to support the definition and integration of MOD equipment capability, particularly in support of Network Enabled Capability (NEC). More recently, MOD has additionally been using MODAF to underpin the use of the Enterprise Architecture approach to the capture of the information about the business to identify the processes and resources required to deliver the vision expressed in the strategy." (http://en.wikipedia.org/wiki/Modaf)</blockquote><br />
<br />
[[File:ESE-F17.png|thumb|600px|center|Figure 5. DoDAF Conceptual Data Model (DoD 2010) Released by the United States Department of Defense.]]<br />
<br />
===TOGAF Framework===<br />
Some frameworks (like The Open Group Architecture Framework [[Acronyms|(TOGAF)]]) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).<br />
<br />
[[File:ESE-F18.png|thumb|center|400px|Figure 6. TOGAF Methodology (TOGAF 2009 -Image credited to Marley NASA /SCI 2003) (Source: http://en.wikipedia.org/wiki/File:TOGAF_ADM.jpg) Accessed September 16, 2011. Released in the public domain from NASA.]]<br />
<br />
===Zachman Framework===<br />
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “[[Stakeholder (glossary)|stakeholder]] concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, [[Network (glossary)|networks]], people, time, and motivation. The rows represent the different stakeholder “perspectives”: [[Context (glossary)|contextual]] (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: [[scope (glossary)]] (i.e., contextual), business model, system model, technology model, and detailed representations.<br />
<br />
[[File:ESE-F19.png|thumb|600px|center|Figure 7. Zachman Framework (Zachmann 1992 –Image credited to Dekker and SunSw0rd) (Source: http://en.wikipedia.org/wiki/File:Zachman_Framework_Model.svg ) Accessed September 16, 2011. Released in the public domain by Wikimedia guidelines.]]<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 Journal 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 />
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, Richard 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 />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html 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 />
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 />
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 />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=36408
Enterprise Systems Engineering Key Concepts
2012-07-23T05:41:16Z
<p>Jgercken: /* Enterprise Entities and Relationships */</p>
<hr />
<div>==Introduction==<br />
The purpose of traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(TSE)]] is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] ([[Acronyms|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 [[Element (glossary)|elements]] of the organization’s [[business (glossary)|business]] strategy” (Carlock and Fenton 2001, 242-261). The traditional role of systems engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[context (glossary)|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 />
The MITRE Corporation has significantly developed ESE practices.<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.” 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 />
*[[Capability (glossary)|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.]]<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 />
[[File:ESE-F14.png|thumb|center|500px|Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities(Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies]]<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|1000px|Figure 3. Example of Enterprise Entities & Relationships (Troux 2010)Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 (glossary)]]. Some of these are described below.<br />
<br />
===TRAK Framework===<br />
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011). This framework was developed primarily for the rail industry in the United Kingdom but has been used in other domains as well.<br />
<br />
[[File:ESE-F16.png|thumb|center|800px|Figure 4.TRAK Metamodel (TRAK 2011) Released under the GNU Free Documentation License of Copyright (C) 2010 - 2011 UK Department for Transport. Source is available at http://trakmetamodel.sourceforge.net]]<br />
<br />
===DODAF Framework===<br />
The figure below shows the metamodel for the United States Department of Defense [[Acronyms|(DoD)]] Architecture framework (DoD 2010). "DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of 'operational views' detailing the external customer's operating domain in which the developing system will operate." (http://en.wikipedia.org/wiki/DODAF)<br />
<br />
A related framework is the Ministry of Defense (MOD) Architecture Framework (MODAF): "Initially the purpose of MODAF was to provide rigour and structure to support the definition and integration of MOD equipment capability, particularly in support of Network Enabled Capability (NEC). More recently, MOD has additionally been using MODAF to underpin the use of the Enterprise Architecture approach to the capture of the information about the business to identify the processes and resources required to deliver the vision expressed in the strategy." (http://en.wikipedia.org/wiki/Modaf)<br />
<br />
[[File:ESE-F17.png|thumb|600px|center|Figure 5. DoDAF Conceptual Data Model (DoD 2010) Released by the United States Department of Defense.]]<br />
<br />
===TOGAF Framework===<br />
Some frameworks (like The Open Group Architecture Framework [[Acronyms|(TOGAF)]]) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).<br />
<br />
[[File:ESE-F18.png|thumb|center|400px|Figure 6. TOGAF Methodology (TOGAF 2009 -Image credited to Marley NASA /SCI 2003) (Source: http://en.wikipedia.org/wiki/File:TOGAF_ADM.jpg) Accessed September 16, 2011. Released in the public domain from NASA.]]<br />
<br />
===Zachman Framework===<br />
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “[[Stakeholder (glossary)|stakeholder]] concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, [[Network (glossary)|networks]], people, time, and motivation. The rows represent the different stakeholder “perspectives”: [[Context (glossary)|contextual]] (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: [[scope (glossary)]] (i.e., contextual), business model, system model, technology model, and detailed representations.<br />
<br />
[[File:ESE-F19.png|thumb|600px|center|Figure 7. Zachman Framework (Zachmann 1992 –Image credited to Dekker and SunSw0rd) (Source: http://en.wikipedia.org/wiki/File:Zachman_Framework_Model.svg ) Accessed September 16, 2011. Released in the public domain by Wikimedia guidelines.]]<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 Journal 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 />
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, Richard 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 />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html 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 />
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 />
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 />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=36407
Enterprise Systems Engineering Key Concepts
2012-07-23T05:37:02Z
<p>Jgercken: /* Role of Requirements in ESE */</p>
<hr />
<div>==Introduction==<br />
The purpose of traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(TSE)]] is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] ([[Acronyms|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 [[Element (glossary)|elements]] of the organization’s [[business (glossary)|business]] strategy” (Carlock and Fenton 2001, 242-261). The traditional role of systems engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[context (glossary)|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 />
The MITRE Corporation has significantly developed ESE practices.<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.” 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 />
*[[Capability (glossary)|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.]]<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 group 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 is provided by Reese (2010).<br />
<br />
[[File:ESE-F14.png|thumb|center|500px|Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities(Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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|1000px|Figure 3. Example of Enterprise Entities & Relationships (Troux 2010)Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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)]] for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (or 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 (glossary)]]. Some of these are described below.<br />
<br />
===TRAK Framework===<br />
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011). This framework was developed primarily for the rail industry in the United Kingdom but has been used in other domains as well.<br />
<br />
[[File:ESE-F16.png|thumb|center|800px|Figure 4.TRAK Metamodel (TRAK 2011) Released under the GNU Free Documentation License of Copyright (C) 2010 - 2011 UK Department for Transport. Source is available at http://trakmetamodel.sourceforge.net]]<br />
<br />
===DODAF Framework===<br />
The figure below shows the metamodel for the United States Department of Defense [[Acronyms|(DoD)]] Architecture framework (DoD 2010). "DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of 'operational views' detailing the external customer's operating domain in which the developing system will operate." (http://en.wikipedia.org/wiki/DODAF)<br />
<br />
A related framework is the Ministry of Defense (MOD) Architecture Framework (MODAF): "Initially the purpose of MODAF was to provide rigour and structure to support the definition and integration of MOD equipment capability, particularly in support of Network Enabled Capability (NEC). More recently, MOD has additionally been using MODAF to underpin the use of the Enterprise Architecture approach to the capture of the information about the business to identify the processes and resources required to deliver the vision expressed in the strategy." (http://en.wikipedia.org/wiki/Modaf)<br />
<br />
[[File:ESE-F17.png|thumb|600px|center|Figure 5. DoDAF Conceptual Data Model (DoD 2010) Released by the United States Department of Defense.]]<br />
<br />
===TOGAF Framework===<br />
Some frameworks (like The Open Group Architecture Framework [[Acronyms|(TOGAF)]]) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).<br />
<br />
[[File:ESE-F18.png|thumb|center|400px|Figure 6. TOGAF Methodology (TOGAF 2009 -Image credited to Marley NASA /SCI 2003) (Source: http://en.wikipedia.org/wiki/File:TOGAF_ADM.jpg) Accessed September 16, 2011. Released in the public domain from NASA.]]<br />
<br />
===Zachman Framework===<br />
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “[[Stakeholder (glossary)|stakeholder]] concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, [[Network (glossary)|networks]], people, time, and motivation. The rows represent the different stakeholder “perspectives”: [[Context (glossary)|contextual]] (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: [[scope (glossary)]] (i.e., contextual), business model, system model, technology model, and detailed representations.<br />
<br />
[[File:ESE-F19.png|thumb|600px|center|Figure 7. Zachman Framework (Zachmann 1992 –Image credited to Dekker and SunSw0rd) (Source: http://en.wikipedia.org/wiki/File:Zachman_Framework_Model.svg ) Accessed September 16, 2011. Released in the public domain by Wikimedia guidelines.]]<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 Journal 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 />
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, Richard 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 />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html 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 />
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 />
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 />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=36406
Enterprise Systems Engineering Key Concepts
2012-07-23T05:35:18Z
<p>Jgercken: /* Closing the Gap */</p>
<hr />
<div>==Introduction==<br />
The purpose of traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(TSE)]] is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] ([[Acronyms|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 [[Element (glossary)|elements]] of the organization’s [[business (glossary)|business]] strategy” (Carlock and Fenton 2001, 242-261). The traditional role of systems engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[context (glossary)|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 />
The MITRE Corporation has significantly developed ESE practices.<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.” 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 />
*[[Capability (glossary)|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.]]<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)]] 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 group 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 is provided by Reese (2010).<br />
<br />
[[File:ESE-F14.png|thumb|center|500px|Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities(Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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|1000px|Figure 3. Example of Enterprise Entities & Relationships (Troux 2010)Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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)]] for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (or 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 (glossary)]]. Some of these are described below.<br />
<br />
===TRAK Framework===<br />
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011). This framework was developed primarily for the rail industry in the United Kingdom but has been used in other domains as well.<br />
<br />
[[File:ESE-F16.png|thumb|center|800px|Figure 4.TRAK Metamodel (TRAK 2011) Released under the GNU Free Documentation License of Copyright (C) 2010 - 2011 UK Department for Transport. Source is available at http://trakmetamodel.sourceforge.net]]<br />
<br />
===DODAF Framework===<br />
The figure below shows the metamodel for the United States Department of Defense [[Acronyms|(DoD)]] Architecture framework (DoD 2010). "DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of 'operational views' detailing the external customer's operating domain in which the developing system will operate." (http://en.wikipedia.org/wiki/DODAF)<br />
<br />
A related framework is the Ministry of Defense (MOD) Architecture Framework (MODAF): "Initially the purpose of MODAF was to provide rigour and structure to support the definition and integration of MOD equipment capability, particularly in support of Network Enabled Capability (NEC). More recently, MOD has additionally been using MODAF to underpin the use of the Enterprise Architecture approach to the capture of the information about the business to identify the processes and resources required to deliver the vision expressed in the strategy." (http://en.wikipedia.org/wiki/Modaf)<br />
<br />
[[File:ESE-F17.png|thumb|600px|center|Figure 5. DoDAF Conceptual Data Model (DoD 2010) Released by the United States Department of Defense.]]<br />
<br />
===TOGAF Framework===<br />
Some frameworks (like The Open Group Architecture Framework [[Acronyms|(TOGAF)]]) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).<br />
<br />
[[File:ESE-F18.png|thumb|center|400px|Figure 6. TOGAF Methodology (TOGAF 2009 -Image credited to Marley NASA /SCI 2003) (Source: http://en.wikipedia.org/wiki/File:TOGAF_ADM.jpg) Accessed September 16, 2011. Released in the public domain from NASA.]]<br />
<br />
===Zachman Framework===<br />
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “[[Stakeholder (glossary)|stakeholder]] concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, [[Network (glossary)|networks]], people, time, and motivation. The rows represent the different stakeholder “perspectives”: [[Context (glossary)|contextual]] (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: [[scope (glossary)]] (i.e., contextual), business model, system model, technology model, and detailed representations.<br />
<br />
[[File:ESE-F19.png|thumb|600px|center|Figure 7. Zachman Framework (Zachmann 1992 –Image credited to Dekker and SunSw0rd) (Source: http://en.wikipedia.org/wiki/File:Zachman_Framework_Model.svg ) Accessed September 16, 2011. Released in the public domain by Wikimedia guidelines.]]<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 Journal 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 />
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, Richard 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 />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html 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 />
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 />
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 />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Product_Systems_Engineering_Key_Aspects&diff=36405
Product Systems Engineering Key Aspects
2012-07-23T05:07:34Z
<p>Jgercken: /* Product Lifecycle & Product Adoption Rates */</p>
<hr />
<div>== Acquired Products vs. Offered Products ==<br />
<br />
The emphasis for traditional systems engineering ([[Acronyms|TSE]]) is in the provisioning of products and related services that meet stakeholder needs and requirements. For acquired products, an acquirer specifies the needs and requirements, selects a supplier for development and provisioning, and then receives the needed products and services. The acquirer, after acceptance, usually owns, operates, and maintains the product and the support systems supplied by the developer. Offered products are provided by suppliers based on opportunities to develop and offer products and services to potential users of the product based on business objectives usually measured in terms of value addition to the stakeholder. <br />
<br />
In the provisioning of product systems and related services, the enterprise owning and provisioning the product and services typically makes agreements with other suppliers to also provide elements, methods, and tools that are used during their entire life cycle. The supplying enterprises, in turn, may make further agreements with suppliers in regards to building a supply chain. The complexities of dealing with supply chains must be accounted for with respect to cost, risk, and schedule and thus can have an impact upon product or service maturity. (See articles under the [[Systems Engineering Organizational Strategy]] Knowledge Area in Part 5.)<br />
<br />
'''Acquired Products'''<br />
<br />
Specific needs for a product or service typically result in some form of an agreement between the acquirer and a supplier as specified in the agreement processes of ISO/IEC 15288 (2008). The acquirer specifies the need and requirements for the properties of the expected product or service and may or may not place specific requirements upon how the supplier plans to organize their life cycle treatment of the product or system.<br />
<br />
The degree of formality involved with the agreement varies and is strongly influenced by whether the customer is a government entity or a commercial entity. Government contracts usually incorporate strict specifications and other unique requirements that are rarely found in commercial contracts. Government acquisition agents often specify design characteristics in addition to functional and performance specifications. Design specifications place constraints on product systems engineering (PSE) by explicitly defining the details of a product's physical characteristics. The government acquirer may also specify how the product is to be designed and developed or how it is to be produced. Government specifications tend to be longer, more detailed, and more complex than functional specifications and much longer than specifications used in a commercial environment. <br />
<br />
When contracting with the government or similar enterprises, the PSE must identify disagreements related to the meaning of a particular provision in a contract, and work with contracts to get a written resolution of all ambiguities and issues in the specifications. Failure to do this can lead to legal disputes and government claims of product substitution which can prevent acceptance of the product system and result in financial penalties.<br />
<br />
Developing product systems for government customers requires PSE to do a thorough review and perform internal coordination within the enterprise to prevent it from submitting proposals that are non-compliant because the requirements are not fully understood. <br />
<br />
'''Offered Products'''<br />
<br />
Given an opportunity or perceived opportunity, an enterprise may decide to develop and offer products or services to a broader potential marketplace. The properties of the product or service are often determined through surveying and/or forecasting the potential market penetration. The supplier determines the structure and operation of an appropriate life cycle model for achieving the desired results (Pugh 1990).<br />
<br />
== Supply Chains & Distribution Channels ==<br />
<br />
The supply of products and services to the owner of a product or service that is acquired or offered at various points during the life cycle is vital to success. It is this wider system-of-interest (WSOI) that is the outsourcing holism that must be treated properly in order to provide successful products or services. A portrayal of supply chain structure is provided in Figure 1 below. <br />
<br />
[[File:PSE_PSEKA_Fig1.png|600px|thumb|left|Figure 1. Supply Chain Structure (Lawson) Reprinted with permission of Harold "Bud" Lawson.]] <br />
<br />
In Figure 1, it is important to note that in an agreement with a supplier, the outsourcing can involve delivering complete system description solutions or portions thereof. For example, a supplier could, given a set of stakeholder requirements developed by the acquirer, develop and supply a system that conforms to the architectural solution. The supplier in turn can be an acquirer of portions of their delivered results by outsourcing to other suppliers.<br />
<br />
In regards to production, the outsourcing agreement with a supplier can vary from total production responsibility to merely supplying instances of system elements to be integrated by the acquirer. Once again, these suppliers can be acquirers of portions of their delivery from outsourcing to other suppliers.<br />
<br />
In regards to utilization, for non-trivial systems, outsourcing agreements can be made with a supplier to provide for operational services, for example, operating a health care information system. Further agreements with suppliers can involve various forms of logistics aimed at sustaining a system product or service or for supplying assistance in the form of help desks. Once again, suppliers that agree to provide services related to utilization can be acquirers of the services of other suppliers.<br />
<br />
Important to all supply chains is the concept that supplying parties contribute some form of added value to the life cycle of a system-of-interest. The proper management of a supply chain system asset is a vital part of the operations of an enterprise. In fact, the supply chain itself is an enterprise system-of-interest that is composed of acquirers and suppliers as system elements. There is definitely a structure tied together by agreement relationships. Further, the operation of the supply chain results in an emergent behavior. The supply chain system becomes a vital infrastructure asset in the system portfolios of enterprises and forms the basis for extended enterprises. <br />
<br />
Similar to a supply chain, the distribution channels for a product system can be a complex web of relationships between the product supplier and various distributors, for example, package delivery companies, warehouses, service depots, wholesale outlets, retail sales establishments, operator training and certification organizations, and so on. The nature of the distribution channels could have a significant impact on the architecture or design of a product system.<br />
<br />
PSE may need to include special features in the product design to accommodate for the needs of distribution channel elements, for example, heavy load tie down or lifting brackets, protective shipping packages, retail marketing displays, product brochures, installation manuals, operator certification packages, training materials, and so on. Sometimes it may be necessary to create special versions (or instances) of the product for the training of operators and users for certifying safe or secure operations, for environmental testing and qualification, for product demonstration and user testing, for patent application, for load testing and scalability demonstrations, and for interface fit checking and mass balance certification, to name some examples.<br />
<br />
== Product Lifecycle & Product Adoption Rates ==<br />
<br />
The life cycle of each product follows the typical incremental development phases shown below (Wasson 2006, 59-65). A particular product to be engineered could be preceded by a previous “model” of that product as shown in the product model life cycle below, and could be superseded later by a newer model of that product. It is worth noting that there is no standard set of life cycle phases. The example below is one of many ways that the phases can be structured. <br />
<br />
[[File:PSE_PSEKA_Fig2.png|600px|thumb|center|Figure 2. Product Lifecycle as Related to the Product Model Lifecycle (Wasson 2006) Reprinted with permission of John Wiley & Sons, Inc.]]<br />
<br />
From an industry perspective, managing a product’s life cycle involves more than just the engineering aspects:<br />
<br />
''<blockquote>Product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception through design and manufacture to service and disposal. PLM integrates people, data, processes and business systems, and provides a product information backbone for companies and their extended enterprise.'' (http://en.wikipedia.org/wiki/Product_lifecycle_management)</blockquote><br />
<br />
There are many PLM tools and services available for facilitating the development and management of complicated product life cycles and especially for product line management (insert link to product line mgmt section here).<br />
<br />
[[File:PSE_PSEKA_Fig3.png|600px|thumb|center|Figure 3. Product Lifecycle from an Industry Perspective (Source: http://commons.wikimedia.org/wiki/File:Product%E2%80%99s_lifecycle.jpg#filelinks Accessed February 6, 2012. NIST Programs of the Manufacturing Engineering Laboratory, Released by US Federal Government, Public Domain)]]<br />
<br />
The product and product model life cycles are driven by the product adoption rate, illustrated below, that is commonly experienced by most engineered products (Rogers 2003). As products reach market saturation (i.e., on the down slope of the curve below) then there would typically be a new, upgraded version of the product ready for delivery to the marketplace. PSE serves a critical role in determining the best timing for delivery of this new version and the set of features and functions that would be of the greatest value at that time.<br />
<br />
[[File:PSE_PSEKA_Fig4.png|600px|thumb|center|Figure 4. Rogers Innovation Adoption Curve (Source: http://en.wikipedia.org/wiki/File:Diffusionofideas.PNG Accessed February 6, 2012, Released by Tungsten, Public Domain)]]<br />
<br />
== Integrated Product Teams and Integrated Product Development ==<br />
<br />
Product systems as discussed throughout this KA mandate the participation of different disciplines for their success during their entire lifecycle from concept to product disposal or retirement. Rapid technology innovations and market pressures in the mid '90s demanded development process (mostly input-output serial) to shorten their development time and development cost, and to improve product quality to remain competitive. For commercial enterprises, the typical development times of 18-24 months to deploy new products into markets of the '90s have in many cases been reduced to 6-12 months and even 3-6 months for the highly competitive leading edge information technology products.<br />
<br />
An initial response to these pressures was concurrent engineering. Concurrent engineering is “... a systematic approach to the integrated, concurrent design of products and their related processes, including manufacturing and support to cause developers, from the outset to consider all elements of the product lifecycle from conception through disposal, including quality, cost, schedule and end user requirements." This definition has evolved into the integrated product development (IPD) as more descriptive of this concurrency to describe the continuous integration of the entire product team, including engineering, manufacturing, test, and support through the life cycle. Later, as the importance of the process was recognized, the terminology was modified to integrated product and process development or IPPD (INCOSE 2.a). <br />
<br />
The INCOSE Systems Engineering Handbook v. 3.1 provides a good description of the IPT and IPDT process; the different types of IPDT; the steps in organizing and running an IPDT; good examples of IPDT, particularly for acquired systems; and a good discussion on IPDT pitfalls to avoid.<br />
<br />
In the case of commercial enterprises, product development is tightly coupled with business strategies (short and long term), stakeholder value added measured in terms of return on investments (ROI), market presence/coverage, and other strategies as defined by the business objectives. Thus, product integration teams include strategic planners, business managers, financial managers, market managers, quality assurance managers, customer representatives, and end-users, as well as other disciplines required for acquired products. Phillips (2001), Annachino (2003), and Morse (2007) provide good discussions on this topic.<br />
<br />
== Role of Architecture, Requirement & Standards ==<br />
<br />
The architectural properties of a product system are influenced by the concerns of the various stakeholders as indicated in the ISO/IEC 42010 standard. The stakeholders have various views that they express based on their specific perspective. These views are vital in establishing requirements and are inputs to those responsible for defining the functions, structures, and relationships needed to achieve the desired product or service.<br />
<br />
A number of stakeholders have been identified in the discussions of product systems. It would be possible to identify a set of important stakeholders based on the life cycle thinking provided by the ISO/IEC 15288 standard, for example, one such set could consist of owners, conceivers, developers, producers, users, and maintainers as discussed by Lawson (2010). As mentioned earlier, these stakeholders should cooperate at all stages of the life cycle in specifying requirements, verifying that the requirements are met, and validating that the products produced provide needed capabilities.<br />
<br />
In addition to the two standards that have been identified, there are a variety of standards related to specialty aspects of products, such as safety and security, as well as standards that are applicable for project management and life cycle considerations, such as requirements and quality management.<br />
<br />
== Role of Modeling, Simulation, Prototyping & Experimentation ==<br />
<br />
Modelling, simulation, prototyping, and experimentation are techniques that have the purpose of improving stakeholder knowledge and shared understanding about aspects of the system to de-risk system development and operation before heavy commitment of time and funds. Examples of this are found below:<br />
<br />
*Understanding future needs: “Warfighting experiments are the heart of the Army's warfighting requirements determination process. Progressive and iterative mixes of high fidelity constructive, virtual, and live simulations using real soldiers and units in relevant, tactically competitive scenarios provide Army leaders with future operational capability insights" (US Army). <br />
*Simulation is used to predict and optimise aspects of system performance for which there are good mathematical or logical models before committing the final physical design, and also to verify and validate the system design in scenarios where physical testing is too difficult, dangerous, or expensive, for example, checking the performance envelope of military systems in a wide range of engagement scenarios where test firing thousands of rounds to get statistically valid data is clearly unaffordable, ensuring that the safety features in a nuclear power station will operate correctly in a wide range of stressing scenarios, etc.<br />
*Prototyping (physical and virtual) is used in a wide variety of ways to check out aspects of system performance, usability, utility, and to validate models and simulations as part of the iterative process of converging on a final design.<br />
*In a manufacturing context, the first units produced are often “prototypes” intended to make sure the production process is working properly before committing to high rate production, and are often not shipped to end users, but used for intensive testing to qualify the design.<br />
*Simulation is also used extensively for training and marketing purposes. For training, an accurate model of the human machine interface and representation of the operational context allows operators to do most of their training without putting operational hours on the real system enabling them to learn emergency procedures for combat and accident scenarios in a safe and repeatable environment; for example, airline and military pilots now train mainly on simulators. System simulators of various levels of fidelity are used to familiarise customers and end users with the potential characteristics and benefits of the system, available options and trade-offs, and integration issues early in the development and acquisition process.<br />
<br />
All of these methods use a variety of physical and mathematical representations of the system and its environment so modelling is an enabler for simulation, prototyping, and experimentation.<br />
<br />
== Increasing Role of Software in Product Functionality ==<br />
<br />
An important trend in marketed products is the increasing importance of software in an increasingly wide range of products. Everything from phones, cameras, cars, test gear, and medical equipment now has essential functionality implemented in software. Software has had an increasing role in providing the desired functionality in many products. The embedding of software in many types of products accounts for increasing portions of product functionality. In tangible products such as cars, software helps improve functionality and usability (cruise control, climate control, etc.). In intangible products such as insurance, software helps in improving operational efficiency, data accessibility, etc. <br />
<br />
The movement toward the internet of “things” where sensing and activating functions are incorporated is now starting to permeate. The use of various software products in proving service is also described in the Service Systems Engineering article in the SeBOK. <br />
<br />
Recent advancements in IT and software have assisted in their increased use in PSE. Although software development is already a very complex field, the role of software in the development and functionality of products is growing larger each day. <br />
<br />
There is a need to broaden the horizons of software engineers to think of problem solving not only in software terms, but also using the systems thinking approach. For this purpose, software engineers need to be able to think critically about the problem and also the possible solutions to the problem or opportunity and its implication for business objectives.<br />
<br />
== Product Integration & Interface Control ==<br />
<br />
Integration is "the set of activities that bring together smaller units of a system into larger units" (Eisner 2008). Products may consists of several systems, subsystems, assemblies, parts, etc., which have to work together as a whole to deliver the offered product’s functionalities at specified performance levels in the intended operations environment. Product integration entails not only the working together of hardware and software components, but also the organization, processes, people, facilities, and the resources for the manufacturing, distribution, maintenance, customer support, sales channels, etc. Grady (2010) groups the above information into three fundamental integration components: functional organization, product integration, and process integration.<br />
<br />
PSE plays an important role to ensure well defined interfaces, interactions, relationships, information exchange, and processes requirements between product components. These requirements are baseline, documented, traced, verified, and validated for the end-to-end Product integration and to maintain and ensure product offering integrity during its life cycle. The systems engineering hierarchical decomposition level allows requirement definition and allocations at different levels of abstraction to define the building blocks of the product architecture; these building blocks are assigned to integrated product development teams (IPDTs) for detailed design and development. The IPDTs or the systems engineering integration team (SEIT) must interact with all involved players to generate appropriate architectural block specifications at the lower tier of development for a product’s architectural configuration and configuration tracking. As the building blocks are put together, interface requirements, information exchange, and interaction and relationships among entities are verified against the baseline. Once a configuration item has been built and tested against the baseline, test and verification at higher levels are conducted to obtain the final product configuration; the final product configuration can only be changed by a formal approval from a configuration control board (CCB). <br />
<br />
Interface agreements, specifications, and interface designs are usually documented through the interface control documents (ICD) and the interface design descriptions (IDD); in some instances, depending on the complexity of the product and the type of internal and/or external interfaces, an interface control working group (ICWG) is created to analyze and baseline changes to an interface for further recommendation to the CCB.<br />
<br />
A configuration item (CI) may be hardware (HWCI), software (CSCI), firmware, subsystems, assemblies, non-Development items, commercial off-the-shelf (COTS) items, acquirer furnished equipment, and/or processes. Please see Wasson (2006), Grady (2006), and INCOSE v. 3.1 for a more detailed description of configuration and interface control.<br />
<br />
A product may experience hundreds of changes during its life cycle due to new product releases/enhancements, repair/replacement of parts, upgrades/updates in operating systems, computer infrastructure, software modules, organizational changes, changes in processes and/or methods and procedures, etc. Thus, strong mechanisms for bookkeeping and activity control need to be in place to identify, control, audit, account and trace interfaces, interactions, and relationships between entities that are required to maintain product configuration status (Eisner 2008). The product configuration and CI’s are then controlled through the configuration management process.<br />
<br />
== Configuration Management (CM) & Risk Management (RM) ==<br />
<br />
Configuration management (CM) deals with the identification, control, auditing, status accounting, and traceability aspects of the product, and broadly covers the book-keeping and control activities of the systems engineering process (Eisner 2001). Any product configuration changes to the baseline (configuration item, operational baseline, functional baseline, behavior baseline) or product baseline are submitted to a configuration control board (CCB) through an engineering change request (ECR) and/or a configuration change request (CCR). The CCB then analyzes the request to understand CI impacts and the feasibility (time and cost) of authorization or rejection of change request(s). The lack of proper control and tracking of CI and product baselines may result in a loss of features, functionality, data, interfaces, etc., leading to backtracking and CI version losses which may affect the offered product. All approved changes will have to be baselined, documented, and tested for backward compatibility and to ensure compliance with the integrated product functionality. Thus, successful implementation and life cycle management of the product mandates a highly disciplined CM process that maintains proper control over the product and its components. Please see the INCOSE Systems Engineering Handbook v. 3.1 for a detailed description of the CM Process.<br />
<br />
Risk management deals with the identification, assessment, and prioritization of technical, cost, schedule, and programmatic risks in any system. Almost all engineered systems are designed, constructed, and operated under some level of risks and uncertainty while achieving multiple, and often conflicting, objectives. As greater complexities and new technologies are introduced in modern systems, the potential of risks have significantly increased. Thus, the overall managerial decision-making process should involve an extensive cost-benefit analysis of all identified, qualified, and evaluated risks (Haimes 2008). Risk management involves the coordinated and most cost-effective application of resources to minimize, monitor, and control the probability and/or impact of all identified risks within the systems engineering process (http://en.wikipedia.org/wiki/Risk_management). The risk management process requires the involvement of several disciplines and encompasses empirical, quantitative, and normative judgmental aspects of decision-making. Furthermore, risk assessment and management should be integrated and incorporated within the broader holistic approach so technology management can help align the risk management requirements to the overall systems engineering requirements. Thus, the inclusion of a well defined risk management plan that deals with the analysis of risks, within the systems engineering master plan is vital for the long term and sustained success of any system (Blanchard and Fabrycky 2011).<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Anachino, M. 2003. ''New Product Development: From Initial Idea to Product Management''. Elsevier. <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 />
Eisner, H. 2008. ''Essentials of Project and Systems Engineering Management'', 3rd edition. New York, NY, USA: John Wiley & Sons. <br />
<br />
Grady, J. 2006. ''System Requirements Analysis''. Elsevier. <br />
<br />
Haimes, Y. 2008. ''Risk Modeling, Assessment, and Management,'' 3rd edition. New York, NY, USA: John Wiley & Sons. <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 />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications. Kings College, UK.<br />
<br />
Morse, L. and D. Babcock. 2007. ''Managing Engineering and Technology''. International Series in Industrial and Systems Engineering. Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Phillips, F. 2001. ''Market Oriented Technology Management: Innovating for Profit in Entrepreneurial Times''. New York, NY, USA: Springer.<br />
<br />
Wasson, C. S. 2006. ''System Analysis, Design, and Development''. Hoboken, NJ, USA: John Wiley & Sons. <br />
<br />
Rogers, E. M. 2003. Diffusion of innovations (5th ed.). New York, NY: Free Press.<br />
<br />
Pugh, S. 1990. Total Design: Integrated Methods for Successful Product Engineering. Prentice Hall. ISBN-10: 0201416395, ISBN-13: 978-0201416398.<br />
<br />
Smith, P. and Reinertsen, D. 1997. Developing products in half the time – new rules, new tools. John Wiley and Sons. 2nd edition. ISBN-10: 0471292524, ISBN-13: 978-0471292524 <br />
<br />
Reinertsen, D. 1997. Managing the Design Factory: A Product Developers Tool Kit. Simon & Shuster Ltd. ISBN-10: 0684839911 ISBN-13: 978-0684839912<br />
<br />
US Army, Chapter 2, section A.4 of Army Science and Technology Master Plan. dowloaded from http://www.fas.org/man/dod-101/army/docs/astmp/c2/P2A4.htm, accessed on 12 Jan 2012<br />
<br />
Kass, R. 2006. The logic of warfighting experiments. DOD CCRP – downloaded from http://www.dodccrp.org/files/Kass_Logic.pdf, 12Jan 2012<br />
<br />
===Primary References===<br />
No primary references have been identified for version 0.75. Please provide any recommendations on primary references in your review.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
<center>[[Business Activities Related to Product Systems Engineering|< Previous Article]] | [[Product Systems Engineering|Parent Article]] | [[Product Systems Engineering Special Activities|Next Article >]]</center><br />
<br />
=Comments from 0.5 Wiki=<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Product Systems Engineering]]</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Product_Systems_Engineering_Key_Aspects&diff=36404
Product Systems Engineering Key Aspects
2012-07-23T05:07:06Z
<p>Jgercken: </p>
<hr />
<div>== Acquired Products vs. Offered Products ==<br />
<br />
The emphasis for traditional systems engineering ([[Acronyms|TSE]]) is in the provisioning of products and related services that meet stakeholder needs and requirements. For acquired products, an acquirer specifies the needs and requirements, selects a supplier for development and provisioning, and then receives the needed products and services. The acquirer, after acceptance, usually owns, operates, and maintains the product and the support systems supplied by the developer. Offered products are provided by suppliers based on opportunities to develop and offer products and services to potential users of the product based on business objectives usually measured in terms of value addition to the stakeholder. <br />
<br />
In the provisioning of product systems and related services, the enterprise owning and provisioning the product and services typically makes agreements with other suppliers to also provide elements, methods, and tools that are used during their entire life cycle. The supplying enterprises, in turn, may make further agreements with suppliers in regards to building a supply chain. The complexities of dealing with supply chains must be accounted for with respect to cost, risk, and schedule and thus can have an impact upon product or service maturity. (See articles under the [[Systems Engineering Organizational Strategy]] Knowledge Area in Part 5.)<br />
<br />
'''Acquired Products'''<br />
<br />
Specific needs for a product or service typically result in some form of an agreement between the acquirer and a supplier as specified in the agreement processes of ISO/IEC 15288 (2008). The acquirer specifies the need and requirements for the properties of the expected product or service and may or may not place specific requirements upon how the supplier plans to organize their life cycle treatment of the product or system.<br />
<br />
The degree of formality involved with the agreement varies and is strongly influenced by whether the customer is a government entity or a commercial entity. Government contracts usually incorporate strict specifications and other unique requirements that are rarely found in commercial contracts. Government acquisition agents often specify design characteristics in addition to functional and performance specifications. Design specifications place constraints on product systems engineering (PSE) by explicitly defining the details of a product's physical characteristics. The government acquirer may also specify how the product is to be designed and developed or how it is to be produced. Government specifications tend to be longer, more detailed, and more complex than functional specifications and much longer than specifications used in a commercial environment. <br />
<br />
When contracting with the government or similar enterprises, the PSE must identify disagreements related to the meaning of a particular provision in a contract, and work with contracts to get a written resolution of all ambiguities and issues in the specifications. Failure to do this can lead to legal disputes and government claims of product substitution which can prevent acceptance of the product system and result in financial penalties.<br />
<br />
Developing product systems for government customers requires PSE to do a thorough review and perform internal coordination within the enterprise to prevent it from submitting proposals that are non-compliant because the requirements are not fully understood. <br />
<br />
'''Offered Products'''<br />
<br />
Given an opportunity or perceived opportunity, an enterprise may decide to develop and offer products or services to a broader potential marketplace. The properties of the product or service are often determined through surveying and/or forecasting the potential market penetration. The supplier determines the structure and operation of an appropriate life cycle model for achieving the desired results (Pugh 1990).<br />
<br />
== Supply Chains & Distribution Channels ==<br />
<br />
The supply of products and services to the owner of a product or service that is acquired or offered at various points during the life cycle is vital to success. It is this wider system-of-interest (WSOI) that is the outsourcing holism that must be treated properly in order to provide successful products or services. A portrayal of supply chain structure is provided in Figure 1 below. <br />
<br />
[[File:PSE_PSEKA_Fig1.png|600px|thumb|left|Figure 1. Supply Chain Structure (Lawson) Reprinted with permission of Harold "Bud" Lawson.]] <br />
<br />
In Figure 1, it is important to note that in an agreement with a supplier, the outsourcing can involve delivering complete system description solutions or portions thereof. For example, a supplier could, given a set of stakeholder requirements developed by the acquirer, develop and supply a system that conforms to the architectural solution. The supplier in turn can be an acquirer of portions of their delivered results by outsourcing to other suppliers.<br />
<br />
In regards to production, the outsourcing agreement with a supplier can vary from total production responsibility to merely supplying instances of system elements to be integrated by the acquirer. Once again, these suppliers can be acquirers of portions of their delivery from outsourcing to other suppliers.<br />
<br />
In regards to utilization, for non-trivial systems, outsourcing agreements can be made with a supplier to provide for operational services, for example, operating a health care information system. Further agreements with suppliers can involve various forms of logistics aimed at sustaining a system product or service or for supplying assistance in the form of help desks. Once again, suppliers that agree to provide services related to utilization can be acquirers of the services of other suppliers.<br />
<br />
Important to all supply chains is the concept that supplying parties contribute some form of added value to the life cycle of a system-of-interest. The proper management of a supply chain system asset is a vital part of the operations of an enterprise. In fact, the supply chain itself is an enterprise system-of-interest that is composed of acquirers and suppliers as system elements. There is definitely a structure tied together by agreement relationships. Further, the operation of the supply chain results in an emergent behavior. The supply chain system becomes a vital infrastructure asset in the system portfolios of enterprises and forms the basis for extended enterprises. <br />
<br />
Similar to a supply chain, the distribution channels for a product system can be a complex web of relationships between the product supplier and various distributors, for example, package delivery companies, warehouses, service depots, wholesale outlets, retail sales establishments, operator training and certification organizations, and so on. The nature of the distribution channels could have a significant impact on the architecture or design of a product system.<br />
<br />
PSE may need to include special features in the product design to accommodate for the needs of distribution channel elements, for example, heavy load tie down or lifting brackets, protective shipping packages, retail marketing displays, product brochures, installation manuals, operator certification packages, training materials, and so on. Sometimes it may be necessary to create special versions (or instances) of the product for the training of operators and users for certifying safe or secure operations, for environmental testing and qualification, for product demonstration and user testing, for patent application, for load testing and scalability demonstrations, and for interface fit checking and mass balance certification, to name some examples.<br />
<br />
== Product Lifecycle & Product Adoption Rates ==<br />
<br />
The life cycle of each product follows the typical incremental development phases shown below (Wasson 2006, 59-65). A particular product to be engineered could be preceded by a previous “model” of that product as shown in the product model life cycle below, and could be superseded later by a newer model of that product. It is worth noting that there is no standard set of life cycle phases. The example below is one of many ways that the phases can be structured. <br />
<br />
[[File:PSE_PSEKA_Fig2.png|600px|thumb|center|Figure 2. Product Lifecycle as Related to the Product Model Lifecycle (Wasson 2006) Reprinted with permission of John Wiley & Sons, Inc.]]<br />
<br />
From an industry perspective, managing a product’s life cycle involves more than just the engineering aspects:<br />
<br />
''<blockquote>Product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception through design and manufacture to service and disposal. PLM integrates people, data, processes and business systems, and provides a product information backbone for companies and their extended enterprise. (http://en.wikipedia.org/wiki/Product_lifecycle_management)</blockquote>''<br />
<br />
There are many PLM tools and services available for facilitating the development and management of complicated product life cycles and especially for product line management (insert link to product line mgmt section here).<br />
<br />
[[File:PSE_PSEKA_Fig3.png|600px|thumb|center|Figure 3. Product Lifecycle from an Industry Perspective (Source: http://commons.wikimedia.org/wiki/File:Product%E2%80%99s_lifecycle.jpg#filelinks Accessed February 6, 2012. NIST Programs of the Manufacturing Engineering Laboratory, Released by US Federal Government, Public Domain)]]<br />
<br />
The product and product model life cycles are driven by the product adoption rate, illustrated below, that is commonly experienced by most engineered products (Rogers 2003). As products reach market saturation (i.e., on the down slope of the curve below) then there would typically be a new, upgraded version of the product ready for delivery to the marketplace. PSE serves a critical role in determining the best timing for delivery of this new version and the set of features and functions that would be of the greatest value at that time.<br />
<br />
[[File:PSE_PSEKA_Fig4.png|600px|thumb|center|Figure 4. Rogers Innovation Adoption Curve (Source: http://en.wikipedia.org/wiki/File:Diffusionofideas.PNG Accessed February 6, 2012, Released by Tungsten, Public Domain)]]<br />
<br />
== Integrated Product Teams and Integrated Product Development ==<br />
<br />
Product systems as discussed throughout this KA mandate the participation of different disciplines for their success during their entire lifecycle from concept to product disposal or retirement. Rapid technology innovations and market pressures in the mid '90s demanded development process (mostly input-output serial) to shorten their development time and development cost, and to improve product quality to remain competitive. For commercial enterprises, the typical development times of 18-24 months to deploy new products into markets of the '90s have in many cases been reduced to 6-12 months and even 3-6 months for the highly competitive leading edge information technology products.<br />
<br />
An initial response to these pressures was concurrent engineering. Concurrent engineering is “... a systematic approach to the integrated, concurrent design of products and their related processes, including manufacturing and support to cause developers, from the outset to consider all elements of the product lifecycle from conception through disposal, including quality, cost, schedule and end user requirements." This definition has evolved into the integrated product development (IPD) as more descriptive of this concurrency to describe the continuous integration of the entire product team, including engineering, manufacturing, test, and support through the life cycle. Later, as the importance of the process was recognized, the terminology was modified to integrated product and process development or IPPD (INCOSE 2.a). <br />
<br />
The INCOSE Systems Engineering Handbook v. 3.1 provides a good description of the IPT and IPDT process; the different types of IPDT; the steps in organizing and running an IPDT; good examples of IPDT, particularly for acquired systems; and a good discussion on IPDT pitfalls to avoid.<br />
<br />
In the case of commercial enterprises, product development is tightly coupled with business strategies (short and long term), stakeholder value added measured in terms of return on investments (ROI), market presence/coverage, and other strategies as defined by the business objectives. Thus, product integration teams include strategic planners, business managers, financial managers, market managers, quality assurance managers, customer representatives, and end-users, as well as other disciplines required for acquired products. Phillips (2001), Annachino (2003), and Morse (2007) provide good discussions on this topic.<br />
<br />
== Role of Architecture, Requirement & Standards ==<br />
<br />
The architectural properties of a product system are influenced by the concerns of the various stakeholders as indicated in the ISO/IEC 42010 standard. The stakeholders have various views that they express based on their specific perspective. These views are vital in establishing requirements and are inputs to those responsible for defining the functions, structures, and relationships needed to achieve the desired product or service.<br />
<br />
A number of stakeholders have been identified in the discussions of product systems. It would be possible to identify a set of important stakeholders based on the life cycle thinking provided by the ISO/IEC 15288 standard, for example, one such set could consist of owners, conceivers, developers, producers, users, and maintainers as discussed by Lawson (2010). As mentioned earlier, these stakeholders should cooperate at all stages of the life cycle in specifying requirements, verifying that the requirements are met, and validating that the products produced provide needed capabilities.<br />
<br />
In addition to the two standards that have been identified, there are a variety of standards related to specialty aspects of products, such as safety and security, as well as standards that are applicable for project management and life cycle considerations, such as requirements and quality management.<br />
<br />
== Role of Modeling, Simulation, Prototyping & Experimentation ==<br />
<br />
Modelling, simulation, prototyping, and experimentation are techniques that have the purpose of improving stakeholder knowledge and shared understanding about aspects of the system to de-risk system development and operation before heavy commitment of time and funds. Examples of this are found below:<br />
<br />
*Understanding future needs: “Warfighting experiments are the heart of the Army's warfighting requirements determination process. Progressive and iterative mixes of high fidelity constructive, virtual, and live simulations using real soldiers and units in relevant, tactically competitive scenarios provide Army leaders with future operational capability insights" (US Army). <br />
*Simulation is used to predict and optimise aspects of system performance for which there are good mathematical or logical models before committing the final physical design, and also to verify and validate the system design in scenarios where physical testing is too difficult, dangerous, or expensive, for example, checking the performance envelope of military systems in a wide range of engagement scenarios where test firing thousands of rounds to get statistically valid data is clearly unaffordable, ensuring that the safety features in a nuclear power station will operate correctly in a wide range of stressing scenarios, etc.<br />
*Prototyping (physical and virtual) is used in a wide variety of ways to check out aspects of system performance, usability, utility, and to validate models and simulations as part of the iterative process of converging on a final design.<br />
*In a manufacturing context, the first units produced are often “prototypes” intended to make sure the production process is working properly before committing to high rate production, and are often not shipped to end users, but used for intensive testing to qualify the design.<br />
*Simulation is also used extensively for training and marketing purposes. For training, an accurate model of the human machine interface and representation of the operational context allows operators to do most of their training without putting operational hours on the real system enabling them to learn emergency procedures for combat and accident scenarios in a safe and repeatable environment; for example, airline and military pilots now train mainly on simulators. System simulators of various levels of fidelity are used to familiarise customers and end users with the potential characteristics and benefits of the system, available options and trade-offs, and integration issues early in the development and acquisition process.<br />
<br />
All of these methods use a variety of physical and mathematical representations of the system and its environment so modelling is an enabler for simulation, prototyping, and experimentation.<br />
<br />
== Increasing Role of Software in Product Functionality ==<br />
<br />
An important trend in marketed products is the increasing importance of software in an increasingly wide range of products. Everything from phones, cameras, cars, test gear, and medical equipment now has essential functionality implemented in software. Software has had an increasing role in providing the desired functionality in many products. The embedding of software in many types of products accounts for increasing portions of product functionality. In tangible products such as cars, software helps improve functionality and usability (cruise control, climate control, etc.). In intangible products such as insurance, software helps in improving operational efficiency, data accessibility, etc. <br />
<br />
The movement toward the internet of “things” where sensing and activating functions are incorporated is now starting to permeate. The use of various software products in proving service is also described in the Service Systems Engineering article in the SeBOK. <br />
<br />
Recent advancements in IT and software have assisted in their increased use in PSE. Although software development is already a very complex field, the role of software in the development and functionality of products is growing larger each day. <br />
<br />
There is a need to broaden the horizons of software engineers to think of problem solving not only in software terms, but also using the systems thinking approach. For this purpose, software engineers need to be able to think critically about the problem and also the possible solutions to the problem or opportunity and its implication for business objectives.<br />
<br />
== Product Integration & Interface Control ==<br />
<br />
Integration is "the set of activities that bring together smaller units of a system into larger units" (Eisner 2008). Products may consists of several systems, subsystems, assemblies, parts, etc., which have to work together as a whole to deliver the offered product’s functionalities at specified performance levels in the intended operations environment. Product integration entails not only the working together of hardware and software components, but also the organization, processes, people, facilities, and the resources for the manufacturing, distribution, maintenance, customer support, sales channels, etc. Grady (2010) groups the above information into three fundamental integration components: functional organization, product integration, and process integration.<br />
<br />
PSE plays an important role to ensure well defined interfaces, interactions, relationships, information exchange, and processes requirements between product components. These requirements are baseline, documented, traced, verified, and validated for the end-to-end Product integration and to maintain and ensure product offering integrity during its life cycle. The systems engineering hierarchical decomposition level allows requirement definition and allocations at different levels of abstraction to define the building blocks of the product architecture; these building blocks are assigned to integrated product development teams (IPDTs) for detailed design and development. The IPDTs or the systems engineering integration team (SEIT) must interact with all involved players to generate appropriate architectural block specifications at the lower tier of development for a product’s architectural configuration and configuration tracking. As the building blocks are put together, interface requirements, information exchange, and interaction and relationships among entities are verified against the baseline. Once a configuration item has been built and tested against the baseline, test and verification at higher levels are conducted to obtain the final product configuration; the final product configuration can only be changed by a formal approval from a configuration control board (CCB). <br />
<br />
Interface agreements, specifications, and interface designs are usually documented through the interface control documents (ICD) and the interface design descriptions (IDD); in some instances, depending on the complexity of the product and the type of internal and/or external interfaces, an interface control working group (ICWG) is created to analyze and baseline changes to an interface for further recommendation to the CCB.<br />
<br />
A configuration item (CI) may be hardware (HWCI), software (CSCI), firmware, subsystems, assemblies, non-Development items, commercial off-the-shelf (COTS) items, acquirer furnished equipment, and/or processes. Please see Wasson (2006), Grady (2006), and INCOSE v. 3.1 for a more detailed description of configuration and interface control.<br />
<br />
A product may experience hundreds of changes during its life cycle due to new product releases/enhancements, repair/replacement of parts, upgrades/updates in operating systems, computer infrastructure, software modules, organizational changes, changes in processes and/or methods and procedures, etc. Thus, strong mechanisms for bookkeeping and activity control need to be in place to identify, control, audit, account and trace interfaces, interactions, and relationships between entities that are required to maintain product configuration status (Eisner 2008). The product configuration and CI’s are then controlled through the configuration management process.<br />
<br />
== Configuration Management (CM) & Risk Management (RM) ==<br />
<br />
Configuration management (CM) deals with the identification, control, auditing, status accounting, and traceability aspects of the product, and broadly covers the book-keeping and control activities of the systems engineering process (Eisner 2001). Any product configuration changes to the baseline (configuration item, operational baseline, functional baseline, behavior baseline) or product baseline are submitted to a configuration control board (CCB) through an engineering change request (ECR) and/or a configuration change request (CCR). The CCB then analyzes the request to understand CI impacts and the feasibility (time and cost) of authorization or rejection of change request(s). The lack of proper control and tracking of CI and product baselines may result in a loss of features, functionality, data, interfaces, etc., leading to backtracking and CI version losses which may affect the offered product. All approved changes will have to be baselined, documented, and tested for backward compatibility and to ensure compliance with the integrated product functionality. Thus, successful implementation and life cycle management of the product mandates a highly disciplined CM process that maintains proper control over the product and its components. Please see the INCOSE Systems Engineering Handbook v. 3.1 for a detailed description of the CM Process.<br />
<br />
Risk management deals with the identification, assessment, and prioritization of technical, cost, schedule, and programmatic risks in any system. Almost all engineered systems are designed, constructed, and operated under some level of risks and uncertainty while achieving multiple, and often conflicting, objectives. As greater complexities and new technologies are introduced in modern systems, the potential of risks have significantly increased. Thus, the overall managerial decision-making process should involve an extensive cost-benefit analysis of all identified, qualified, and evaluated risks (Haimes 2008). Risk management involves the coordinated and most cost-effective application of resources to minimize, monitor, and control the probability and/or impact of all identified risks within the systems engineering process (http://en.wikipedia.org/wiki/Risk_management). The risk management process requires the involvement of several disciplines and encompasses empirical, quantitative, and normative judgmental aspects of decision-making. Furthermore, risk assessment and management should be integrated and incorporated within the broader holistic approach so technology management can help align the risk management requirements to the overall systems engineering requirements. Thus, the inclusion of a well defined risk management plan that deals with the analysis of risks, within the systems engineering master plan is vital for the long term and sustained success of any system (Blanchard and Fabrycky 2011).<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Anachino, M. 2003. ''New Product Development: From Initial Idea to Product Management''. Elsevier. <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 />
Eisner, H. 2008. ''Essentials of Project and Systems Engineering Management'', 3rd edition. New York, NY, USA: John Wiley & Sons. <br />
<br />
Grady, J. 2006. ''System Requirements Analysis''. Elsevier. <br />
<br />
Haimes, Y. 2008. ''Risk Modeling, Assessment, and Management,'' 3rd edition. New York, NY, USA: John Wiley & Sons. <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 />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications. Kings College, UK.<br />
<br />
Morse, L. and D. Babcock. 2007. ''Managing Engineering and Technology''. International Series in Industrial and Systems Engineering. Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Phillips, F. 2001. ''Market Oriented Technology Management: Innovating for Profit in Entrepreneurial Times''. New York, NY, USA: Springer.<br />
<br />
Wasson, C. S. 2006. ''System Analysis, Design, and Development''. Hoboken, NJ, USA: John Wiley & Sons. <br />
<br />
Rogers, E. M. 2003. Diffusion of innovations (5th ed.). New York, NY: Free Press.<br />
<br />
Pugh, S. 1990. Total Design: Integrated Methods for Successful Product Engineering. Prentice Hall. ISBN-10: 0201416395, ISBN-13: 978-0201416398.<br />
<br />
Smith, P. and Reinertsen, D. 1997. Developing products in half the time – new rules, new tools. John Wiley and Sons. 2nd edition. ISBN-10: 0471292524, ISBN-13: 978-0471292524 <br />
<br />
Reinertsen, D. 1997. Managing the Design Factory: A Product Developers Tool Kit. Simon & Shuster Ltd. ISBN-10: 0684839911 ISBN-13: 978-0684839912<br />
<br />
US Army, Chapter 2, section A.4 of Army Science and Technology Master Plan. dowloaded from http://www.fas.org/man/dod-101/army/docs/astmp/c2/P2A4.htm, accessed on 12 Jan 2012<br />
<br />
Kass, R. 2006. The logic of warfighting experiments. DOD CCRP – downloaded from http://www.dodccrp.org/files/Kass_Logic.pdf, 12Jan 2012<br />
<br />
===Primary References===<br />
No primary references have been identified for version 0.75. Please provide any recommendations on primary references in your review.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
<center>[[Business Activities Related to Product Systems Engineering|< Previous Article]] | [[Product Systems Engineering|Parent Article]] | [[Product Systems Engineering Special Activities|Next Article >]]</center><br />
<br />
=Comments from 0.5 Wiki=<br />
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments.<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Product Systems Engineering]]</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=36403
Enterprise Systems Engineering Key Concepts
2012-07-23T05:05:03Z
<p>Jgercken: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
The purpose of traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(TSE)]] is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]] “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] ([[Acronyms|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 [[Element (glossary)|elements]] of the organization’s [[business (glossary)|business]] strategy” (Carlock and Fenton 2001, 242-261). The traditional role of systems engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[context (glossary)|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 />
The MITRE Corporation has done significant development of ESE practices.<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.” In addition to the TSE [[Process (glossary)]] areas, MITRE has included the following process areas in their ESE process (DeRosa 2005) to close the gap between ESE and product SE:<br />
*Strategic Technical Planning<br />
*Enterprise Architecture<br />
*[[Capability (glossary)|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.]]<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)]] 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)]]. Outcome spaces are characterized by a set of desired capabilities that help meet enterprise objectives, as opposed to definitive “user [[Requirement (glossary)|requirements]]” based on near-term needs. Enterprise capabilities must be [[Robustness (glossary)|robust]] enough to handle unknown [[Threat (glossary)|threats]] and situations in the future. A detailed description of previous MITRE views on ESE can be found in (Rebovich and White 2011).<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)]] 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 group 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 is provided by Reese (2010).<br />
<br />
[[File:ESE-F14.png|thumb|center|500px|Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities(Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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|1000px|Figure 3. Example of Enterprise Entities & Relationships (Troux 2010)Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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)]] for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (or 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 (glossary)]]. Some of these are described below.<br />
<br />
===TRAK Framework===<br />
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011). This framework was developed primarily for the rail industry in the United Kingdom but has been used in other domains as well.<br />
<br />
[[File:ESE-F16.png|thumb|center|800px|Figure 4.TRAK Metamodel (TRAK 2011) Released under the GNU Free Documentation License of Copyright (C) 2010 - 2011 UK Department for Transport. Source is available at http://trakmetamodel.sourceforge.net]]<br />
<br />
===DODAF Framework===<br />
The figure below shows the metamodel for the United States Department of Defense [[Acronyms|(DoD)]] Architecture framework (DoD 2010). "DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of 'operational views' detailing the external customer's operating domain in which the developing system will operate." (http://en.wikipedia.org/wiki/DODAF)<br />
<br />
A related framework is the Ministry of Defense (MOD) Architecture Framework (MODAF): "Initially the purpose of MODAF was to provide rigour and structure to support the definition and integration of MOD equipment capability, particularly in support of Network Enabled Capability (NEC). More recently, MOD has additionally been using MODAF to underpin the use of the Enterprise Architecture approach to the capture of the information about the business to identify the processes and resources required to deliver the vision expressed in the strategy." (http://en.wikipedia.org/wiki/Modaf)<br />
<br />
[[File:ESE-F17.png|thumb|600px|center|Figure 5. DoDAF Conceptual Data Model (DoD 2010) Released by the United States Department of Defense.]]<br />
<br />
===TOGAF Framework===<br />
Some frameworks (like The Open Group Architecture Framework [[Acronyms|(TOGAF)]]) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).<br />
<br />
[[File:ESE-F18.png|thumb|center|400px|Figure 6. TOGAF Methodology (TOGAF 2009 -Image credited to Marley NASA /SCI 2003) (Source: http://en.wikipedia.org/wiki/File:TOGAF_ADM.jpg) Accessed September 16, 2011. Released in the public domain from NASA.]]<br />
<br />
===Zachman Framework===<br />
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “[[Stakeholder (glossary)|stakeholder]] concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, [[Network (glossary)|networks]], people, time, and motivation. The rows represent the different stakeholder “perspectives”: [[Context (glossary)|contextual]] (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: [[scope (glossary)]] (i.e., contextual), business model, system model, technology model, and detailed representations.<br />
<br />
[[File:ESE-F19.png|thumb|600px|center|Figure 7. Zachman Framework (Zachmann 1992 –Image credited to Dekker and SunSw0rd) (Source: http://en.wikipedia.org/wiki/File:Zachman_Framework_Model.svg ) Accessed September 16, 2011. Released in the public domain by Wikimedia guidelines.]]<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 Journal 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 />
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, Richard 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 />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html 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 />
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 />
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 />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Enterprise_Systems_Engineering_Key_Concepts&diff=36402
Enterprise Systems Engineering Key Concepts
2012-07-23T05:04:28Z
<p>Jgercken: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
The purpose of traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(TSE)]] is to bring together a diversity of discipline experts to address a wide range of problems inherent in the development of a large, [[complex (glossary)]], “single” [[system (glossary)]] (Blanchard and Fabrycky 2010; Hall 1989; Sage and Rouse 2009). [[Enterprise Systems Engineering (ESE) (glossary)|Enterprise systems engineering]] ([[Acronyms|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 [[Element (glossary)|elements]] of the organization’s [[business (glossary)|business]] strategy” (Carlock and Fenton 2001, 242-261). The traditional role of systems engineering [[Acronyms|(SE)]] is heavily involved in system acquisition and implementation, especially in the [[context (glossary)|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 />
The MITRE Corporation has done significant development of ESE practices.<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.” In addition to the TSE [[Process (glossary)]] areas, MITRE has included the following process areas in their ESE process (DeRosa 2005) to close the gap between ESE and product SE:<br />
*Strategic Technical Planning<br />
*Enterprise Architecture<br />
*[[Capability (glossary)|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.]]<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)]] 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)]]. Outcome spaces are characterized by a set of desired capabilities that help meet enterprise objectives, as opposed to definitive “user [[Requirement (glossary)|requirements]]” based on near-term needs. Enterprise capabilities must be [[Robustness (glossary)|robust]] enough to handle unknown [[Threat (glossary)|threats]] and situations in the future. A detailed description of previous MITRE views on ESE can be found in (Rebovich and White 2011).<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)]] 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 group 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 is provided by Reese (2010).<br />
<br />
[[File:ESE-F14.png|thumb|center|500px|Figure 2. Asset Domain and Concept Domain Categories for Enterprise Entities(Troux 2010) Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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|1000px|Figure 3. Example of Enterprise Entities & Relationships (Troux 2010)Reprinted with permission of Copyright © 2010 Troux Technologies]]<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 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)]] for enterprise architecture activities. Other enterprise modeling tools have similar metamodels (or 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 (glossary)]]. Some of these are described below.<br />
<br />
===TRAK Framework===<br />
The “standard” entities and relationships used in architecture modeling of an enterprise are specified in metamodels and viewpoint specifications in various domain-specific architecture frameworks. The figure below, as one example, shows the metamodel for the TRAK architecture framework (TRAK 2011). This framework was developed primarily for the rail industry in the United Kingdom but has been used in other domains as well.<br />
<br />
[[File:ESE-F16.png|thumb|center|800px|Figure 4.TRAK Metamodel (TRAK 2011) Released under the GNU Free Documentation License of Copyright (C) 2010 - 2011 UK Department for Transport. Source is available at http://trakmetamodel.sourceforge.net]]<br />
<br />
===DODAF Framework===<br />
The figure below shows the metamodel for the United States Department of Defense [[Acronyms|(DoD)]] Architecture framework (DoD 2010). "DoDAF defines a set of views that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal or graphical means. It is especially suited to large systems with complex integration and interoperability challenges, and is apparently unique in its use of 'operational views' detailing the external customer's operating domain in which the developing system will operate." (http://en.wikipedia.org/wiki/DODAF)<br />
<br />
A related framework is the Ministry of Defense (MOD) Architecture Framework (MODAF): "Initially the purpose of MODAF was to provide rigour and structure to support the definition and integration of MOD equipment capability, particularly in support of Network Enabled Capability (NEC). More recently, MOD has additionally been using MODAF to underpin the use of the Enterprise Architecture approach to the capture of the information about the business to identify the processes and resources required to deliver the vision expressed in the strategy." (http://en.wikipedia.org/wiki/Modaf)<br />
<br />
[[File:ESE-F17.png|thumb|600px|center|Figure 5. DoDAF Conceptual Data Model (DoD 2010) Released by the United States Department of Defense.]]<br />
<br />
===TOGAF Framework===<br />
Some frameworks (like The Open Group Architecture Framework [[Acronyms|(TOGAF)]]) are more properly called methodologies since they focus on the process (see figure below) by which artifacts are created and how they are used. Other frameworks (like Zachman and CIO Council 1999) are more properly called taxonomies since they define and categorize the kinds of elements of interest to the enterprise analyst (Ref: A Comparison of the Top Four Enterprise-Architecture Methodologies, http://msdn.microsoft.com/en-us/library/bb466232.aspx).<br />
<br />
[[File:ESE-F18.png|thumb|center|400px|Figure 6. TOGAF Methodology (TOGAF 2009 -Image credited to Marley NASA /SCI 2003) (Source: http://en.wikipedia.org/wiki/File:TOGAF_ADM.jpg) Accessed September 16, 2011. Released in the public domain from NASA.]]<br />
<br />
===Zachman Framework===<br />
The figure below shows the Zachman architecture framework (taxonomy) (Zachman 1987 and 1992). The columns represent the six “interrogatives” of why, how, what, who, where, and when, and these can be considered to be “[[Stakeholder (glossary)|stakeholder]] concerns” of the enterprise stakeholders. These columns also represent data (i.e., the “what”), functions, [[Network (glossary)|networks]], people, time, and motivation. The rows represent the different stakeholder “perspectives”: [[Context (glossary)|contextual]] (planners), conceptual (owners), logical (designers), physical (builders), and detailed (subcontractors or suppliers). These rows also represent the following “perspectives”: [[scope (glossary)]] (i.e., contextual), business model, system model, technology model, and detailed representations.<br />
<br />
[[File:ESE-F19.png|thumb|600px|center|Figure 7. Zachman Framework (Zachmann 1992 –Image credited to Dekker and SunSw0rd) (Source: http://en.wikipedia.org/wiki/File:Zachman_Framework_Model.svg ) Accessed September 16, 2011. Released in the public domain by Wikimedia guidelines.]]<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 Journal 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 />
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, Richard 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 />
TRAK. 2011. "TRAK Enterprise Architecture Framework." http://trak.sourceforge.net/index.html 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 />
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 />
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 />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
[[Category: Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Systems_Engineering_Implementation_Examples&diff=36401
Systems Engineering Implementation Examples
2012-07-23T04:57:20Z
<p>Jgercken: </p>
<hr />
<div>To illustrate the principles described in the [[SEBoK Table of Contents|Systems Engineering Body of Knowledge (SEBoK) Parts 1-6]], Part 7 is a collection of systems engineering (SE) implementation examples. These examples describe the application of SE practices, principles, and concepts in real settings. The intent is to provide typical instances of the application of SE so readers can learn from these experiences. This can improve the practice of SE by illustrating to students and practitioners the benefits of effective practice, as well as the risks and liabilities of poor practice.<br />
<br />
A [[Matrix of Implementation Examples|matrix of implementation examples]] is used to map the implementation examples to topics in the [[SEBoK Table of Contents|SEBoK]]. To provide a broader set of domains, both formal [[Case Study (glossary)|case studies]] and shorter [[Vignette (glossary)|vignettes]] are used. For the case studies, an introduction and analysis of the case is given with references to the full external case study. For the vignettes, the implementation example is described directly. In the SE literature, a wide variety of examples and formats are considered "case studies." Here, the distinction between a case study and a vignette is that a vignette is a short wiki article written for the BKCASE project and a case study exists externally in the SE literature.<br />
<br />
An initial set of examples is included with the anticipation that more will be added over time to highlight the different aspects and applications of SE. In addition, new examples can be added to demonstrate the evolving state of practice, such as the application of model-based SE and the engineering of complex, adaptive systems.<br />
<br />
To download a PDF of Part 7, please [http://www.sebokwiki.org/075/images/6/6f/SEBoK075_Part7.pdf click here].<br />
<br />
==Knowledge Areas in Part 7==<br />
Part 7 is organized into the following:<br />
*[[Matrix of Implementation Examples]]<br />
*[[Case Studies]]<br />
*[[Vignettes]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
None.<br />
<br />
===Primary References===<br />
No primary references have been identified for version 0.75. Please provide any recommendations on primary references in your review.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
----<br />
<center>[[Environmental Engineering|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Matrix of Implementation Examples|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 7]][[Category:Part]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Systems_Engineering_Implementation_Examples&diff=36400
Systems Engineering Implementation Examples
2012-07-23T04:52:15Z
<p>Jgercken: </p>
<hr />
<div>To illustrate the principles described in the [[SEBoK Table of Contents|Systems Engineering Body of Knowledge (SEBoK) Parts 1-6]], Part 7 is a collection of systems engineering (SE) implementation examples. These examples describe the application of systems engineering practices, principles, and concepts in real settings. The intent is to provide typical instances of the application of systems engineering so readers can learn from these experiences. This can improve the practice of systems engineering by illustrating to students and practitioners the benefits of effective practice, as well as the risks and liabilities of poor practice.<br />
<br />
A [[Matrix of Implementation Examples]] is used to map the implementation examples to topics in the [[SEBoK Table of Contents|SEBoK]]. To provide a broader set of domains, both formal [[Case Study (glossary)|Case Studies (glossary)]] and shorter [[Vignette (glossary)|Vignettes (glossary)]] are used. For the case studies, an introduction and analysis of the case is given, with references to the full external case study. For the vignettes, the implementation example is described directly. In the literature, a wide variety of examples and formats are considered "case studies." Here, the distinction between a case study and a vignette is that a vignette is a short wiki article written for the BKCASE project and a case study exists externally in the literature.<br />
<br />
An initial set of examples is included, anticipating that more will be added over time to highlight the different aspects and applications of systems engineering. In addition, new examples can be added to demonstrate the evolving state of practice, such as the application of model-based systems engineering and the engineering of complex, adaptive systems.<br />
<br />
To download a PDF of Part 7, please [http://www.sebokwiki.org/075/images/6/6f/SEBoK075_Part7.pdf click here].<br />
<br />
==Knowledge Areas in Part 7==<br />
Part 7 is organized into the following:<br />
*[[Matrix of Implementation Examples]]<br />
*[[Case Studies]]<br />
*[[Vignettes]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
None.<br />
<br />
===Primary References===<br />
No primary references have been identified for version 0.75. Please provide any recommendations on primary references in your review.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
<br />
----<br />
<center>[[Environmental Engineering|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Matrix of Implementation Examples|Next Article >]]</center><br />
<br />
{{5comments}}<br />
<br />
[[Category: Part 7]][[Category:Part]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36399
Related Business Activities
2012-07-23T04:46:40Z
<p>Jgercken: /* Multi-Level Enterprises */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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 actvities. 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 />
<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 recognising 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 [[Acronyms|(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.]]<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.]]<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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36398
Related Business Activities
2012-07-23T04:42:23Z
<p>Jgercken: /* Enterprise Governance */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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 actvities. 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 />
<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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36397
Related Business Activities
2012-07-23T04:40:14Z
<p>Jgercken: /* Program and Project Management */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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 actvities. 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36396
Related Business Activities
2012-07-23T04:39:17Z
<p>Jgercken: /* Program and Project Management */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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 actvities. 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36395
Related Business Activities
2012-07-23T04:36:16Z
<p>Jgercken: /* Resource Allocation and Budgeting */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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 actvities. 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)]] 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)]] 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 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36394
Related Business Activities
2012-07-23T04:33:05Z
<p>Jgercken: /* Portfolio Management */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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)]] 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 & Information Management and the Performance Management actvities. 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)]] 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)]] 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 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36393
Related Business Activities
2012-07-23T04:29:06Z
<p>Jgercken: /* Business Management Cycles */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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)]]. 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 Enterprise SE is well addressed in this 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)]] 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 & Information Management and the Performance Management actvities. 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)]] 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)]] 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 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36392
Related Business Activities
2012-07-23T04:26:54Z
<p>Jgercken: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<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.]]<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 to Perform Systems Engineering]]. 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 />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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)]]. 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 Enterprise SE is well addressed in this 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)]] 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 & Information Management and the Performance Management actvities. 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)]] 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)]] 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 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Related_Business_Activities&diff=36391
Related Business Activities
2012-07-23T03:53:50Z
<p>Jgercken: /* Introduction */</p>
<hr />
<div>==Introduction==<br />
The following [[business (glossary)]] management activities can be supported by [[Enterprise Systems Engineering (ESE) (glossary)|enterprise systems engineering]] [[Acronyms|(ESE)]] activities:<br />
*mission and strategic planning<br />
*business processes and information Management<br />
*performance management<br />
*portfolio management<br />
*resource allocation and budgeting<br />
*program and project management<br />
<br />
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product SE (Martin 2010 and 2011). Product SE is mainly involved at the project level and collaborates with Project Management activities, and gets somewhat involved in Program Management and the Resource Allocation & Budgeting activities. On the other hand, ESE is heavily involves in the higher level activities from the Program Management level and up. Both ESE and Product SE 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.]]<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. Traditional Systems Engineering [[Acronyms|(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 (glossary)]] 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 to Perform Systems Engineering]]. The other business management activities are described in more detail below in how they relate to ESE.<br />
<br />
==Business Management Cycles==<br />
[[Acronyms|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 replanning 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 [[Acronyms|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 a term used to describe 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 honouring 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]] ([[Acronyms|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]] ([[Acronyms|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)]]. 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 Enterprise SE is well addressed in this 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)]] 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 & Information Management and the Performance Management actvities. 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)]] 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)]] 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 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 />
<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 both to ‘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 recognising 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 [[Acronyms|(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 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.]]<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.]]<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 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 15288. 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 />
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 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 />
===Additional References===<br />
<br />
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." ''Systems Engineering, the Journal of the International Council on 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, the Journal of the International Council on Systems Engineering (INCOSE) 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 />
{{5comments}}<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Enterprise Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36390
Service Systems Engineering Stages
2012-07-23T03:50:14Z
<p>Jgercken: /* Service Systems Engineering Tools & Technologies */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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<br />
*access management<br />
<br />
A continuous service improvement [[Acronyms|(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 [[Acronyms|(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 (glossary)|business process]] execution language [[Acronyms|(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 [[Acronyms|(AF)]] and enterprise architectures [[Acronyms|(EA)]] 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 [[Acronyms|(UML)]] and system modeling language [[Acronyms|(SysML)]], help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service oriented architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural 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]] [[Acronyms|(MBSE)]], model driven architectures [[Acronyms|(MDA)]], and model oriented systems engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational), and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0, and [[Acronyms|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 [[Acronyms|(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 [[Acronyms|(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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36389
Service Systems Engineering Stages
2012-07-23T03:49:31Z
<p>Jgercken: /* Service Systems Engineering Tools & Technologies */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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<br />
*access management<br />
<br />
A continuous service improvement [[Acronyms|(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 [[Acronyms|(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 (glossary)|business process]] execution language [[Acronyms|(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 [[Acronyms|(AF)]] and enterprise architectures [[Acronyms|(EA)]] 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 [[Acronyms|(UML)]] and system modeling language [[Acronyms|(SysML)]], help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service oriented architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural 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]] [[Acronyms|(MBSE)]], model driven architectures [[Acronyms|(MDA)]], and model oriented systems engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational), and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 [[Acronyms|(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 [[Acronyms|(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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36388
Service Systems Engineering Stages
2012-07-23T03:47:29Z
<p>Jgercken: /* Service Systems Engineering Tools & Technologies */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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<br />
*access management<br />
<br />
A continuous service improvement [[Acronyms|(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 [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 [[Acronyms|(AF)]] and enterprise architectures [[Acronyms|(EA)]] 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 [[Acronyms|(UML)]] and system modeling language [[Acronyms|(SysML)]], help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service oriented architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural 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]] [[Acronyms|(MBSE)]], model driven architectures [[Acronyms|(MDA)]], and model oriented systems engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational), and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 [[Acronyms|(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 [[Acronyms|(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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36387
Service Systems Engineering Stages
2012-07-23T02:38:26Z
<p>Jgercken: /* Service Systems Engineering Tools & Technologies */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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<br />
*access management<br />
<br />
A continuous service improvement [[Acronyms|(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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36386
Service Systems Engineering Stages
2012-07-23T02:32:13Z
<p>Jgercken: /* Service Systems Engineering Tools & Technologies */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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<br />
*access management<br />
<br />
A continuous service improvement [[Acronyms|(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)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36385
Service Systems Engineering Stages
2012-07-23T02:29:42Z
<p>Jgercken: /* Service Operations/ Continuous Service Improvement (CSI) */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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<br />
*access management<br />
<br />
A continuous service improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36384
Service Systems Engineering Stages
2012-07-23T02:28:01Z
<p>Jgercken: /* Service Transition/Deployment */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36383
Service Systems Engineering Stages
2012-07-23T02:25:24Z
<p>Jgercken: /* Systems Design/Development */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*service level management <br />
*[[Capacity (glossary)|capacity]] management<br />
*availability management<br />
*service continuity management<br />
*security management<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]] [[Acronyms|(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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36382
Service Systems Engineering Stages
2012-07-23T02:24:54Z
<p>Jgercken: /* Service Integration, Verification & Validation */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*Service level management <br />
*[[Capacity (glossary)|Capacity]] management<br />
*Availability management<br />
*Service continuity management<br />
*Security management<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]] [[Acronyms|(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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36381
Service Systems Engineering Stages
2012-07-23T02:21:05Z
<p>Jgercken: /* Systems Design/Development */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(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 architectural 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 catalogue management<br />
*Service level management <br />
*[[Capacity (glossary)|Capacity]] management<br />
*Availability management<br />
*Service continuity management<br />
*Security management<br />
*Supplier/provider management<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)]] 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)]] [[Acronyms|(IV&V)]] plans need to include end-to-end [[Verification (glossary)]] and [[Validation (glossary)]] 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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36380
Service Systems Engineering Stages
2012-07-23T02:17:02Z
<p>Jgercken: /* Requirements Analysis and Engineering */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms| (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 [[Acronyms|(KPIs)]], [[Technical Performance Measure (TPM) (glossary)|technical performance measures]] [[Acronyms|(TPMs)]], and service performance measures [[Acronyms|(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 [[Acronyms|(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 [[Plan (glossary)|plans]] [[Acronyms|(SOPs)]] and the operations technical plans [[Acronyms|(OTPs)]].<br />
<br />
==Systems Design/Development==<br />
<br />
The SRD, SOP and OTP have enough details about the service functions, operations, interfaces and information flows required among the different service system entities to analyze, identify and recommend end-to-end applicable architectural frameworks, to carry out trade-off analyses for the alternatives among service system entities, to describe and allocate relationships (interactions) among entities, and 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 V3 (OGC 2009) recommends inclusion of the following Service Design Processes:<br />
<br />
*Service Catalogue Management<br />
*Service Level Management <br />
*[[Capacity (glossary)|Capacity]] Management<br />
*Availability Management<br />
*Service Continuity Management<br />
*Security Management<br />
*Supplier/Provider Management<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)]] 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)]] [[Acronyms|(IV&V)]] plans need to include end-to-end [[Verification (glossary)]] and [[Validation (glossary)]] 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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36379
Service Systems Engineering Stages
2012-07-23T02:12:12Z
<p>Jgercken: /* Service Strategy/Concept */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 describing 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 [[Acronyms|(SLA)]] 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 [[Acronyms| (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 [[Acronyms|(KPI)]]s, [[Technical Performance Measure (TPM) (glossary)|Technical Performance Measures]] [[Acronyms|(TPM)]]s, and Service Performance Measures [[Acronyms|(SPM)]]s according to intended 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 [[Acronyms|(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 [[Plan (glossary)|Plans]] [[Acronyms|(SOP)]] and the Operations Technical Plans [[Acronyms|(OTP)]].<br />
<br />
==Systems Design/Development==<br />
<br />
The SRD, SOP and OTP have enough details about the service functions, operations, interfaces and information flows required among the different service system entities to analyze, identify and recommend end-to-end applicable architectural frameworks, to carry out trade-off analyses for the alternatives among service system entities, to describe and allocate relationships (interactions) among entities, and 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 V3 (OGC 2009) recommends inclusion of the following Service Design Processes:<br />
<br />
*Service Catalogue Management<br />
*Service Level Management <br />
*[[Capacity (glossary)|Capacity]] Management<br />
*Availability Management<br />
*Service Continuity Management<br />
*Security Management<br />
*Supplier/Provider Management<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)]] 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)]] [[Acronyms|(IV&V)]] plans need to include end-to-end [[Verification (glossary)]] and [[Validation (glossary)]] 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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36378
Service Systems Engineering Stages
2012-07-23T02:10:09Z
<p>Jgercken: /* Service Strategy/Concept */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 describing 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 [[Acronyms|(SLA)]] 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 [[Acronyms| (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 [[Acronyms|(KPI)]]s, [[Technical Performance Measure (TPM) (glossary)|Technical Performance Measures]] [[Acronyms|(TPM)]]s, and Service Performance Measures [[Acronyms|(SPM)]]s according to intended 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 [[Acronyms|(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 [[Plan (glossary)|Plans]] [[Acronyms|(SOP)]] and the Operations Technical Plans [[Acronyms|(OTP)]].<br />
<br />
==Systems Design/Development==<br />
<br />
The SRD, SOP and OTP have enough details about the service functions, operations, interfaces and information flows required among the different service system entities to analyze, identify and recommend end-to-end applicable architectural frameworks, to carry out trade-off analyses for the alternatives among service system entities, to describe and allocate relationships (interactions) among entities, and 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 V3 (OGC 2009) recommends inclusion of the following Service Design Processes:<br />
<br />
*Service Catalogue Management<br />
*Service Level Management <br />
*[[Capacity (glossary)|Capacity]] Management<br />
*Availability Management<br />
*Service Continuity Management<br />
*Security Management<br />
*Supplier/Provider Management<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)]] 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)]] [[Acronyms|(IV&V)]] plans need to include end-to-end [[Verification (glossary)]] and [[Validation (glossary)]] 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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken
https://sebokwiki.org/w/index.php?title=Service_Systems_Engineering_Stages&diff=36377
Service Systems Engineering Stages
2012-07-23T02:09:27Z
<p>Jgercken: /* Service Strategy/Concept */</p>
<hr />
<div>This article describes the stages of the [[Service System (glossary)|service systems]] development [[Process (glossary)|process]] [[Acronyms|(SSDP)]] and expected outputs for each stage; for a closer alignment with the traditional [[Systems Engineering (glossary)|systems engineering]] [[Acronyms|(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]] [[Acronyms|(IT)]], and technology impacts and [[customer (glossary)]] expectations. The Information Technology Infrastructure Library [[Acronyms|(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 />
[[File:SSE_SDP_Fig2.png|thumb|center|600px|Figure 1. Converting [[Business (glossary)|business]] [[Requirement (glossary)|requirements]] into New Services (Adams et al., pg. 44) © Crown copyright 2012 All rights reserved. Material is reproduced with the permission of the Cabinet Office under delegated authority from the Controller of HMSO]]<br />
<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 [[Acronyms|(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 [[Acronyms|(OSS)]], service support systems [[Acronyms|(SSS)]], and business support systems [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 [[Acronyms|(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 describing 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 [[Acronyms|(SLA)]] 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 [[Acronyms| (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 [[Acronyms|(KPI)]]s, [[Technical Performance Measure (TPM) (glossary)|Technical Performance Measures]] [[Acronyms|(TPM)]]s, and Service Performance Measures [[Acronyms|(SPM)]]s according to intended 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 [[Acronyms|(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 [[Plan (glossary)|Plans]] [[Acronyms|(SOP)]] and the Operations Technical Plans [[Acronyms|(OTP)]].<br />
<br />
==Systems Design/Development==<br />
<br />
The SRD, SOP and OTP have enough details about the service functions, operations, interfaces and information flows required among the different service system entities to analyze, identify and recommend end-to-end applicable architectural frameworks, to carry out trade-off analyses for the alternatives among service system entities, to describe and allocate relationships (interactions) among entities, and 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 V3 (OGC 2009) recommends inclusion of the following Service Design Processes:<br />
<br />
*Service Catalogue Management<br />
*Service Level Management <br />
*[[Capacity (glossary)|Capacity]] Management<br />
*Availability Management<br />
*Service Continuity Management<br />
*Security Management<br />
*Supplier/Provider Management<br />
<br />
==Service Integration, Verification & Validation==<br />
<br />
SSE defines [[Integration (glossary)]] 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)]] [[Acronyms|(IV&V)]] plans need to include end-to-end [[Verification (glossary)]] and [[Validation (glossary)]] 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)<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 V3 (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<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 V3 are:<br />
<br />
*Event Management<br />
*Incident Management<br />
*Problem Management<br />
*Request Fulfillment<br />
*Access Management<br />
<br />
A Continuous Service Improvement [[Acronyms|(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 modeling, definition, and [[Design (glossary)]] of the organization, processes and data structures of the service system (See also [[Representing Systems with Models]]). These tools and technologies include: Modeling, [[Simulation (glossary)]], 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'''<br />
*'''Service Design Management'''<br />
<br />
'''Business Process Management (BPM)''': 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 in the alignment of the business [[Architecture (glossary)|architectures]] with the technology and IT architecture. The business process modeling notation [[Acronyms|(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 (glossary)]] Execution Language [[Acronyms|(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 the reader is referred to (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 [[Acronyms|(AF)]] and Enterprise Architectures [[Acronyms|(EA)]] are [[Systems Engineering Standards|standards]] that help split [[Complex (glossary)]] systems (see also [[Complexity]]) into an interrelated, structured form. They describe the different characteristics of the [[Product (glossary)]] and services. System engineering modeling tools such as the Unified Modeling Language [[Acronyms|(UML)]] and System Modeling Language [[Acronyms|(SysML)]] help develop the AF and EA and greatly impact the continued evolution and successful implementation of complex projects. Service Oriented Architecture [[Acronyms|(SOA)]] and software-intensive systems architecture (IEEE P1471) are standards that apply architecture principles for specialised applications. Successful implementation of the architectural tools help identify critical interfaces and understand the allocations between components and functions. <br />
<br />
[[Model-Based Systems Engineering (MBSE) (glossary)]] [[Acronyms|(MBSE)]], Model Driven Architectures [[Acronyms|(MDA)]], and Model Oriented Systems Engineering [[Acronyms|(MOSES)]] are examples of commonly used tools for logical (functional), behavioral (operational) and physical design of the [[Information Technology (glossary)|IT (glossary)]]. [[Acronyms|UML]], [[Acronyms|UML]] 2.0 and [[Acronyms|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 the reader is referred to (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, 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 [[Acronyms|(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 [[Acronyms|(PDCA))]] is widely used as the foundation for [[Quality (glossary)]] improvements across the service. [[Lean Systems Engineering (LSE) (glossary)|Lean]] Manufacturing, [[Six Sigma (glossary)]], swim lanes, balanced scoreboard, benchmarking, 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) 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) and product quality (ISO/IEC 9126), as well as information security management (ISO 27001) and evaluation (ISO 15408). The ITIL V3 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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
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 />
AT&T SRP. 2008. [[Technical Approach to Service Delivery]]. General Services Administration, AT&T Bridge Contract No. GS00Q09NSD0003, http://www.corp.att.com/gov/contracts/fts_bridge/technical/07_vol_I_section_1.pdf. accessed on June 1st 2011.<br />
<br />
Daskin, M.S. 2010. ''[[Service Science]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-0-470-52588-3.<br />
<br />
Erl, T. 2008. "[[SOA Principles of Service Design]]." Boston, MA, USA: Prentice Hall Pearson Education. ISBN 978-0-13234-482-1.<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 />
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 />
OGC (Office of Government Commerce). 2009. ''"[[ITIL Lifecycle Publication Suite Books]]."'' London, UK: The Stationery Office. ISBN 978-0-11331-050-0.<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 />
Luzeaux, D. and J.R. Ruault (eds.). 2010. ''[[Systems of Systems]].'' New York, NY, USA: John Wiley & Sons. ISBN 978-1-84821-164-3.<br />
<br />
===Additional References===<br />
No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.<br />
----<br />
<center>[[Value of Service Systems Engineering|< Previous Article]] | [[Service Systems Engineering|Parent Article]] | [[Enterprise Systems Engineering|Next Article >]]</center><br />
<br />
==Comments from SEBok 0.5 Wiki==<br />
No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.<br />
<br />
<br />
[[Category:Part 4]][[Category:Topic]]<br />
[[Category:Service Systems Engineering]]<br />
{{DISQUS}}</div>
Jgercken