Task: Outline the Operational Model
Develop a high level overview of the operational system architecture.
Purpose
  • Provide a basis for assessing the viability of implementing the system
  • Gain an understanding of the geographical distribution and operational complexity of the system
  • Provide a basis for early effort and cost estimates
Relationships
RolesPrimary: Additional: Assisting:
InputsMandatory: Optional:
  • None
External:
  • None
Outputs
Main Description

Develop an overview of how the software is deployed. For example, determine if the system needs to be accessed remotely, or has requirements that suggest distribution across multiple nodes. Some sources of information to consider are:

  • users (at locations), defined in user profiles and use cases
  • organization of business data
  • service level requirements
  • constraints (such as requirements to interface with legacy systems)

Provisionally assign components and data to nodes, and indicate how users access components that access data. Detailed specification of nodes and connections is deferred, except where they are important for estimating or assessing viability. Existing assets can be used if appropriate assets are available.

Although this is the first operational model produced in the project, and it is produced quickly and at a high level, it might identify actual hardware and software products if they are known, or if it is important to make these selection decisions at this time.

If a non-trivial distributed system is required, then deployment units can be specified by grouping components (and their different operational facets). This significantly reduces the number of things that need to be placed and the level of complexity in developing the operational architecture aspect of a complex, distributed IT system.


Steps
Outline logical node descriptions

Develop an initial 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) are often 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.). Logical nodes ignore many technological limitations and focus on application software components, deferring treatment of middleware and other software.

Detailed specification of nodes and connections is deferred, except where they are important for estimating or viability assessment.

Place components on nodes

Place components provisionally on nodes. The operational model must be capable of supporting users at locations performing use cases which access components which access data, while satisfying non-functional requirements and constraints.


Outline logical connection descriptions

The two purposes of this step are to:

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

Develop an initial description of the connections between the system nodes at a logical level. This should include:

  • The end points (node names) of the connection.
  • The business traffic the connection supports.
  • A specification of the availability requirements for the connection.
Review the results

Validate that the operational model supports users (especially users at remote locations if this is required) performing typical use cases while satisfying non-functional requirements and constraints. Validate that the nodes and connections are adequate to support the interactions between components on different nodes, and between components and their stored data.

Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information