Difference between revisions of "Engineered System Context"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(85 intermediate revisions by 12 users not shown)
Line 1: Line 1:
==Engineered Systems==
+
----
 +
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Brian Wells, Scott Jackson, James Martin''
 +
----
 +
[[File:PPI.png|thumb|250px|right|<center>The "Systems Approach Applied to Engineered Systems" knowledge area is graciously sponsored by PPI.<center>]]
 +
This article is part of the [[Systems Approach Applied to Engineered Systems]] knowledge area (KA). It describes knowledge related to the further expansion of the ideas of an {{Term|Engineered System (glossary)|engineered system}} and engineered system {{Term|System Context (glossary)|context}} that were introduced in the [[Systems Fundamentals]] KA.
 +
 +
The single most important principle of the {{Term|Systems Approach (glossary)|systems approach}} is that it is applied to an engineered system context and not just to a single system (INCOSE 2012). The systems approach includes models and activities useful for the understanding, creation, use, and sustainment of engineered systems to enable the realization of stakeholder needs. Disciplines that use a systems approach (like {{Term|Systems Engineering (glossary)|systems engineering}} (SE)) consider an engineered system context that defines stakeholder needs, and look for the best ways to provide value by applying managed technical activities to one or more selected engineered {{Term|System-of-Interest (glossary)|systems of interest}} (SoI).
  
The ideas of both an [[Engineered System (glossary)]] and a [[Systems Context (glossary)]] are discussed in the [[Systems Thinking]] Knowledge Area.
+
Generally, four specific types of engineered system contexts are recognized in SE:
+
* {{Term|Product System (glossary)|product system}}
The single most important principle of the systems approach is that it is applied to an Engineered System Context and not to a single system (INCOSE 2011).  The [[Systems Approach (glossary)]] includes models and activities useful in the understanding, creation, use and sustainment of Engineered Systems to enable the realisation of stakeholder needs.  Disciplines which use a systems approach (such as Systems Engineering) consider an Engineered System Context in which stakeholder need is defined; and look for ways to best provide that value by applying managed technical activities to  one or more selected Engineered [[System of Interest (SoI) (glossary)]].
+
* {{Term|Service System (glossary)|service system}}
 +
* {{Term|Enterprise System (glossary)|enterprise system}}
 +
* {{Term|System of Systems (SoS) (glossary)|system of systems (SoS) capability}}
  
Three specific types of engineered system context are generally recognized in systems engineering: [[Product System (glossary)]], [[Service System (glossary)]] and [[Enterprise System (glossary)]].  One of the key distinctions between product, service, and enterprise systems engineering is how widely the SoI boundary is drawn.
+
One of the key distinctions between these system contexts pertains to the establishment of how and when the SoI boundary is drawn.
  
==Engineered System Context==
+
==Engineered System-of-Interest==
We use the idea of an Engineered System Context to define an engineered system of interest, and to capture and agree on the important relationships between it; the systems it works directly with and the systems which influence it in some way. All application of a systems approach (and hence of systems engineering) are applied to a system context, and not to an individual system.  
+
We use the idea of an engineered system context to define an engineered SoI and to capture and agree on the important relationships between it, the systems with which it works directly, and any other systems with which it works. All applications of a systems approach (and hence of SE) are applied in a system context rather than only to an individual system.  
  
A system contexts can be constructed around the following set of open system relationships (Flood and Carson 1993):
+
A system context can be constructed around the following set of open system relationships (Flood and Carson 1993):
*The '''Narrower System of Interest''' (NSoI) is the system of direct concern to the observer. The focus of this system is driven by the scope of authority or control, recognizing that this may not capture all related elements.  
+
* The '''Narrower System-of-Interest''' (NSoI) is the system of direct concern to the observer. The focus of this system is driven by the scope of authority or control with implicit recognition that this scope may not capture all related elements.  
*The '''Wider System of Interest''' (WSoI) describes a logical system boundary, containing all elements needed to fully understand system behavior. The observer may not have authority over all elements in the WSoI, but will be able to agree the relationships between WSoI elements and NSoI elements.
+
*The '''Wider System-of-Interest''' (WSoI) describes a logical system boundary containing all of the elements needed to fully understand system behavior. The observer may not have authority over all of the elements in the WSoI but will be able to establish the relationships between WSoI elements and NSoI elements.
*The WSoI sits in an '''Environment'''. The immediate environment contains engineered, natural or social system with which the WSoI (and thus some elements of the NSoI) directly interact, exchanging material, information and/or energy to achieve its Goals or Objective.
+
*The WSoI exists in an '''environment'''. The immediate environment contains engineered, natural, and/or social systems, with which the WSoI (and thus some elements of the NSoI) directly interact for the purpose of exchanging material, information, and/or energy to achieve its goals or objective.
*A '''Wider Environment''' completes the context, containing systems which have no direct interaction with the SoI, but which might influence decisions related to it during its life.
+
*A '''Wider Environment''' completes the context and contains systems that have no direct interaction with the SoI, but which might influence decisions related to it during its life cycle.
*(Flood 1987) extends the context to include a '''Meta-System''' (MS), which sits outside of the WSoI and exercises direct control over it.   
+
*"Some Theoretical Considerations of Mathematical Modeling" (Flood 1987) extends this context to include a '''meta-system''' (MS) that exists outside of the WSoI and exercises direct control over it.   
  
