Vision

High-level, aspirational view of the VMARC PM. The purpose of the vision is to agree at the outset what the desired outcome should be, so that further focus is on the critical areas to validate feasibility. Providing an VMARC PM Vision also supports stakeholder communication by providing an executive summary version of the full VMARC PM Definition.

Architecture Vision

<<Note: Tailoring to suit a VMARC client and project situation.>>

 

Contents

  1. Purpose of this Document
  2. Principle Template
  3. Summary of Principles
  4. Business Principles
  5. Data Principles
  6. Application Principles
  7. Technology Principles

 

Project Information

Project Name: Project XXX
Prepared By: Document Version No: 0.1
Title: Architecture Vision 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)

Version History

Version
Number
Version
Date
Revised By Description Filename

1 Purpose

The Architecture Vision is created early on in the project lifecycle and provides a high-level, aspirational view of the end architecture product. The purpose of the vision is to agree at the outset what the desired outcome should be for the architecture, so that architects can then focus on the critical areas to validate feasibility. Providing an Architecture Vision also supports stakeholder communication by providing an executive summary version of the full Architecture Definition.

It may be that the Architecture Vision 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 an Architecture Vision and can be adapted to align with any TOGAF adaptation being implemented.

 

2 Problem Description

2.1 Stakeholders and their Concerns

<<The purpose of this section is to describe the stakeholders for the vision together with any concerns they may have.>>

Stake Holders concerns:

  1. Business needs to be able to effectively manage project data
    1. project data re-use should become a norm
  2. PM Solution should clearly describe the solutions

2.2  List of Issues/Scenarios to be Addressed

<<The purpose of this section is to define the business context and problem description for which the vision of the target architecture has been produced.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business vision statement for the target architecture
  2. Pictorial representation of business context
  3. Change drivers and opportunities behind this vision for the target architecture>>

2.3 Business Vision Statement

<<The purpose of this section is to define the business vision statement of the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business vision statement(s) for the target architecture>>

2.4 Business Vision Diagram

<<The purpose of this section is to provide one or more suitable pictorial representation(s) that explain the business context and business problem. They are required in order to obtain senior executive engagement with this activity.

Mandatory/optional: This section is optional but recommended.

In terms of quality criteria, this section should make clear:

  1. Diagram(s) explaining the problem statement for the target architecture
  2. Description of business vision diagram>>

2.5 Change Drivers & Opportunities

<<The purpose of section is to identify the change drivers and opportunities behind this vision for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Change drivers that will impact decisions made for the target architecture
  2. Opportunities that can be leveraged for the target architecture>>

3  Detailed Objectives

<<The purpose of this section is to describe the detailed objectives that need to be fulfilled by the target architecture. The previous section looks at the business problem, whereas this section determines the objectives, for the architecture solution, that will resolve the business problem.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business objectives to resolve the business problem
    1. Project Data Management
  2. Technology objectives (such as decommissioning)
    1. File Management
    2. Design Reuse
    3. Revision Management
    4. Secure File Archiving
    5. Regulatory compliance

 

4 Environment and Process Models

<<The purpose of this section is to outline the environment and process models that are in scope for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business processes that are in scope for the vision
  2. Business and technology environment in scope for the vision
  3. Users who interact with the business process
  4. Information flows for the business processes>>

4.1 Process Description

<<The purpose of this section is to outline the business processes that are in scope and thus impacted by the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business processes that are in scope for the vision
  2. If required, high-level diagram(s) of business processes
  3. Descriptions for the business process diagrams>>

4.2 Process Steps Mapped to Environment

<<The purpose of this section is to cross-reference the business processes, in scope, to the business and technology environments.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business environment in scope for the vision
  2. Technology environment in scope for the vision>>

4.3 Process Steps Mapped to People

<<The purpose of this section is to cross-reference the business processes to business actors; i.e., business users. Business actors/users are those users who interact with a business process.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Business users involved with the business processes in scope>>

4.4 Information Flow

<<The purpose of this section is to describe the information flows that correspond to the business processes in scope for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Information flows for the business processes in scope>>

5 Actors and their Roles and Responsibilities

<<The purpose of this section is to describe the system users/actors in scope for the target architecture. System actors/users are those users who interact with a system. They can be human or a system/computer.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Human (system) actors and roles in scope for the target architecture
  2. Computer (system) actors and roles in scope for target architecture
  3. Any other system actor-oriented requirements in scope for the target architecture>>

5.1 Human Actors and Roles

<<The purpose of this section is to define the human actors and roles in scope for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Human actors and roles in scope for the target architecture>>

5.2 Computer Actors and Roles

<<The purpose of this section is to define the computer actors and roles in scope for target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Computer actors and roles in scope for target architecture>>

5.3 Requirements

<<The purpose of this section is to define any other actor-oriented requirements in scope for the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Any other actor-oriented requirements in scope for the target architecture>>

5.4 Resulting Architecture Model

 

6 Resulting Architecture Model

<<The purpose of this section is to describe the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. High-level diagram(s) of the target architecture
  2. Description of the diagram(s)
  3. Requirements that map onto the target architecture
  4. Constraints that impact the target architecture
  5. Principles that can be leveraged in order to define the target architecture>>

6.1 Constraints

<<The purpose of this section is to describe the constraints that impact the target architecture.

Mandatory/optional: This section is mandatory if constraints need to be taken into consideration.

In terms of quality criteria, this section should make clear:

  1. Constraints that impact the target architecture>>

6.2 IT Principles

<<The purpose of this section is to describe the principles that can be leveraged in order to define the target architecture.

Mandatory/optional: This section is mandatory if existing principles need to be taken into consideration.

In terms of quality criteria, this section should make clear:

  1. Principles that can be leveraged in order to define the target architecture>>

6.3 Architecture Supporting the Process

<<The purpose of this section is to describe the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. High-level diagram(s) of the target architecture
  2. Description of the diagram(s)>>

6.4 Requirements Mapped to Architecture

<<The purpose of this section is to describe the high-level business and technology requirements that map onto the target architecture.

Mandatory/optional: This section is mandatory.

In terms of quality criteria, this section should make clear:

  1. Existing business requirements such as goals and objectives that map onto the target architecture
  2. Existing technology requirements that map onto the target architecture>>

7 End Vision Statement

<<A statement executive summary of the end vision of the architectural effort.

Begin with the end in mind!>>