Roadmap

Scope and approach that will be used to complete IT architecture of the VMARC PM project. The Statement of IT Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services. In general, all the information in this document is at a high level.

Statement of IT Architecture Work

Table of Contents

1        Purpose of this Document

2        Statement of Architecture Work

3        Objectives and Scope

4        Roles and Responsibilities

5        Architecture Approach

6        Work Plan

7        Risks and Mitigations

8        Acceptance Criteria and Procedures

9        Signature Approvals

 

Document Information

Project Name: VMARC PM
Prepared By: Document Version No: 0.1
Title: Statement of Architecture Work Document Version Date:
Reviewed By: Review Date:

Distribution List

From Date Phone/Fax/Email

 

To Action* Due Date Phone/Fax/Email

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Document Version History

Version
Number
Version
Date
Revised By Description Filename

Purpose of this Document

This document is a Statement of IT Architecture Work for the VMARC PM.

The Statement of Architecture Work defines the scope and approach that will be used to complete an IT architecture project. The Statement of IT Architecture Work is typically the document against which successful execution of the architecture project will be measured and may form the basis for a contractual agreement between the supplier and consumer of architecture services. In general, all the information in this document should be at a high level.

It may be that the Statement of Architecture Work is documented using a wiki or as an intranet rather than a text-based document. Even better would be to use a licensed TOGAF tool that captures this output.

<<This template shows “typical” contents of a Statement of Architecture Work and can be adapted to align with any TOGAF adaptation being implemented.>>

 

Statement of Architecture Work

Project Request and Background

 

Project Description and Scope

 

Overview

 

Strategic Alignment

 

Objectives and Scope

Objectives

The business objectives of this architecture work are as follows:

Business Objective Notes
<<Business Objective 1>> <<Notes>>
<<Business Objective 2>> <<Notes>>

<<Refer back to the Request for Architecture Work and restate/refine.>>

Scope

 

Stakeholders, Concerns, and Views

The following table shows the stakeholders who will use this document, their concerns, and how the architecture work will meets those concerns through the delivery of a number of views.

Stakeholder Concern View
VM <<Describe what aspects of the architecture will be of interest to this stakeholder.>> <<List any views to be created to address this stakeholder’s concerns.>>

Managerial Approach

 

Change of Scope Procedures

 

Roles and Responsibilities

Governance Structure

<<Outline the team structure – e.g., simple organization chart showing roles and reporting lines.>>

Project Processes

<<Outline key project processes – e.g., regular meetings, steering boards, document repository, configuration management, quality assurance, escalation procedure, change procedure.>>

Roles and Responsibilities (RACI)

<<Where relevant, add a RACI chart – showing key stakeholders and activities, and who is (R)esponsible, (A)ccountable, (C)onsulted, (I)nformed in each case.>>

 

IT Architecture Approach

Architecture Process

The TOGAF Architecture Development Method (ADM) defines a best-practice methodology for architecture development. However, not all phases are necessarily equally relevant to every project. The table below describes the usage of the ADM for this particular project.

TOGAF full ADM

Phase In/Out Notes
Preliminary
A – Architecture Vision
B – Business Architecture <<Baseline and/or Target?>>
C – Information Systems Architecture <<Baseline and/or Target?>>
D – Technology Architecture <<Baseline and/or Target?>>
E – Opportunities and Solutions
F – Migration Planning
G – Implementation Governance
H – Architecture Change Management
Requirements Management

<<Provide any further notes on phasing, iterations, etc.>>

5.2            IT Architecture Content

The image bellow represents the full TOGAF IT Architecture Content Framework (ACF) provides a best-practice categorization of IT architecture content. However, not all items are necessarily equally relevant to every project. The table below describes the content areas relevant to this particular project.

TOGAF full Architecture Content

Content Area In/Out Notes
Architecture Principles, Vision, and Requirements <<Note which sub-categories will be covered>>
Business Architecture <<Note which sub-categories will be covered>>
Information Systems Architecture – Data <<Note which sub-categories will be covered>>
Information Systems Architecture – Applications <<Note which sub-categories will be covered>>
Technology Architecture <<Note which sub-categories will be covered>>
Architecture Realisation <<Note which sub-categories will be covered>>

<<Provide any additional insight into stakeholder concerns and particular views that will be created as a result.>>

Relevant Methodologies and Industry Standards

 

Support of the Enterprise Continuum

Other points of note regarding the IT architecture approach include:

<<Optional section – describe any other key points in terms of categorizing the architecture work.>>

<<Points to consider include:

  • Level of detail (strategic/segment/capability)
  • Time period (what time period does the architecture cover?)
  • Subject matter (what subject matter domain is to be covered?)
  • Level of abstraction (e.g., concrete representation of solutions, or more abstract reference architecture)
  • Baseline versus target (is the emphasis on documenting the current baseline, or proposing a future target architecture? In what sequence will these activities be approached?)
  • Iteration – any use of iteration in the ADM?
  • Partitioning – any relationships to other architecture work within a partitioned environment?>>

 

Work Plan

This section describes all activities and deliverables for the architecture work.

<<Provide a plan for the architecture work.>>

Work Item 1

Activities

 

Deliverables

The following work products will be created as a result of this architecture work:

  • <<Work Product 1 Name>>

<<Description of work product 1, etc.>>

  • <<Work Product 2 Name>>

<<Description of work product 2, etc.>>

Work Item 2

Activities

Deliverables

 

Work Item n

 Activities

Deliverables

Communications Planning

Events

Channels

Formats

Content

 

Duration and Effort

 

Collaboration

 

Project Plan and Schedule

Kan Ban project board.

Here is a good and simple (and important) explanation on what is “Kan Ban”.

Risks and Mitigations

Risk Analysis

ID Risk Severity Likelihood Mitigation Owner
1.          
2  

<<Note: The above table provides a simple risk assessment for small projects. More complex risk management methodologies/spreadsheets may be substituted where relevant.>>

Assumptions

The following table summarizes assumptions for this Statement of IT Architecture Work:

ID Assumption Impact Owner
1.      

 

Acceptance Criteria and Procedures

Metrics and KPI’s

In addition, the following metrics will be used to determine the success of this IT architecture work:

Metric Measurement Technique Target Value Rationale/Further Notes

<<Refer back to the Request for Architecture Work and restate/refine.>>

Acceptance Procedure

<<Describe the process to be used for acceptance/sign-off.>>

 

Signature Approvals

Signature Date