Developing an Operations View

Stakeholders and Concerns      Modeling the View      Key Issues


Stakeholders and Concerns

This view should be developed for the operations, administration and management personnel of the system.

Major concerns for these stakeholders are understanding how the system is managed as a whole, and how all components of the system are managed. The key concern is managing change in the system and predicting necessary preventative maintenance.

In general these stakeholders are concerned with assuring that the availability of the system does not suffer when changes occur. Managing the system includes managing components such as:

Modeling the View

The general architecture of a "managed system" can be modeled with ADML entities (components, ports, connectors and roles).

Additionally business scenarios are an extremely useful way to depict what should happen when planned and unplanned events occur. It is highly recommended that business scenarios be created for planned change, and for unplanned change.

The model of actors and interactions in the business scenario should be developed using the above constructs, components, ports, roles, connectors.

The following paragraphs describe some of the key issues that the architect might consider when constructing business scenarios.

Key Issues

The Operations View acts as a check and balance on the difficulties and day-to-day running costs of systems built within the new architecture. Often, system management is not considered until after all the important purchasing and development decisions have been taken, and taking a separate management view at an early stage in architecture development is one way to avoid this pitfall. It is good practice to develop the Technical Operations View with close consideration of the Technical Development View, since in general management is difficult to retrofit into an existing design.

Key elements of the Operations View are:

Key technical components categories that are the subject of the Operations View deal with change, either planned upgrades, or unplanned outages. The following table lists specific concerns in for each component category.

Component
Category

Planned Change
Considerations

Unplanned Change
Considerations

 

Security Components

How does one propagate a security change throughout the system?

Who is responsible for making changes, end users, or security stewards?…

 

What should happen when security is breached?

What should happen if a security component fails?…

 

Data Assets

How does one add new data elements?

How does one import/export or load/unload data?

How is backup managed while running continuously?

How is data change propagated in distributed environment?… 

 

What are your backup procedures and are all the system capabilities there to backup in time?

 

Software Assets

How does one introduce a new application into the systems?

What procedures do you have to control software quality?

How does one propagate application changes in a distributed environment?

How does one restrict unwanted software introduction given the internet? …

 

What do you want to happen when an application fails?

What do you want to happen when a resource of the application fails?…

Hardware Assets

How do you assess the impact of new hardware on the system, especially network load?

 

What do you want to happen when hardware outages occur?

Networking Assets

How do you assess the impact of new networking components?

How do you optimize your networking components?…

What do you want to happen when networking outages occur?


Copyright © The Open Group, 1998, 2000