Infrastructure Architecture Work Product for [XYZ Project]

Author: [Author Name]Date: [Date]

Version: [Version Number]

Filename: document.doc

document.doc

1 Document Control

1.1 Change History

Version Author Date Change Description

1.2 Security ClassificationThis document is classified as [Unclassified, Internal Use Only, Confidential, etc].

document.doc

2 Introduction

This document captures the Infrastructure Architecture for [insert project or scope of the component].

[Infrastructure in this architecture method is what physical ‘stuff’ is needed for a particular solution. Components, data and integrations all run on physical (and logical) machines and links. The infrastructure architecture details what physical and logical devices are needed and where components and data reside. Infrastructure is also fundamentally concerned with meeting non functional requirements, such as capacity, performance, availability, recovery, etc.

One curiosity of infrastructure architecture is that software is part of the architecture. Software is ostensibly architectured in the component model. Infrastructure architecture will normally define the operating system and other software used for service delivery and service management purpose which are invisible to end users such as monitoring and backup. There is a hazy line, one example being database software and another being physical devices which perform the function of software such as IBM Datapower boxes which is an ESB in a physical box. Do these examples belong in the component model or the infrastructure architecture? Actually it does not really matter as long as the two architectures agree and that they aren’t forgotten!

Infrastructure architecture is composed of multiple infrastructure components and the documentation is broken into definitions of each component. Infrastructure components can be servers, LPARs, network connections, or software as mentioned above.

Another primary aspect of the architecture must be how service delivery/service management run the infrastructure and are able to support the complete solution and meet all non functional requirements. The architecture must also cover how problems are diagnosed across all components, data and integrations, and how they are recovered in various error and recovery scenarios.]

.

document.doc

3 Infrastructure

3.1 Scope[Describe the scope of the Infrastructure Architecture contained within this document and how it relates to other Infrastructure architecture work products.]

3.2 Infrastructure Architecture Overview Diagram[Add an Architecture Overview Diagram of the infrastructure architecture, what devices will be deployed and how they are logically partitioned, and specifications of those components like server type and/or numbers of cpus, memory, and attached storage space. The architecture must articulate where data and components reside, they may be in multiple locations for resilience or capacity, performance, recovery, capacity, etc reasons. Each component of the infrastructure architecture should be uniquely numbered for easy reference.]

3.3 Infrastructure Component [xxx] – Infrastructure Component Name

Infrastructure ID [A unique reference for each infrastructure component in the document, for instance 001, 002, etc]

Infrastructure Name [The name of the infrastructure component.]Infrastructure Description

[A description of the infrastructure component, what is it for, etc.]

Specification [Specify the infrastructure component. This is the main substance of the infrastructure component description. For instance if the infrastructure components is a server it should state the hardware, racks required, physical storage, memory, LPARs, physical connections, memory, software levels, etc.]

Locations [If required, define where the device will be physically located. This maybe multiple locations.]

Monitoring / Alerting [Define how the component is monitored for failures or predictions of failures]

Recovery [Define how the component is recovered from failure, or how extra capability is added to avoid a predicted failure.]

IT Strategy / Enterprise ArchitectureEnterprise Architecture Standards

[Define any applicable standards to which the infrastructure component must conform. Standards are a form of requirement. Standards may arise from an organisations’ Enterprise Architecture, or from the delivery project itself.]

RequirementsFunctional Requirements

[Define which requirements this infrastructure component implements. This should be cross referenced with Functional Requirements documents.]

Non Functional Requirements

[Define any non functional requirements this infrastructure component solutions.]

Security [Define any security requirements or considerations, for instance who may use or access the infrastructure component and how authorisation and authentication are achieved.]

Controls / Audit [Define any business controls and audit requirements and considerations for the infrastructure component such as logging physical access to server rooms. This should include recording accesses by different types of Actors (human and inhuman) and how the data will support and report on any Business Controls which it may be supporting.

document.doc

Architecture and DesignComponent Architecture

[Define how the infrastructure component fits with the component architecture, which component is considered the trusted source of the data, which components can create, read, update, delete and data.]

Data Architecture [Define how this infrastructure component fits into the data architecture.]Integration Architecture [Define how this infrastructure component fits with the integration

architecture.]Infrastructure Architecture

[Define how the infrastructure component fits with the rest of the infrastructure architecture.]

DevelopmentImplementation [Describe any other considerations for the development team during

implementation.]TestingRequirements [Define how the infrastructure component addresses any testing

requirements including how the integration should be tested for the following test scenarios:

Unit System Integration User Performance Security Production Verification]

DeploymentDeployment Instructions

[Define any deployment considerations and instructions. especially any one off infrastructure component deployments which occur during deployment, for instance to support data migrations. This section may defer to later documentation.]

Service Delivery / Service ManagementService Delivery / Data Management

[Define how the infrastructure component meets any service delivery and service management requirements. Data recovery in disaster or failure scenarios must be covered.

Data Management [Define how the infrastructure component is managed over time. How the data is monitored for quality and consistency and how this is reported and corrected. Define the business owner of the data.http://en.wikipedia.org/wiki/Data_management

DecommissionDecommission Considerations

[Describe any considerations and requirements for the future decommission of the integration.]

Project ManagementScope [If required define the scope of the infrastructure component, however

this is usually not required since the infrastructure component is a definition of scope.]

Resources – Cost Estimate

[If required provide a cost estimate needed to implement the infrastructure component. Be clear to state what is included and excluded from the estimate such as the development effort itself, documentation, testing, etc]

Resources - Effort Estimate

[If required provide an estimate of the resources needed to implement the infrastructure component, usually in man hours. Be clear to state what is included and excluded from the estimate such as the installing OS, physical installation, documentation, testing, etc]

Schedule [If required state any schedule implications, that is any task or time dependencies which may affect the implementation of the infrastructure component.]

Risks and Mitigations [State any risks associated with the infrastructure component and any risk mitigation plans to avoid the risk.]

Issues [State any issues associated with the infrastructure component and

document.doc

current in-flight actions which are attempting to resolve them.]Dependencies [State any dependencies which the infrastructure component has.]Assumptions [State any assumptions made in the architecture of the infrastructure

component.]Skills and Resources [State the resources and associated skills needed to implement the

infrastructure component.]Intellectual Capital [Define any existing intellectual capital which may be reused in the

implementation of the infrastructure component.]Linkage to other Architecture Work ProductsArchitectural Decisions [List any relevant Architectural Decisions and how they affect the design

of the infrastructure component.]Architectural Risks and Mitigation

[List any relevant Architectural Risks raised which are relevant to the infrastructure component and how they may affect the infrastructure architecture if the risks occur.]

Change Cases [List any change cases and their consequence. Change cases are possible and probable changes which will be made at a later date.]

- End of Document –

document.doc