The choice of the System of Interest SoI boundary for particular activities depends upon what can be changed and what must remain fixed. The SoI will always include one or more NSoI but may also include WSoI and MS if appropriate; such as when considering a Service or Enterprise System.
+
The choice of the SoI boundary for particular activities depends upon what can be changed and what must remain fixed. The SoI will always include one or more NSoI but may also include WSoI and an MS if appropriate, such as when considering a service or an enterprise system.
How is system context applied to different kinds of engineered system problems?
 
  
For lower level, less complex, systems the WSoI can represent levels of [[Product System (glossary)]] hierarchy; e.g. an engine management unit as part of an engine; an engine as part of a car.
+
==Applying the System Context==
  
The WSoI in a system context may encapsulate some aspects of [[System of Systems (SoS) (glossary)|System of Systems (glossary)]] ideas, for sufficiently [[Complexity (glossary)|Complex (glossary)]] systems. In these cases the WSoI represents a collection of system with their own objectives and ownership, with which our NSoI must cooperate with towards a shared goal, e.g. a car and driver contributing to a transport [[Service (glossary)]].  
+
For lower-level and less-complex systems, the WSoI can represent levels of a {{Term|Product System (glossary)|product system}} hierarchy. An example of this would be an engine management unit as part of an engine, or an engine as part of a car. The WSoI in a system context may encapsulate some aspects of SoS ideas for sufficiently {{Term|Complexity (glossary)|complex}} systems. In these cases, the WSoI represents a collection of systems with their own objectives and ownership with which the NSoI must cooperate in working towards a shared goal. An example of this would be a car and a driver contributing to a transportation service.
  
This view of a system of systems context as a means to support the engineering of a NSoI [[Product System (glossary)]] is one way in which a systems approach can be applied.  We can also apply it directly to the system of systems, e.g. a flexible, multi vehicle transport service, or transport as part of a commercial retail [[Enterprise (glossary)]]. In this case the NSoI aspect of the context no longer applies. The WSoI will consist of a set of cooperating systems, each of which might be changed or replaced to synthesis a solution. The context may also need to represent '''loose coupling''', with some systems moving in or out of the context depending on the need; or '''late binding''' with systems joining the context only at or close to delivery of the service.   
+
This view of a SoS context being used as a means to support the engineering of an NSoI product system is one way in which a systems approach can be applied.  It can also be applied directly to the SoS. Examples of this include a flexible multi-vehicle transportation service or transportation as part of a commercial enterprise. In this case, the NSoI aspect of the context no longer applies. The WSoI will consist of a set of cooperating systems, each of which might be changed or replaced to aid in the synthesis of a solution. The context may also need to represent '''loose coupling''', with some systems moving in or out of the context depending on the need, or '''late binding''' with systems joining the context only at, or close to, the delivery of the service.   
  
Thus, a context allows an observer to take a reductionist view of the SoI he/she has direct concern for and authority over, while providing the system relationships and influences needed to enable them to keep a [[Holistic (glossary)]] view of the consequence of any actions they take.
+
Thus, a context allows a reductionist view of the SoI that is of direct concern to an observer, as it provides for the system relationships and influences that are needed to maintain a {{Term|Holistic (glossary)|holistic}} view of the consequence of any actions taken.
  
==Product System Contexts==
+
==Product System Context==
  
The distinction between [[Product (glossary)]] and a [[Product System (glossary)|Product System (glossary)]] is discussed in [[Types of Systems]].   
+
The distinction between a {{Term|Product (glossary)|product}} and a {{Term|Product System (glossary)|product system}} is discussed in the article [[Types of Systems]].   
 
   
 
   
A product [[System Context (glossary)]] would be one in which the [[System of Interest (SoI) (glossary)]] is the product itself. The Wider System context for a product system can be a higher level of product hierarchy or a service or an enterprise system which uses the product directly to help provide user value.
+
A product system context would be one in which the SoI is the product itself. The wider system context for a product system can be a higher level of product hierarchy, a service, or an enterprise system that uses the product directly to help provide value to the user. A significant aspect of a product systems context is the clear statement of how the product is intended to be used and ensures that this information is given to the {{Term|Acquirer (glossary)|acquirer}} upon delivery. The {{Term|Customer (glossary)|customer}} will be required to accept the system, typically through a formal process, agreeing not to go against the terms of use. 
  
