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".
|
|