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.
Domains: Architecture
Purpose

This artifact provides:

  1. 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.
  2. 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
RolesResponsible: Modified By:
TasksInput To: Output From:
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
NotationThis 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.
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 needingThis artifact may be unnecessary if the IT system is very trivial, for example, a standalone PC application for a single computer.
More Information