View source for Deploying, Using, and Sustaining Systems to Solve Problems

----
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Brian Wells, Scott Jackson, Janet Singer, Duane Hybertson''
----
[[File:PPI.png|thumb|250px|right|<center>The "Systems Approach Applied to Engineered Systems" knowledge area is graciously sponsored by PPI.<center>]]
This topic is part of the [[Systems Approach Applied to Engineered Systems]] knowledge area (KA).  It describes knowledge related to the deployment, {{Term|Sustainment (glossary)|sustainment}}, and use of a {{Term|Solution (glossary)|solution}} that may have been developed through the activities described in the [[Implementing and Proving a Solution]] topic.  Discussion of how a deployed {{Term|System (glossary)|system}} fits into commercial and {{Term|Acquisition (glossary)|acquisition}} relationships is present in [[Introduction to System Fundamentals]]. Any of the activities described below may also need to be considered {{Term|Concurrently (glossary)|concurrently}} with other activities in the {{Term|Systems Approach (glossary)|systems approach}} at a particular point in the life of a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI). 

The activities described below should be considered in the {{Term|Context (glossary)|context}} of the [[Overview of the Systems Approach]] topic at the start of this KA.  The final topic in this KA, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to {{Term|Element (glossary)|elements}} of {{Term|Systems Engineering (glossary)|systems engineering}} (SE).

==Introduction==
Part 3, [[Systems Engineering and Management]], of the Guide to the SE Body of Knowledge (SEBoK) provides two additional KAs that address the {{Term|Engineering (glossary)|engineering}} aspects of these steps of the systems approach.  KAs [[Product and Service Life Management]] and [[System Deployment and Use]] in Part 3 explain the SE aspects of deployment, operation, {{Term|Maintenance (glossary)|maintenance}}, {{Term|Logistics (glossary)|logistics}}, {{Term|Service Life Extension (SLE) (glossary)|service life extension}}, updates, upgrades, {{Term|Disposal (glossary)|disposal}} and the retirement of systems.

A systems approach considers the total system and the total {{Term|Life Cycle (glossary)|life cycle}} of the system.  This includes all aspects of the system and the system throughout its life until the day users depose of the system and the external {{Term|Enterprise (glossary)|enterprises}} complete the handling of the disposed system {{Term|Product (glossary)|products}}.  Creation of the system is rarely the step that solves the {{Term|Stakeholder (glossary)|stakeholders’}} {{Term|Problem (glossary)|problems}}.  It is the use of the system solution that solves the problem.  From this perspective the deployment, use and sustainment of the system are important {{Term|Concept (glossary)|concepts}} that must be a part of the systems approach.

{{Term|Engineered System (glossary)|Engineered systems}} are eventually owned by an individual, {{Term|Team (glossary)|team}}, or enterprise. Those who own the system during development may not be the ones who own the system when it is in operation. Moreover, the owners may not be the {{Term|User (glossary)|users}}; e.g., {{Term|Service System (glossary)|service systems}} may be used by the general public but owned by a specific {{Term|Business (glossary)|business}} that offers the {{Term|Service (glossary)|service}}. The transition of a system from development to operations is often itself a {{Term|Complex (glossary)|complex}} task, involving such activities as training those who will operate the system, taking legal actions to complete the transfer, and establishing logistical arrangements so that the operators can keep the system running once the transition is completed.

A complete systems approach must also consider the many enterprises involved in the system from initial conception through the completion of the disposal {{Term|Process (glossary)|process}}.  These enterprises are all stakeholders with {{Term|Requirement (glossary)|requirements}}, which all have {{Term|Interface (glossary)|interfaces}} that must be considered as part of a total systems approach.

There is very little in the literature pertaining to the application of the systems approach to these phases of the life cycle. However, a basic premise of this KA is that the systems approach pertains to all phases of a system’s life cycle. Hence, to properly build systems to solve problems or for other uses, it can be inferred that the systems approach pertains to the deployment, use, and the sustainment of the systems. Many of the available references in this topic area are from SE literature rather than from literature associated with the systems approach; the reader should also see Part 3 of the SEBoK, [[Systems Engineering and Management]]. 

===Deployment: The Transition from Development to Operation===

Transferring custody of the SoI and responsibility for its support from one {{Term|Organization (glossary)|organization}} to another occurs during deployment and is often called transition (INCOSE 2011). Transition of a {{Term|Product System (glossary)|product system}} includes the integration of the system into the acquiring organization's {{Term|Infrastructure (glossary)|infrastructure}}. Deployment and transition involves the activity of moving the system from the development to the operational location(s), along with the support systems necessary to accomplish the relocation.

Transition includes the initial {{Term|Installation (glossary)|installation}} of a system and the determination that it is compatible with the wider system and does not cause any significant wider system {{Term|Issue (glossary)|issues}}. This process of acceptance and release for use varies between {{Term|Domain (glossary)|domains}} and across businesses and enterprises, and can be thought of as an initial assessment of the system’s {{Term|Effectiveness (glossary)|effectiveness}} (Hitchins 2007). Generally, transition may be considered as having two parts:  1.) ensuring that the new system {{Term|Interoperability (glossary)||interoperates}} with the systems around it and 2.) ensuring the resulting system is safe and possesses other critical {{Term|Operational (glossary)|operational}} properties. 

