This section provides example descriptions of input and output items referenced in the ADM.
Note that not all the content described here need be contained in a particular input or output. Rather, it is recommended that external references be used where possible; for example, the strategic plans should not be copied into the Request for Architecture Work, but rather the title of the strategic plans should be referenced.
Also, it is not suggested that these descriptions should be followed to the letter. However, each element should be considered carefully; ignoring any input or output item may cause problems downstream.
Finally, note that versioning is used to indicate that input or output items may undergo change as the ADM is executed. As an input or output item is updated, a new version may be produced. The initial version is named V1, and subsequent versions are named V2, V3, etc.
Refer to www.cio-dpi.gc.ca/btep-pto/documents/2004/templates-gabarits/template-gabarit_e.asp.
A typical Architecture Design and Development Contract includes:
Introduction and background
The nature of the agreement
Scope of the architecture
Architecture and strategic principles and requirements
Conformance requirements
Architecture development and management process and roles
Target architecture measures
Defined phases of deliverables
Prioritized joint workplan
Time window(s)
Architecture delivery and business metrics
A typical Business Users' Architecture Contract includes:
Introduction and background
The nature of the agreement
Scope
Strategic requirements
Conformance requirements
Architecture adopters
Time window
Architecture business metrics
Service architecture (includes Service Level Agreements (SLAs))
This contract is also used to manage changes to the enterprise architecture in Phase H (see Phase H: Architecture Change Management).
See also Book 3: Architecture Contracts.
A tool for assisting in the production of organization-specific architectures. An architecture framework consists of a Technical Reference Model, a method for architecture development, and a list of component standards, specifications, products, and their inter-relationships which can be used to build up architectures.
See Book 3: Architecture Principles for guidelines and a detailed set of generic architecture principles.
Includes the following:
Business Principles (Business Principles)
Data Principles (Data Principles)
Application Principles (Application Principles)
Technology Principles (Technology Principles)
Architecture Reports will be developed for each architecture - Business, Data, Applications, and Technology.
An Architecture Report summarizes what was done and the key findings.
The Architecture Vision expresses the conceptual enterprise architecture to meet the needs of the Board directive. It includes:
A typical Business Architecture includes:
Baseline Business Architecture
Business goals, objectives, and constraints
Business requirements and key system and architecture drivers
Business return given required changes
Assumptions (e.g., business, financial, organizational, or required technical functionality)
Business Architecture principles
Business Architecture models
Organization structure
Business functions
Business roles
Correlation of organization and functions
Business Architecture building blocks list (e.g., business services)
Business Architecture building blocks models
Candidate solution building blocks list
Candidate solution building blocks models
Relevant business process descriptions, including measures and deliverables
Technical requirements (drivers for other architecture work)
Business policies are underwritten by the Board.
The Business Scenario technique is one tool/technique that could be used to develop the Architecture Vision.
Business Scenario reports contain the results of Business Scenario workshops and other tools and techniques. A typical Business Scenario/Architecture Vision includes:
Problem description
Purpose of scenario
Detailed objectives
Environment and process models, including:
Process description
Process steps mapped to environment
Process steps mapped to people
Information flow
Actors and their roles and responsibilities, including:
Human actors and roles
Computer actors and roles
Automation requirements
Resulting architecture model, including:
Constraints
Architecture principles
Architecture supporting the process
Stakeholder requirements mapped to architecture
Business strategy includes:
The culture of the scoped enterprise may need to be redefined, particularly if different organizations and teams are merged or interwork together.
The requirements may reflect geographic, language, social, and religious needs that should be considered in the new scoped enterprise.
Enterprise architecture measures include:
These measures must be able to provide:
All artifacts must have explicit traceability to Business Architecture artifacts (especially/at least to business functions) and thus traceability to the business strategy.
TBA
Comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum. Together these are a range of definitions with increasing specificity, from foundational definitions and agreed enterprise strategies all the way to architectures and implementations in specific organizations. Such coexistence of abstraction and concreteness in an enterprise can be a real source of confusion. The Enterprise Continuum also doubles as a powerful tool to turn confusion and resulting conflicts into progress.
The Enterprise Continuum is defined in Book 3: Enterprise Continuum. It also includes:
The gap analysis technique is used to assess what the existing enterprise architecture does and does not support, or where it is deficient.
A typical Impact Analysis includes:
Project list
Name, description, and objectives of each impacted project
Prioritized list of impacted projects to implement the proposed architecture
Time-oriented Migration Plan
Benefits of migration (including mapping to business requirements)
Estimated costs of migration options
Implementation recommendations
Criteria measures of effectiveness of projects
Risks and issues
Solution Building Blocks (SBBs) - description and model
The Information System Architecture comprises:
Investment requirements address infrastructure changes and new investments.
These are the total investment requirements which may have to be split into at least two parts - business and IT - depending on the investment management and budget management processes of the organization.
There will probably be an IT strategy process and cycle for change management. The requirements may need to be formalized and referenced against the strategy, or they may be simple statements of needs, preferably with a planning timescale.
A typical new technology report includes:
New developments in potentially relevant technology
Product information includes:
Functional descriptions of products that are candidates for the implementation
Architectural descriptions of elements that are candidates for the implementation
Relationship profiles define key information about the relationships between the stakeholder or groups of stakeholders within the new enterprise.
Relationship profiles may be categorized to identify the level of impact and sharing of investment, resources, and contribution expected between the stakeholders and within the work area. For example:
Seconded resources
Priorities
Impacted business objectives
Potential revenue impacts and returns
Relationship profiles may also include the decision-making processes and governance processes that the stakeholders need to conform with. For example:
Staff meetings
Reporting requirements
External influencers
Business returns
The Request for Architecture Work includes:
Organization sponsors
Organization's mission statement
Business goals (and changes)
Strategic plans of the business
Time limits
Changes in the business environment
Organizational constraints
Budget information, financial constraints
External constraints, business constraints
Current business system description
Current architecture/IT system description
Description of developing organization
Description of resources available to developing organization
For Existing Business Programs and Projects:
A request for change will normally conform with the change management processes supported by the business program and projects. For example, a program office may be assigned to a business program with some specific methodologies for interacting and defining change requests to projects; e.g., PRINCE 2.
In other instances, an informal request can be made through presentations, meetings, and memos.
TBA
A typical Requirements Impact Statement includes:
Reference to specific requirements
Stakeholder priority of the requirements to date
Phases to be revisited
Phase to lead on requirements prioritization
Results of phase investigations and revised priorities
Recommendations on management of requirements
Repository reference number
Re-usable Architecture Building Blocks (ABBs) include:
Architecture documentation and models from the enterprise's Architecture Continuum
Understanding and qualifying stakeholder expectations is an important first step in gaining their buy-in to the steps required to achieve the business directive and initiative goals.
Stakeholder profiles define key information about the stakeholder or groups of stakeholders that will be critical to the initiative/directive.
The profiles may be categorized to identify the level of impact and contribution expected by that stakeholder. For example:
Name
Contact details
Roles
Key relationships
Personal objectives
Skills and knowledge
Stakeholder profiles may also be linked with the relationship profiles to identify the decision-making processes and governance processes with which the stakeholder(s) need to conform. For example:
Staff meetings
Reporting requirements
External influencers
Business returns
The Statement of Architecture Work defines the scope and constraints and a plan for the architectural work, including:
Statement of work title
Project request and background
Project description and scope
Architecture Vision
Managerial approach
Change of scope procedures
Responsibilities and deliverables
Acceptance criteria and procedures
Project plan and schedule
Support of the Enterprise Continuum
Signature approvals
Technical requirements (drivers for the Technology Architecture work) include identifying, categorizing, and prioritizing the implications for work in the remaining architecture domains; for example, by a dependency/priority matrix. (For example, guiding trade-off between speed of transaction processing and security.) List the specific models that are expected to be produced (for example, expressed as primitives of the Zachman Framework).
A typical Technology Architecture includes:
Baseline Technology Architecture
Objectives and constraints
Technology requirements and key system and architecture drivers
Assumptions (e.g., business, financial, organizational, or required technical functionality)
Technology Architecture model(s)
Architecture Building Block (ABB) models of views (minimally a model of functions and a model of services)
Architecture Building Block (ABB) models of service portfolios (enterprise-specific framework)
Technology Architecture specification
Per-architecture building block:
Details of the technical functionality
Fully defined list of all the standards
Description of building block at the levels necessary to support implementation, enterprise-wide strategic decision-making, and further iterations of the architectural definition process
Rationale for decisions taken that relate to the building block, including rationales for decisions not to do something
Specification identifying the interworking with other building blocks and how they do so
Guidelines for procuring
Standards summary list
Requirements traceability
Acceptance criteria
Criteria for choosing specifications
Criteria for selection of portfolios of specifications
Criteria to test merits of architecture (key question list)
Report on cost/benefit analyses
Report on how the proposed architecture meets the business goals and objectives
Criteria response answers to key question list to test merits of architecture
Gap report
Report on gap analysis
Report of gap analysis matrix
Mapping of the architectures in the Enterprise Continuum
Change requests for extensions or amendments to related architectures
A view is a representation of a whole system from the perspective of the selected viewpoints addressing key stakeholder concerns; e.g., risk management.
See also Book 3: Developing Architecture Views.