A significant aspect of a product systems context is a clear statement of how the product is intended to be used; and its actual delivery to the acquirer.  The customer will be required to accept the system, typically through a formal process, against the agreed use.   
+
If a systems approach is applied to a product context, it is done with the purpose of engineering a narrow system product to be integrated and used in a wider system product hierarchy or to enable the delivery of a wider system service directly to a user by an enterprise.   
  
If we apply a [[Systems Approach (glossary)]] to a product context we do it with the purpose of engineering a narrow system product to be integrated and used in a wider system product hierarchy; or to enable the delivery of a wider system service directly to a user by an [[enterprise (glossary)]]. 
+
This view of the relationship between product and service is specific to [[Product Systems Engineering|product systems engineering]]. While some engineering of the acquirer's static service system may occur, it is done with a product focus. The definition of service system in a [[Service Systems Engineering|service systems engineering]] context describes a more dynamic view of service systems.
 
 
Note, this view of the relationship between product and service is specific to [[Product Systems Engineering]]. While some engineering of the acquirer's static service system may occur, this is done from a product focus. The definition of service system, as associated with [[Service Systems Engineering]], describes a more dynamic view of service systems.  This is discussed more fully in the next section.
 
  
 
==Service System Context==
 
==Service System Context==
Services are activities that cause a transformation of the state of an entity (people, product, business, and region or nation) by mutually agreed terms between the service provider and the customer (Spohrer 2008). The distinction between [[Service (glossary)]] and a [[Service System (glossary)]] is discussed in [[System Types]].   
+
Services are activities that cause a transformation of the state of an entity (people, product, business, and region or nation) by mutually agreed terms between the service provider and the customer (Spohrer 2008). The distinction between service and a service system is discussed in the article [[Types of Systems]].   
  
A service system context is one in which the [[System of Interest (SoI) (glossary)]] is the [[Service System (glossary)]]. This SoI contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. wider system of interest describes the enterprise providing the service and its relationship with other services to provide enterprise success.
+
A service system context is one in which the SoI is the service system. This SoI contains all of the technology, infrastructure, people, resources, etc. that are needed to enable the service. The WSoI describes the enterprise providing the service as well as its relationship with other services that impact the success of the enterprise.
  
If we apply a [[Systems Approach]] to a service system we do it with the purpose of engineering a service system to enable the outcomes required by an enterprise to satisfy its clients. When operating in the service system context, we should be free to consider all options to provide the service, providing they fit within the constraints of the enterprise. This will include interfaces to other services, people and resources in the enterprise. If an option for providing the service makes use of existing products or resources within or outside of the enterprise we must ensure they are available for this use, and that this does not adversely affect other services. Part of getting the right service may require the negotiation of changes to the wider enterprise context, but this must be by agreement with the relevant authority.
+
If a systems approach is applied to a service system, it is done with the purpose of engineering a service system to enable the outcomes required by an enterprise to satisfy its clients. When operating in the service system context, all options to provide the service must be considered, providing that they fit within the constraints of the enterprise. This will include interfaces to other services, people, and resources in the enterprise. If an option for providing the service makes use of existing products or resources within or outside of the enterprise, it must be ensured that they are available for this use and that this does not adversely affect other services. Part of getting the right service may require the negotiation of changes to the wider enterprise context, but this must be by agreement with the relevant authority.
  
