Deploying, Using, and Sustaining Systems to Solve Problems

This article considers the activities of the systems approach related to the deployment, sustainment and use of a solution in detail. Any of the activities described below may need to be considered concurrently with activites the other activities of in the Systems Approach. The final article in this knowledge area, 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 elements of Systems Engineering.

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

There is very little in the literature pertaining to the application of the systems approach to this phase of the life cycle. However, it was stated at the beginning of this Knowledge Area that it was a basic premise that the systems approach would pertain to all phases of the life cycle. Hence,, it can be inferred that the systems approach pertains to the deploying, useing, and sustaining sytems to solve problems.

Transition

Transferring custody of the system-of-interest and responsibility for its support from one organization to another is often called transition (INCOSE 2011). Transition of a product system includes integration into the acquiring organization's infrastructure.

Transition includes the initial installation of a system, ensuring that it is compatible with the wider system, and ensuring that it does not cause any significant wider system issues. This process of acceptance and release for use varies between domains and across businesses and enterprises, and can be thought of as an initial assessment of the system effectiveness , (Hitchin 2007). Generically, transition may be considered to have two parts. (a) Ensuring that the new system interoperates with the systems around it and (b) ensuring the resulting system is safe and has other critical operational properties.

It is particularly important to have considered the emergent properties when a new system is added to the existing organization's system of systems (sos) network, as well as the complexity (see also Complexity) of the organization into which the new system is transitioned. The more complex the receiving organization is, the more challenging the transition and the greater 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. This second case can be a significant problem if the required responsiveness of the service does not leave sufficent time to ensure that the service meets necessary functional and quality attributes, including interoperability, safety, and security. (See Service Systems Engineering).

Transition can also require its own enabling systems , each of which can be realized using a systems approach.

Operation

Use of the system to help enable delivery of user services is often called operations. (INCOSE, 2011) Systems effectiveness is normally considered throughout the operational life of a system. For a complex system, emergent behavior should be considered in three ways:

1. To identify and plan for emergent property within the system realization
2. To build in mechanisms for identifying and handling unexpected emergent properties within the system during its use
3. To provide necessary procedures for dealing with wider system consequences of unexpected emergent properties in the enterprise; e.g. emergency response or medical first aid

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

Maintenance

The purpose of maintence is to sustain the system through its useful life (INCOSE 2011). In system terms, maintenance implements systems to deal with entropy and maintaining the system of interest in a viable state. Since an open system maintains its existance by continual exchange of energy, information and materiel with its 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 system concepts. Resource management identifies the need to consider the acquisition, storage, distribution, conversion and disposal of resources. Viability management should consider systems to maintain homeostasis , and means for ensuring resilience to environmental disturbance and 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

The purpose of disposal is to remove a system element from the operational environment with the intent of permanently terminating its functions, and to deal with any waste products left behnd by the system. (NASA 2007) describes disposal from the vantage point of NASA space and ground systems.

Disposal requires its own enabling systems each of which can be realized using a systems approach. As with maintenance, a large part of successful disposal requires related issues to have been considered early in the life cycle.

References

Works Cited

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

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.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College.

Primary References

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.

Additional References

No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

---

<- Previous Article | Parent Article | Next Article ->