It is particularly important to consider {{Term|Emergent Property (glossary)|emergent properties}} when a new system is added to the existing organization's {{Term|System of Systems (SoS) (glossary)|system of systems}} (SoS) network, as well as the {{Term|Complexity (glossary)|complexity}} of the organization into which the new system is transitioned (see also [[Complexity]]). The more complex the receiving organization is, the more challenging the transition will be, and the greater the likelihood of unintended interactions and consequences from the new system's insertion. Dealing with the consequences of this complexity starts in transition and continues into operation, maintenance, and disposal.   

Transition of a service system is often performed in two stages.  First, the service system infrastructure is accepted and released.  Second, each realization of the service is accepted and released. There can be significant problems during the second stage if the required responsiveness of the service does not leave sufficient time to ensure that the service meets necessary {{Term|Function (glossary)|functional}} and {{Term|Quality (glossary)|quality}} attributes, including {{Term|Interoperability (glossary)|interoperability}}, {{Term|Safety (glossary)|safety}}, and {{Term|Security (glossary)|security}}. (See [[Service Systems Engineering]].)

Transition and deployment of a system may introduce unique requirements that are not necessary for operation or use.  These requirements can influence the {{Term|Design (glossary)|design}} of the system; therefore, must be considered during the initial requirements and design stages.  The most common examples are related to the need to transport the system or system elements, which often limits the size and weight of the system elements.

Transition can also require its own {{Term|Enabling System (glossary)|enabling systems}}, each of which can be realized using a systems approach.

===Use: Operation===

Use of the system to help enable delivery of user services is often called “operations” (INCOSE 2011).  A system’s effectiveness is normally considered throughout the operational life of a system. For a complex system, {{Term|Emergent Behavior (glossary)|emergent behavior}} should be considered in three ways:
* to identify and plan for emergent properties within the system realization process (See [[System Realization]] KA in Part 3, [[Systems Engineering and Management]])
* to incorporate mechanisms for identifying and handling unexpected emergent properties within the system during its use
* to provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise (e.g., emergency responses or medical first aid)

Operations require their own enabling systems, each of which can be realized using a systems approach.

===System Sustainment and Maintenance===

System sustainment requires maintenance of the system throughout its useful life (INCOSE 2011). In system terms, maintenance implements systems that handle {{Term|Entropy (glossary)|entropy}} and maintaining the SoI in a {{Term|Viable (glossary)|viable}} state. Since an {{Term|Open System (glossary)|open system}} maintains its existence by continual exchange of energy, information, and materiel with its {{Term|Environment (glossary)|environment}}, one aspect of its maintenance must be the management of resources in the environment.  

Hitchins (2007) describes generic approaches to resource management and viability management based on {{Term|Systems Concept (glossary)|systems concepts}}. Resource management identifies the need to consider the acquisition, storage, distribution, conversion, and disposal of resources.  Viability management should consider systems to maintain {{Term|Homeostasis (glossary)|homeostasis}} and a means for ensuring {{Term|Resilience (glossary)|resilience}} to environmental disturbance and {{Term|Adaptability (glossary)|adaptability}} to environmental change.

Maintenance will require its own enabling systems, each of which can be realized using a systems approach. Maintenance success is more likely if it is considered as part of the system concept and design well before the system enters service.

===Disposal===

A total life cycle systems approach cannot be considered complete without consideration of how disposal of the system will be accomplished.  The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its use, and remove any hazardous or toxic materials or waste products (INCOSE 2011).

During disposal, the entirety of the open system crosses the {{Term|Boundary (glossary)|boundary}} from the system side to the environment.  A complete systems approach must consider how it crosses the boundary and what remains that must be managed by enterprises other than the ones that developed, used or sustained the system.  Including disposal in the system approach expands the stakeholders, the enterprises and the external systems that must be considered.

Disposal requires its own enabling systems, each of which can be realized using a systems approach.  Some of these may be contained within the system boundaries and others may be external to the system.  For the external disposal systems, the interface where the handover occurs must be considered.  As with maintenance, a large part of successful disposal requires related issues to have been considered early on in the system’s life cycle.

The topic [[Disposal and Retirement]] in Part 3, [[Systems Engineering and Management]], of the SEBoK  provides information on the engineering aspects of system disposal.

==References== 

===Works Cited===

Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA:  John Wiley and Sons.

INCOSE. 2012. ''INCOSE Systems Engineering Handbook'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.2.

===Primary References===
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.

===Additional References===
MITRE.  2011.  "Transformation planning and organizational change," in ''Systems Engineering Guide. '' Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/. Accessed December 4, 2014. 

----
<center>[[Implementing and Proving a Solution|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Applying the Systems Approach|Next Article >]]</center>

<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>

[[Category:Part 2]][[Category:Topic]][[Category:Systems Approach Applied to Engineered Systems]]