For a service system, and when considering the service system context, the value is realized only through service transactions. The end-user co-creates value at the time of the request to use the service. One may have a smart phone (the product) but if one wants to make a flight reservation the service system is composed of many service system entities (the caller, the person called, the smart phone, the access network, core [[Acronyms|Internet Protocol (IP)]] network, [[Acronyms|Internet Service provider (ISP)]], www, data centers, etc.) that are linked as needed to enable the service. When one makes a reservation and then books the flight, the value has been created.
+
For a service system, and also when considering the service system context, the value is realized only through service transactions. The end-user co-creates value at the time of the request to use the service. For example, to make a flight reservation using a smart phone, the service system is composed of many service system entities (the caller, the person called, the smart phone, the access network, the core Internet Protocol (IP) network, the Internet Service provider (ISP), the World Wide Web (WWW), data centers, etc. All these are necessary to enable the service. When a caller makes a reservation and then books the flight, the value has been created.
  
This definition of service system, as associated with dynamic IT services is discussed more fully in [[Service Systems Engineering]] topic of Part 4.
+
This definition of a service system, as associated with dynamic {{Term|Information Technology (glossary)|Information Technology}} (IT) services, is discussed further in the article [[Service Systems Engineering]].
  
==Enterprise Systems Context==
+
==Enterprise System Context==
The distinction between [[Enterprise (glossary)]] and an [[Enterprise System (glossary)]]is discussed in [[System Types]].   
+
The distinction between an enterprise and an enterprise system is discussed in the article [[Types of Systems]].   
  
An Enterprise System context is one in which the [[System of Interest (SoI) (glossary)]] is the Enterprise System. This system contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The wider system of interest describes the business environment within which the enterprise sits.
+
An enterprise system context is one in which the SoI is the enterprise system. This system contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The WSoI describes the business environment within which the enterprise sits.
  
It is worth noting that an enterprise context is not equivalent to “organization” according to this definition. This is a frequent misuse of the term enterprise. An enterprise includes not only the organizations that participate in it, but also includes people, knowledge, and other assets such as processes, principles, policies, practices, doctrine, theories, beliefs, facilities, land, and intellectual property.  
+
It is to be noted that an enterprise context is not equivalent to an '''organization''' according to this definition. An enterprise includes not only the organizations that participate in it, but also the people, knowledge, and other assets, such as processes, principles, policies, practices, doctrines, theories, beliefs, facilities, land, and intellectual property that compose the enterprise.  
  
An enterprise may contain or employ service systems, along with product systems. An enterprise might even contain sub-enterprises.  
+
An enterprise may contain or employ service systems along with product systems. An enterprise might even contain sub-enterprises. Enterprise systems are unique when compared to product and service systems in that:
 +
* they are constantly evolving
 +
* they rarely have detailed configuration controlled requirements
 +
* they typically have (constantly changing) goals of providing shareholder value and customer satisfaction
 +
* they exist in a context (or environment) that is ill-defined and constantly changing
 +
The enterprise systems engineer must consider and account for these factors in their processes and methods.
  
Enterprise systems are unique, compared to product and service systems, in that they are constantly evolving, they rarely have detailed configuration controlled requirements, they typically have the goal of providing shareholder value and customer satisfaction, which are constantly changing and are difficult to verify, and they exist in a context (or environment) that is ill-defined and constantly changing.  The enterprise systems engineer must consider and account for these factors in their processes and methods.
+
Both product and service systems require an enterprise system context to create them and an enterprise to use the product system and deliver services, either internally to the enterprise or externally to a broader community. Thus, the three types of engineered system contexts are linked in all instances, regardless of which type of system the developers consider as the object of the development effort that is delivered to the customer.
 
 
Both product and service systems require an Enterprise System context to create them and an enterprise to use the product system to deliver services either internally to the enterprise or externally to a broader community. Thus the three types of engineered system context are linked in all instances regardless of which type of system the developers considers the object of the development effort and which is delivered to the customer.
 
  
 
==References==  
 
==References==  
 
===Works Cited===
 
===Works Cited===
Chang, C.M., 2010. ''[[Service Systems Management and Engineering]]: Creating Strategic Differentiation and Operational Excellence.''  Hoboken, NJ, USA: John Wiley and Sons.
 
  
Chesbrough, H. 2004. "A failing grade for the innovation academy." ''Financial Times'' (September 24):1, cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering''. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
+
Flood, R.L. 1987. "Some theoretical considerations of mathematical modeling." In ''Problems of Constancy and Change'' (Proceedings of 31st Conference of the International Society for General Systems Research, Budapest), Volume 1, pp. 354 - 360.  
  
IBM. 2005. IBM Research: Services Science: A New Academic Discipline? www.almaden.ibm.com/asr/resources/facsummit.pdf (accessed September 12, 2011), cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering''. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
+
Flood, R.L. and E.R. Carson. 1993. '' [[Dealing with Complexity]]: An Introduction to the Theory and Application of Systems Science, '' 2nd ed. New York, NY, USA: Plenum Press.  
  
IfM and IBM. 2008. "Succeeding through service innovation: A service perspective for education, research, business and government." University of Cambridge Institute for Manufacturing. Cambridge, UK, cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering''. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
Katzan, H. 2008. ''Service Science.'' Bloomington, IN, USA: iUniverse Books.
+
Spohrer, J. 2008. "Service science, management, engineering, and design (SSMED): An emerging discipline-outline & references." ''International Journal of Information Systems in the Service Sector,'' vol. 1, no. 3 (May).
  
Lusch, R.F. and S. L. Vargo (Eds). 2006. ''The service-dominant logic of marketing: Dialog, debate, and directions.'' Armonk, NY: ME Sharpe Inc.
+
===Primary References===
 +
Chang, C.M., 2010. ''[[Service Systems Management and Engineering]]: Creating Strategic Differentiation and Operational Excellence.'' Hoboken, NJ, USA: John Wiley and Sons.
  
Maglio P., S. Srinivasan, J.T. Kreulen, and J. Spohrer. 2006. “Service Systems, Service Scientists, SSME, and Innovation." ''Communications of the ACM''. 49(7) (July).
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
Salvendy, G. and W. Karwowski (eds.). 2010. ''Introduction to Service Engineering''. Hoboken, NJ, USA: John Wiley and Sons.
+
Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]].'' Boca Raton, FL, USA: CRC Press.  
  
