Engineered System Context
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 system and engineered system context that were introduced in the Systems Fundamentals KA.
The single most important principle of the systems approach is that it is applied to an engineered system context and not just to a single system (INCOSE 2011). 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 engineering) 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 interest (SoI).
Generally, four specific types of engineered system contexts are recognized in SE:
One of the key distinctions between these system contexts is how and when the SoI boundary is drawn.
Engineered System Context
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 it works directly with, and the systems that influence it in some way. All applications of a systems approach (and hence of SE) are applied to a system context, and not just 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 agree upon 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 interacts with to exchange 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) which 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 MS if appropriate, such as when considering a service or an enterprise system.
How is a system context applied to different kinds of engineered system problems?
For lower level, less complex, systems the WSoI can represent levels of product system hierarchy, e.g., 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 system of systems (sos) ideas for sufficiently complex systems. In these cases, the WSoI represents a collection of systems with their own objectives and ownership which the NSoI must cooperate with towards a shared goal, e.g., a car and driver contributing to a transport service .
This view of a system of systems context as a means to support the engineering of a NSoI product system 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 . 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, 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 view of the consequence of any actions they take.
Product System Contexts
The distinction between a product and a product system is discussed in 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 or a service or an enterprise system which uses the product directly to help provide value to the user.
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 we apply a systems approach 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.
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 with 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
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 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. needed to enable the service. The wider SoI describes the enterprise providing the service and its relationship with other services to provide enterprise success.
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.
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, the core Internet Protocol (IP) network, the Internet Service provider (ISP), the World Wide Web, data centers, etc.) that are all necessary to enable the service. When one makes a reservation and then books the flight, the value has been created.
This definition of a service system, as associated with dynamic IT services, is discussed more fully in the Service Systems Engineering topic of Part 4.
Enterprise Systems Context
The distinction between an enterprise and an enterprise system is discussed in 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 wider SoI describes the business environment within which the enterprise sits.
It is worth noting that an enterprise context is not equivalent to an “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 the people, knowledge, and other assets, such as processes, principles, policies, practices, doctrine, 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 goals of providing shareholder value and customer satisfaction (these goals 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 the object of the development effort and which 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, p. 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. 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.
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).
Primary References
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.
Rouse, W.B. 2005. "Enterprise as Systems: Essential Challenges and Enterprise Transformation". Systems Engineering. 8(2): 138-50.
Additional References
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.
Chang, C.M., 2010. Service Systems Management and Engineering: Creating Strategic Differentiation and Operational Excellence. Hoboken, NJ, USA: John Wiley and Sons.
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).
Tien, J.M. and D. Berg. 2003. "A Case for Service Systems Engineering". Journal of Systems Science and Systems Engineering. 12(1): 13-38.
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.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus