WorkProductDescriptor
Work Product (Artifact): Operational Model |
|
 |
This artifact describes the "operational" aspect of an IT system's architecture. It describes the required operational characteristics and capabilities of the IT system architecture and represents, at an architectural level, the network of computer systems and their associated peripherals, together with the systems software, middleware, and application software that they run in order to support the users of the system. |
|
Purpose
This artifact provides:
-
A definition of the operational aspect of the architecture of a particular IT system, designed to meet a specific
set of functional and non-functional requirements. The "operational" aspect focuses on the IT system
infrastructure.
-
A definition of a pattern of how the operational aspect of the architecture of an IT system (or parts of it) may be
constructed in order to satisfy a generalized set of functional and non-functional requirements. Examples may be
found in IBM's architectural assets or in an enterprise's architecture framework.
For a particular IT system
This artifact may be used:
-
As an input to architecture and design reviews, including confirmation that the business problem is well
articulated and that there is a viable IT system.
-
As a way of dividing large problems so that each part can be worked on in relative isolation. (For example, a
Manufacturing system may be seen as composed of a Customer Information System, a Scheduling System and a
Dispatching System. The operational aspect of each of these separate systems may then each be worked on
separately).
-
To enable application developers to modify and elaborate their work, based on this artifacts view of how the
application will be distributed and managed.
-
To enable the analysis of how the IT system will deliver key non-functional requirements such as performance &
capacity, and security (confidentiality, integrity and availability), including the verification that the
non-functional requirements of the nodes and connections are achievable.
-
To contribute to estimates of the cost of the system's operational infrastructure, both for budgeting and as part
of the business case for the solution.
-
In conjunction with the functional aspect of the system, to help identify hardware and software technologies and
products, and to generally be a blueprint for the acquisition, installation, and subsequent maintenance of the
system
-
As a detailed technical specification against which an architect can evaluate alternative products or technology
vendors can submit tenders.
As a Pattern
As a pattern, this artifact may be used:
-
To provide a "quick start" to projects, which can select, customize and integrate pre-developed, partial levels and
views of this artifact as a "Reference Architecture". This can save time, reduce required project resources
and reduce risk
-
To control and constrain the options available to multiple and otherwise independent projects within an enterprise,
in order to standardize, realize economies of scale, reduce costs and achieve higher levels of flexibility and
interoperability across IT systems.
|
Relationships
Roles | Responsible:
| Modified By:
|
Description
Main Description |
This artifact describes the operational distribution of a system's components (which may be grouped into deployment
units) onto nodes, the placement of nodes and users across locations, the connections between nodes necessary to
support the required interactions between components, in order to achieve the system's functional and non-functional
requirements within the constraints of technology, skills and budget.
Operational Modeling Terminology
This artifact's (and that of its contained artifacts) terminology is defined within the System Description Standard R3
Semantic Specification (see Guidance for link) which includes definitions for the following:
-
Actors (and workers) - the roles a user or an external system play with respect to the target system
-
Locations - a geographical area or position.
-
Borders - representing the existing connection between two locations
-
Components - modular units of functionality, which make this functionality available through an interface.
-
Deployment Units - a grouping of facets of a component that have similar characteristics.
-
Connectors - enable the exchange of messages (interactions) between resource containers.
-
Interactions - identify the messages exchanged between one or two resource containers in the context of a
collaboration, and the sequencing of these messages via their associated send/receive events.
-
Nodes - a collection of components fulfilling a specific responsibility with a certain quality of service within
the target system.
-
Connections - supports the required connectivity between connectable model elements.
-
Zones - an aggregation of a number of model elements with a common (sub-) set of values for a particular
non-functional requirement and/or non-functional characteristic.
-
Boundaries - associated with a change in value for a particular non-functional requirement and/or characteristic
between two model elements.
Depending on the development approach adopted and/or the context, it can be very helpful to create levels of this
artifact. The two basic levels of this artifact are:
-
Logical: This level describes the characteristics and capabilities of the operational aspect
of the system architecture in a technology independent and product neutral manner.
-
Physical: This level describes characteristics and capabilities of the operational aspect of
the system architecture in a technology and product dependent manner.
Both levels of this artifact may be further described at three different sub-levels relating to the degree to which the
level has been sized:
-
Unsized (or unranged) - the technology and products are specified to support the components
deployed but not sized and without detailing how the system will achieve the service level characteristics.
-
Ranged - the technology and products are specified to support a bounded range of requirements for
a defined range of circumstances.
-
Sized - the technology and products are specified and sized to support the components deployed and
details how the system will achieve the service level characteristics.
|
Brief Outline |
This artifact may contain the following which may be described by this artifact or by its contained artifacts, as
appropriate to the context:
-
An introduction, describing the overall context and content of the artifact, the nature of the artifact (either to
meet a specific set of IT requirement or to provide a generalized architecture pattern), its scope and depth of
detail, its level, and its degree of completeness.
-
A description of the locations, borders, zones, and boundaries that provide the backdrop for the IT system.
-
A model showing the placement of users of the IT system across locations and zones.
-
A description of the deployment units and the connectors used for communication.
-
A model showing the relationship between deployment units, and the interactions between deployment units over
connectors.
-
A model showing the relationship between nodes and connections, the distribution of nodes across locations and
zones, the interactions of nodes across connections, and the use of borders by connections.
-
A description of the nodes (and/or collections of nodes) and connections between nodes.
-
A description of the placement of deployment units (and/or components) onto nodes.
-
A description of how the operational aspect of the architecture of the IT system will support the functional and
non-functional requirements. This includes considerations of how the various service levels (of performance,
availability and security) will be achieved, as well as defining the system's functional behaviour when operating
in an acceptable degraded mode caused by planned or unplanned system outages.
-
A description of the systems management approach to ensure the IT system maintains the target service levels.
This will cover topics such as a backup and recovery, data and software distribution, change control, configuration
management, and other systems management processes.
-
Walkthrough diagram(s) showing how the elements in this artifact interact in order to support an activity triggered
by a user of the system. This would show how the deployment units placed on nodes co-operate in
support of selected use cases for particular actors in particular locations and/or
zones.
|
Notation | This artifact is documented in a combination of structured text, structured tables, matrices and diagrams using a
specialized notation and naming standards which are defined in the IBM System Description Standard V3 and the IBM
Architecture Description Standard (ADS) Operational Model Notation Guidance V2. Please refer to these for details of
the notation. |
Properties
Optional |  |
Planned |  |
Key Considerations
Levels of this artifact
The artifact can be a large and complex work product. It is therefore important to understand how it may be best
developed and presented, depending on the particular context.
In order to reduce the complexity of the development process, the various development techniques available take
advantage of a number of well-defined views and levels of completeness.
Therefore this artifact can be refined and elaborated in various ways depending on the nature of the project life cycle
and the development techniques used. Useful intermediate stages of development have been defined for both the
logical and physical levels of this artifact as described within this artifact.
Degree of completeness (elaboration) and quality (refinement)
Individual circumstances will dictate the degree of completeness (including omission) of each level of this
artifact. Decisions on level of detail, focus and completeness will be based on many factors, such as
-
Audience (e.g. business people, IT Architects, or Developers)
-
Purpose (is it to be fully specified and configured or a generalized reference pattern?)
-
Completeness (is it early in a project's life, or a finished artifact?)
The degree of completeness reached (or required) will also be dependent on the development process (e.g. waterfall,
iterative, etc.). The levels of this artifact elaborate through degrees of completeness towards their completed
states while remaining synchronized and consistent with one another at each major project "milestone".
Varying depth of detail
As well describing the operational aspect of a complete IT system, it is often helpful to develop this artifact showing
greater detail for particular parts of the system. For example:
-
This artifact may model a whole IT system as one or two nodes on the overall model, but a further more detailed
representation of parts of the IT system in a particular location may also be constructed.
-
This artifact may model a single part of an IT system in detail without modeling the whole IT system.
-
This artifact may include the same "recurring pattern" of nodes and/or connections, and, in this case, a separate
artifact may detail the recurring pattern and be referenced by the main artifact.
Cross-cutting viewpoints
This artifact and the logical and physical levels of this artifact may be the focus of a particular viewpoint, at any
degree of elaboration and refinement, to address the concerns of a particular stakeholder. These cross-cutting
viewpoints overlap with one another. For example, views may be constructed on this artifact for the following:
-
Application
-
Technical
-
Performance
-
Capacity
-
Availability and Recovery
-
Security and Privacy Management
-
Operability and Operations Management
-
Systems Management
-
Software Distribution and Installation
-
Distributed Data Management
-
Problem Identification and Management
-
End User Support/Helpdesk
-
Networking
-
Accessibility
-
National Language Support
-
Financial proprietary
-
Archiving
Such filtering does not generally change the elements in the artifact rather it simply enables a clearer focus on some
particular part of it.
Please refer to "An Introduction to the IBM Views and Viewpoints Framework for IT Systems" Whitepaper for further
details on the views and viewpoints framework including the relationship between base and cross-cutting views.
Linkages to other work products
As well as a linkage via Deployment Units with the functional aspect of architecture as embodied in the Component
Model, this artifact has influences and/or is strongly interdependent on other areas that cover the design of the
infrastructure that will implement the operational aspect of architecture. For example:
-
Network Design: affects the application design, middleware selection, component placement, security and privacy,
systems management and overall operational system control.
-
Platform Design; the detailed design and configuration of the platforms that will implement the nodes.
-
Storage Design; the detailed design and configuration of storage which may be shared across multiple platforms.
-
Site & Facilities Design; the detailed design and configuration of the site and facilities in the locations in
which nodes (implemented by platforms) are placed.
-
Systems Management design; through its definition of how the IT system is spread out over locations and what
systems management components and nodes are needed at each location. Selection of a systems management style
is an important decision, which determines:
-
The cost of operations management
-
The cost of software distribution
-
The complexity of system management tooling
-
Potential security and performance of the IT system (ability to satisfy the service level requirements)
-
Existing or planned enterprise-wide IT infrastructure initiatives on which the target system will be
implemented. For example, enterprise wide middleware decisions may well move function, which would otherwise
be duplicated across multiple applications, into a set of shared services, which are usually purchased or part of
an enterprise wide development effort.
|
Tailoring
Impact of not having |
This artifact is the main description of an IT system's operational architecture. Without it, it becomes extremely
difficult to design and develop an IT system of any complexity.
The most obvious consequences will be that some functional requirements will be compromised and some non-functional
requirements will not be met. Without this artifact, this is unlikely to be identified until very late in the project
and either result in unexpected re-work which will impact the delivery schedule, or the system will fail to meet the
desired service level characteristics, and will be more prone to system failures when put into operation.
|
Reasons for not needing | This artifact may be unnecessary if the IT system is very trivial, for example, a standalone PC application for a single
computer. |
More Information
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|