Sampson, S.E. 2001. ''Understanding Service Businesses''. New York, NY, USA: John Wiley.
+
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation|Enterprises as systems: Essential challenges and enterprise transformation]]". ''Systems Engineering'', vol. 8, no. 2, pp. 138-50.
  
Spohrer, J. 2008. "Service Science, Management, Engineering, and Design (SSMED): An Emerging Discipline-Outline & References."  ''International Journal of Information Systems in the Service Sector.'' 1(3) (May).
+
Tien, J.M. and D. Berg. 2003. "[[A Case for Service Systems Engineering|A case for service systems engineering]]", ''Journal of Systems Science and Systems Engineering,'' vol. 12, no. 1, pp. 13-38.
  
Spohrer, J. and P. P. Maglio. 2008. "The emergence of service science: Toward systematic service innovations to accelerate co-creation of value." ''Production and Operations Management'' 17 (3): 238-246, cited by Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering''. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
+
===Additional References===
 +
ANSI/EIA. 2003. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐1998.
  
Spohrer, J. and P. Maglio. 2010. "Service Science: Toward a Smarter Planet." In ''Introduction to Service Engineering''. Ed. G Salvendy and W Karwowski. 3-30. Hoboken, NJ, USA: John Wiley & Sons, Inc.
+
Bernus, P., L. Nemes, and G. Schmidt (eds.). 2003. ''Handbook on Enterprise Architecture.'' Heidelberg, Germany: Springer.  
  
Tien, J.M. and D. Berg. 2003. "[[A Case for Service Systems Engineering]]". ''Journal of Systems Science and Systems Engineering.'' 12(1): 13-38.
+
Chang, C.M., 2010. ''[[Service Systems Management and Engineering]]: Creating Strategic Differentiation and Operational Excellence.'' Hoboken, NJ, USA: John Wiley and Sons.
 
 
Vargo, S.L. and R.F. Lusch. 2004. "Evolving to a new dominant logic for marketing." ''Journal of Marketing'' 68 (January 2004): 1-17.
 
  
Zeithaml, V. A., M. J. Bitner, and D. D. Gremler. 2005. ''Services Marketing: Integrating Customer Focus Across the Firm''. 4th ed. New York, NY, USA: McGraw-Hill, quoted in
+
DeRosa, J. K. 2006. “An Enterprise Systems Engineering Model.” Proceedings of the 16th Annual International Council on Systems Engineering, Orlando, FL, USA, 9-13 July 2006.
 
 
Chang, C.M., 2010. ''[[Service Systems Management and Engineering]]: Creating Strategic Differentiation and Operational Excellence.''  Hoboken, NJ, USA: John Wiley and Sons.
 
  
 
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press.
 
Giachetti, R.E. 2010. ''Design of Enterprise Systems: Theory, Architecture, and Methods.'' Boca Raton, FL, USA: CRC Press.
 
Joannou, P. 2007. "Enterprise, Systems, and Software—The Need for Integration." IEEE ''Computer''.  40(5) (May): 103-105.
 
  
Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]].'' Boca Raton, FL, USA: CRC Press.  
+
Joannou, P. 2007. "Enterprise, systems, and software—The need for integration." IEEE ''Computer'', vol. 40, no. 5, May, pp. 103-105.  
  
Rouse, W. B. 2009. "Engineering the Enterprise as a System." In ''Handbook of Systems Engineering and Management,'' 2nd ed. A.P. Sage and W.B. Rouse (eds.). New York, NY, USA: John Wiley and Sons.
+
Katzan, H. 2008. ''Service Science.'' Bloomington, IN, USA: iUniverse Books.
  
