Artifact: Physical Technology Infrastructure Component
Physical Technical Infrastructure Components describe real components.
Description

Physical Technical Infrastructure Components are implementation dependent groups of Logical Technical Infrastructure Components. The grouping criteria are derived from the Principles and Constraints.

The Physical Technical Infrastructure Components also defines the key connectivity points for the solution and provides a view of the real information flows across the architecture thereby allowing more precise and complete view of capacity requirements.

Specific Artifact Attributes

Physical Technology Infrastructure Component attributes

Grouping Criteria

List of the principles that indicate the rationale of the component <ID>, <Name of the Principle>; <ID>, <Name of the Principle>

Logical Components

List of related Logical Component(s) that this Physical Component represents. <ID>, <Name of the Component>; <ID>, <Name of the Component>

Trigger

The events or initiators that cause this component to be started/consumed (will be evident from the services that comprise this component).

KPIs

Identify the KPIs for the component (will be evident from the services that comprise this component).

Confidentiality Classification

Classify and explain the level of Information Confidentiality to be supported by this component. Confidentiality Classification is based on the risk, specifically the impact, of unauthorised disclosure or intelligible interception. Confidentiality Classification is thus the protection level needed of sensitive information from unauthorised disclosure or intelligible interception. The classification should follow the organization security or risk management guidelines; or define and use a High/Medium/Low categorization if one is not available.

Integrity Classification

Classify and explain the level of Information Integrity to be supported by this component. Integrity Classification is based on the risk, specifically the impact, of not having accurate or complete information. Integrity regards safeguarding the accuracy and completeness of information (and thus processes, IT systems and computer software). The classification should follow the organization security or risk management guidelines; or define and use a High/Medium/Low categorization if one is not available.

Availability Classification

Classify and explain the level of Information Availability to be supported by this component. Availability Classification is based on the risk, specifically the impact, of not having information available (accessible or available in time). Availability Classification regards guaranteeing that information and vital services are accessible (accessibility) to authorised users when required (timeliness) The classification should follow the organization security or risk management guidelines; or define and use a High/Medium/Low categorization if one is not available.

Uniqueness Classification

Classify and explain the level of Information Uniqueness to be supported by this component. Uniqueness Classification is based on the risk, specifically the impact, of not having unique or unambiguous information about a specific subject. The classification should follow the organization risk management guidelines; or define and use a High/Medium/Low categorization if one is not available.

Consistency Classification

Classify and explain the level of Information Consistency to be supported by this component. Consistency Classification is based on the risk, specifically the impact, of not having consistent information (consistent within itself or with other information across the organization). The classification should follow the organization risk management guidelines; or define and use a High/Medium/Low categorization if one is not available.

Compliance Classification

Classify and explain the level of Information Compliance to be supported by this component. Compliance Classification is based on the risk, specifically the impact, of not complying to relevant legislation, policies or standards. The classification should follow the organization risk management guidelines; or define and use a High/Medium/Low categorization if one is not available.

Service window

Or opening hours, describes when the component should be available.

Response time

Describes the normal/average and maximum time to fully process a service request for the component.

Throughput

Describes the required throughput (number of requests per period over time) expressed in average amounts for the component.

Throughput period

Describes the throughput period. <Second/ Minute/ Hour/ Day/ Week>

Scalability

Describes the required throughput (number of requests per period over time) expressed in maximum amounts for the component.

Scalability period

Describes the scalability period. <Second/ Minute/ Hour/ Day/ Week>

MTTR

Describes the mean time to repair of the service in case of incidents. (MTTR is behavioural aspect and is specifically linked to the service.)

MTBF

Describes the mean time between failures of the component (MTBF is behavioural aspect and is specifically linked to the component)

Communication mechanism

Describes the communication mechanisms of the component. Business component mechanisms: Click, Call, Face, Fax, Voice, Mail, email, SMS. Business information service mechanism: Automated, Non-automated. Information System component mechanisms: ‘Message based’: Fire&Forget, Request/Reply, or ‘File based’.

Component Quality Characteristics

A description of the quality characteristics that the component is expected to conform to. This will be an aggregated profile of the characteristics of the services that comprise this component (Quality of information, error handling).

Relations/Context
Physical Technology Infrastructure Components are derived in the Technology Infrastructure aspect area of the Physical Abstraction layer, including components derived with the application of the Governance and Security special views.

Hints and Tips
Criteria for physical level grouping are more complex than at the logical abstraction level. Real world constraints may be significant whether it be because of package selection, established configurations and standards for infrastructure components. Governance or security aspects will be key factors. The Constraints and Assumptions will also affect the grouping criteria and need to be validated and considered. The current state technology context will have a significant impact and in many cases, will form the basis for defining the new architecture particularly from a standards perspective.

Don’t be tempted to extend the attribute section to include all the standard/product details, create a cross reference to a standards catalogue since there will be many components to one standard and the standards are likely to change more frequently than the components thereby creating a major update activity.