Task: Detail the Operational Model
Detail the operational architecture for a distributed system.
Purpose
  • Develop complete views of the system topology
  • Identify connections between nodes
  • Provide basis for examining non-functional requirements
  • Validate that all the necessary business and technical functionality have been identified
Relationships
RolesPrimary: Additional: Assisting:
InputsMandatory: Optional:
  • None
External:
  • None
Outputs
Main Description

Detail the required operational characteristics and capabilities of the IT system architecture and describe, 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.

Use reference architectures as a source for specification when there is a good fit to the target problem domain.

Steps
Detail logical node specifications

The purpose of this step is to:

  • develop a specification of the functions, configuration and responsibilities of nodes
  • develop a detailed technical specification against which an architect can evaluate alternative products, or even against which technology vendors can submit proposals

Develop a detailed description of each node, which usually includes a table or box diagram that identifies and classifies the software components that run on the node. Components (which may not all be software) may be grouped into deployment units for ease of placement.

The description includes the node's availability, performance, security and other non-functional characteristics. (A non-functional characteristic is what is achieved; a non-functional requirement is what is required).

Detail logical connection descriptions

The purpose of this task is to:

  • understand the requirements for network capabilities needed to support connections between nodes
  • understand ability of connections support workloads

Describe the connections between the system nodes at a logical level. This is usually done in table format using from node/to node columns that are further subdivided by individual communications between the nodes. The specification consists of the following information:

  • The end points (node names) of the connection and the business traffic it supports.
  • A description of the connections and its characteristics. For example, security, data type (e.g. character, image), protocol used and nature of the connection (e.g. messaging).
  • Documentation of the expected workload for each connection in terms of transactions and packet sizes. Traffic is defined in terms of minimum, average and peak traffic expectations and durations.
  • A specification of the availability requirements for the connection
Perform simulations and prototyping to verify design decisions
Review and refine placement of components on logical nodes
Transform the logical operational model into physical model

The physical specification is fully constrained by the limitations of the technology available, geography and the environment. Fine-grained, detailed models and specifications are produced. The operational model at this point is a complete architectural specification of the IT system, including:

  • software products, hardware products and communication connections to enable products to be ordered. This may include upgrades to installed products or connections.
  • a specification of the operational aspect, which so that nodes and connections can be configured, components deployed a brought into operation.
  • new functionality needed to support operational requirements (e.g., instrumentation) to be created, this will typically comprise module specifications which can be taken by a developer or programmer and developed and unit-tested. The output of this task is an elaboration of the node descriptions, connection descriptions, system management descriptions and middleware specifications. Product selection methods and techniques are used to make choices where complexity or risks are factors.

Develop the physical specifications for nodes and connections.

Evaluate and select products.

Refine the operational model

This step is performed to ensure the right balance between requirements and practicality for the operational model in the delivery of the solution's functional and non-functional requirements.

It is almost inevitable that, while assessing the operational model's ability to achieve the various non-functional requirements, some shortfall or other will be identified, which will require the operational model to be changed. Possibly, it will prove to be impossible, within practical bounds, to achieve all aspects of the solution's non-functional requirements. For example, the delivery of very high levels of availability may compromise the solution's ability to deliver sub-second response times.

This sub-task assesses the implications of these conclusions for the operational model and, where necessary and practical enhances the design. Alternatively, where such changes are not considered desirable or where requirements are found to be in conflict, this task ensures the requirements are refined and balanced to "the art of the possible".

Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
Key Considerations
The logical level of the operational model is developed in parallel with the physical operational model and is tightly coupled with both its development and also the development of the component model. Therefore decisions made when developing the logical operational model may result in changes to both the physical operational model and the component model.

The state of the operational model which needs to be reached at the end of this task is dependent on the context in which it is being developed, the level of confidence that needs to be achieved in the architecture and design, and the degree of accuracy of estimates of resources to further develop the operational model.