DeRosa, J. K. 2005. “Enterprise Systems Engineering.” Air Force Association, Industry Day, Day 1, 4 August 2005, Danvers, MA.  Available at: https://www.paulrevereafa.org/IndustryDay/05/presentations/index.asp.
+
Maglio P., S. Srinivasan, J.T. Kreulen, and J. Spohrer. 2006. “Service Systems, Service Scientists, SSME, and Innovation." ''Communications of the ACM''. 49(7) (July).
  
===Primary References===
+
Martin J.N. 1997. ''Systems Engineering Guidebook.'' Boca Raton, FL, USA: CRC Press.
Chang, C.M., 2010. ''[[Service Systems Management and Engineering]]: Creating Strategic Differentiation and Operational Excellence.''  Hoboken, NJ, USA: John Wiley and Sons.
 
 
 
Tien, J.M. and D. Berg. 2003. "[[A Case for Service Systems Engineering]]". ''Journal of Systems Science and Systems Engineering.'' 12(1): 13-38.
 
 
 
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.
 
  
 
Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]].'' Boca Raton, FL, USA: CRC Press.  
 
Rebovich, G., and B.E. White (eds.). 2011. ''[[Enterprise Systems Engineering: Advances in the Theory and Practice]].'' Boca Raton, FL, USA: CRC Press.  
  
Rouse, W.B. 2005. "[[Enterprise as Systems: Essential Challenges and Enterprise Transformation]]". ''Systems Engineering''. 8(2): 138-50.
+
Rouse, W.B. 2009. "Engineering the enterprise as a system," ''Handbook of Systems Engineering and Management,'', 2nd ed. A.P. Sage and W.B. Rouse (eds.).  New York, NY, USA: Wiley and Sons.
  
 +
Tien, J.M. and D. Berg. 2003. "[[A Case for Service Systems Engineering]]," ''Journal of Systems Science and Systems Engineering,'' vol. 12, no. 1, pp. 13-38.
  
===Additional References===
+
Valerdi, R. and D.J. Nightingale. 2011. "An introduction to the journal of enterprise transformation," ''Journal of Enterprise Transformation'', vol. 1, no. 1, pp. 1-6.
Martin J. N. 1997. ''Systems Engineering Guidebook.'' Boca Raton, FL, USA: CRC Press.
 
  
ANSI/EIA. 2003. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐1998.
+
----
 
 
Rouse, W.B. 2009. "Engineering the Enterprise as a System". In ''Handbook of Systems Engineering and Management'', 2nd ed. A.P. Sage and W.B. Rouse (eds.).  New York, NY, USA: Wiley and Sons.
 
 
 
Bernus, P., L. Nemes, and G. Schmidt (eds.). 2003. ''Handbook on Enterprise Architecture.'' Heidelberg, Germany: Springer.
 
 
 
Valerdi, R. and D.J. Nightingale. 2011. "An Introduction to the Journal of Enterprise Transformation." ''Journal of Enterprise Transformation'' 1(1):1-6.
 
  
DeRosa, J. K. 2006. “An Enterprise Systems Engineering Model.” Proceedings of the 16th Annual International Council on Systems Engineering, 9-13 July 2006, Orlando, FL, USA.
+
<center>[[Overview of the Systems Approach|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Identifying and Understanding Problems and Opportunities|Next Article >]]</center>
----
 
  
<center>[[Overview of the Systems Approach|<- Previous Article]] | [[Systems Approach|Parent Article]] | [[Identifying and Understanding Problems and Opportunities|Next Article ->]]</center>
+
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
  
[[Category:Part 2]][[Category: Topic]]
+
[[Category: Part 2]][[Category: Topic]]
 +
[[Category: Systems Approach Applied to Engineered Systems]]

Latest revision as of 21:46, 2 May 2024


Lead Author: Rick Adcock, Contributing Authors: Brian Wells, Scott Jackson, James Martin


The "Systems Approach Applied to Engineered Systems" knowledge area is graciously sponsored by PPI.

This article is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It describes knowledge related to the further expansion of the ideas of an engineered systemengineered system and engineered system contextcontext that were introduced in the Systems Fundamentals KA.

The single most important principle of the systems approachsystems approach is that it is applied to an engineered system context and not just to a single system (INCOSE 2012). The systems approach includes models and activities useful for the understanding, creation, use, and sustainment of engineered systems to enable the realization of stakeholder needs. Disciplines that use a systems approach (like systems engineeringsystems engineering (SE)) consider an engineered system context that defines stakeholder needs, and look for the best ways to provide value by applying managed technical activities to one or more selected engineered systems of interestsystems of interest (SoI).

Generally, four specific types of engineered system contexts are recognized in SE:

One of the key distinctions between these system contexts pertains to the establishment of how and when the SoI boundary is drawn.

Engineered System-of-Interest

