Difference between revisions of "Engineered System Context"

Revision as of 16:16, 20 February 2012

Engineered Systems

The ideas of both an engineered system and a Systems Context (glossary) are discussed in the Systems Thinking Knowledge Area.

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 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) .

Three specific types of engineered system context are generally recognized in systems engineering: product system , service system and enterprise system . One of the key distinctions between product, service, and enterprise systems engineering is how widely the SoI boundary is drawn.

Engineered System Context

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.

A system contexts 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 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 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.
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.
(Flood 1987) extends the context to include a Meta-System (MS), which sits 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. 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 hierarchy; e.g. an engine management unit as part of an engine; an engine as part of a car.

The WSoI in a system context may encapsulate some aspects of system of systems ideas, for sufficiently complex 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 .

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 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.

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 product and a product system is discussed in Types of Systems.

A product system context would be one in which the system of interest (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 user value.

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 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

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 system of interest (soi) is the service system . This SoI contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The Wider system of interest 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, core Internet Protocol (IP) network, 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.

This definition of service system, as associated with dynamic IT services is discussed more fully in Service Systems Engineering topic of Part 4.

Enterprise Systems Context

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

An Enterprise System context is one in which the system of interest (soi) 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.

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.

An enterprise may contain or employ service systems, along with product systems. An enterprise might even contain sub-enterprises.

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 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

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.