Stakeholders and Concerns Modeling the View Key Issues
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:
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.
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:
the policies, procedures and guidelines drive your management requirements. (such as a policy to restrict downloading software from the internet)
how your shop measure system availability.
the management services and utilities required.
the likely quantity, quality and location of management and support personnel.
the ability of users to take on system management tasks, such as password maintenance.
the manageability of existing and planned components in each of the component categories.
whether management should be centralized or distributed.
whether security is the responsibility of system managers or a separate group, bearing in mind any legal requirements.
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.
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?
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?
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?
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?
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