We use the idea of an engineered system context to define an engineered SoI and to capture and agree on the important relationships between it, the systems with which it works directly, and any other systems with which it works. All applications of a systems approach (and hence of SE) are applied in a system context rather than only to an individual system.

A system context can be constructed around the following set of open system relationships (Flood and Carson 1993):

  • The Narrower System-of-Interest (NSoI) is the system of direct concern to the observer. The focus of this system is driven by the scope of authority or control with implicit recognition that this scope may not capture all related elements.
  • The Wider System-of-Interest (WSoI) describes a logical system boundary containing all of the elements needed to fully understand system behavior. The observer may not have authority over all of the elements in the WSoI but will be able to establish the relationships between WSoI elements and NSoI elements.
  • The WSoI exists in an environment. The immediate environment contains engineered, natural, and/or social systems, with which the WSoI (and thus some elements of the NSoI) directly interact for the purpose of exchanging material, information, and/or energy to achieve its goals or objective.
  • A Wider Environment completes the context and contains systems that have no direct interaction with the SoI, but which might influence decisions related to it during its life cycle.
  • "Some Theoretical Considerations of Mathematical Modeling" (Flood 1987) extends this context to include a meta-system (MS) that exists outside of the WSoI and exercises direct control over it.

The choice of the SoI boundary for particular activities depends upon what can be changed and what must remain fixed. The SoI will always include one or more NSoI but may also include WSoI and an MS if appropriate, such as when considering a service or an enterprise system.

Applying the System Context

For lower-level and less-complex systems, the WSoI can represent levels of a product systemproduct system hierarchy. An example of this would be an engine management unit as part of an engine, or an engine as part of a car. The WSoI in a system context may encapsulate some aspects of SoS ideas for sufficiently complexcomplex systems. In these cases, the WSoI represents a collection of systems with their own objectives and ownership with which the NSoI must cooperate in working towards a shared goal. An example of this would be a car and a driver contributing to a transportation service.

This view of a SoS context being used as a means to support the engineering of an NSoI product system is one way in which a systems approach can be applied. It can also be applied directly to the SoS. Examples of this include a flexible multi-vehicle transportation service or transportation as part of a commercial enterprise. In this case, the NSoI aspect of the context no longer applies. The WSoI will consist of a set of cooperating systems, each of which might be changed or replaced to aid in the synthesis of a solution. The context may also need to represent loose coupling, with some systems moving in or out of the context depending on the need, or late binding with systems joining the context only at, or close to, the delivery of the service.

Thus, a context allows a reductionist view of the SoI that is of direct concern to an observer, as it provides for the system relationships and influences that are needed to maintain a holisticholistic view of the consequence of any actions taken.

Product System Context

The distinction between a productproduct and a product systemproduct system is discussed in the article Types of Systems.

A product system context would be one in which the SoI is the product itself. The wider system context for a product system can be a higher level of product hierarchy, a service, or an enterprise system that uses the product directly to help provide value to the user. A significant aspect of a product systems context is the clear statement of how the product is intended to be used and ensures that this information is given to the acquireracquirer upon delivery. The customercustomer will be required to accept the system, typically through a formal process, agreeing not to go against the terms of use.

If a systems approach is applied to a product context, it is done with the purpose of engineering a narrow system product to be integrated and used in a wider system product hierarchy or to enable the delivery of a wider system service directly to a user by an enterprise.

This view of the relationship between product and service is specific to product systems engineering. While some engineering of the acquirer's static service system may occur, it is done with a product focus. The definition of service system in a service systems engineering context describes a more dynamic view of service systems.

Service System Context

Services are activities that cause a transformation of the state of an entity (people, product, business, and region or nation) by mutually agreed terms between the service provider and the customer (Spohrer 2008). The distinction between service and a service system is discussed in the article Types of Systems.

A service system context is one in which the SoI is the service system. This SoI contains all of the technology, infrastructure, people, resources, etc. that are needed to enable the service. The WSoI describes the enterprise providing the service as well as its relationship with other services that impact the success of the enterprise.

If a systems approach is applied to a service system, it is done with the purpose of engineering a service system to enable the outcomes required by an enterprise to satisfy its clients. When operating in the service system context, all options to provide the service must be considered, providing that they fit within the constraints of the enterprise. This will include interfaces to other services, people, and resources in the enterprise. If an option for providing the service makes use of existing products or resources within or outside of the enterprise, it must be ensured that they are available for this use and that this does not adversely affect other services. Part of getting the right service may require the negotiation of changes to the wider enterprise context, but this must be by agreement with the relevant authority.

For a service system, and also when considering the service system context, the value is realized only through service transactions. The end-user co-creates value at the time of the request to use the service. For example, to make a flight reservation using a smart phone, the service system is composed of many service system entities (the caller, the person called, the smart phone, the access network, the core Internet Protocol (IP) network, the Internet Service provider (ISP), the World Wide Web (WWW), data centers, etc. All these are necessary to enable the service. When a caller makes a reservation and then books the flight, the value has been created.

This definition of a service system, as associated with dynamic Information TechnologyInformation Technology (IT) services, is discussed further in the article Service Systems Engineering.

Enterprise System Context

The distinction between an enterprise and an enterprise system is discussed in the article Types of Systems.

An enterprise system context is one in which the SoI is the enterprise system. This system contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The WSoI describes the business environment within which the enterprise sits.

It is to be noted that an enterprise context is not equivalent to an organization according to this definition. An enterprise includes not only the organizations that participate in it, but also the people, knowledge, and other assets, such as processes, principles, policies, practices, doctrines, theories, beliefs, facilities, land, and intellectual property that compose the enterprise.

An enterprise may contain or employ service systems along with product systems. An enterprise might even contain sub-enterprises. Enterprise systems are unique when compared to product and service systems in that:

  • they are constantly evolving
  • they rarely have detailed configuration controlled requirements
  • they typically have (constantly changing) goals of providing shareholder value and customer satisfaction
  • they exist in a context (or environment) that is ill-defined and constantly changing

The enterprise systems engineer must consider and account for these factors in their processes and methods.

Both product and service systems require an enterprise system context to create them and an enterprise to use the product system and deliver services, either internally to the enterprise or externally to a broader community. Thus, the three types of engineered system contexts are linked in all instances, regardless of which type of system the developers consider as the object of the development effort that is delivered to the customer.

References

Works Cited

Flood, R.L. 1987. "Some theoretical considerations of mathematical modeling." In Problems of Constancy and Change (Proceedings of 31st Conference of the International Society for General Systems Research, Budapest), Volume 1, pp. 354 - 360.

Flood, R.L. and E.R. Carson. 1993. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science, 2nd ed. New York, NY, USA: Plenum Press.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Spohrer, J. 2008. "Service science, management, engineering, and design (SSMED): An emerging discipline-outline & references." International Journal of Information Systems in the Service Sector, vol. 1, no. 3 (May).

Primary References

Chang, C.M., 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Rebovich, G., and B.E. White (eds.). 2011. Enterprise Systems Engineering: Advances in the Theory and Practice. Boca Raton, FL, USA: CRC Press.

Rouse, W.B. 2005. "Enterprises as systems: Essential challenges and enterprise transformation". Systems Engineering, vol. 8, no. 2, pp. 138-50.

Tien, J.M. and D. Berg. 2003. "A case for service systems engineering", Journal of Systems Science and Systems Engineering, vol. 12, no. 1, pp. 13-38.

Additional References

ANSI/EIA. 2003. Processes for Engineering a System. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA). ANSI/EIA 632‐1998.

Bernus, P., L. Nemes, and G. Schmidt (eds.). 2003. Handbook on Enterprise Architecture. Heidelberg, Germany: Springer.

Chang, C.M., 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.

DeRosa, J. K. 2006. “An Enterprise Systems Engineering Model.” Proceedings of the 16th Annual International Council on Systems Engineering, Orlando, FL, USA, 9-13 July 2006.

Giachetti, R.E. 2010. Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, FL, USA: CRC Press.

Joannou, P. 2007. "Enterprise, systems, and software—The need for integration." IEEE Computer, vol. 40, no. 5, May, pp. 103-105.

Katzan, H. 2008. Service Science. Bloomington, IN, USA: iUniverse Books.

Maglio P., S. Srinivasan, J.T. Kreulen, and J. Spohrer. 2006. “Service Systems, Service Scientists, SSME, and Innovation." Communications of the ACM. 49(7) (July).

Martin J.N. 1997. Systems Engineering Guidebook. Boca Raton, FL, USA: CRC Press.

Rebovich, G., and B.E. White (eds.). 2011. Enterprise Systems Engineering: Advances in the Theory and Practice. Boca Raton, FL, USA: CRC Press.

Rouse, W.B. 2009. "Engineering the enterprise as a system," Handbook of Systems Engineering and Management,, 2nd ed. A.P. Sage and W.B. Rouse (eds.). New York, NY, USA: Wiley and Sons.

Tien, J.M. and D. Berg. 2003. "A Case for Service Systems Engineering," Journal of Systems Science and Systems Engineering, vol. 12, no. 1, pp. 13-38.

Valerdi, R. and D.J. Nightingale. 2011. "An introduction to the journal of enterprise transformation," Journal of Enterprise Transformation, vol. 1, no. 1, pp. 1-6.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024