TOGAF

Structure of the TOGAF Architecture Development Method (ADM).^[1]

The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture which provides an approach for designing, planning, implementing, and governing an enterprise information architecture.^[2] TOGAF has been a registered trademark of The Open Group in the United States and other countries since 2011.^[3]

TOGAF is a high level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It tries to give an overall starting model to information architects, which can then be built upon. It relies heavily on modularization, standardization, and already existing, proven technologies and products.

Overview[edit]

An architecture framework is a set of tools which can be used for developing a broad range of different architectures.^[4] It should:

• describe a method for defining an information system in terms of a set of building blocks
• show how the building blocks fit together
• contain a set of tools
• provide a common vocabulary
• include a list of recommended standards
• include a list of compliant products that can be used to implement the building blocks

TOGAF is such an architecture framework.

The ANSI/IEEE Standard 1471-2000 specification of architecture (of software-intensive systems) may be stated as: "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

However TOGAF has its own view, which may be specified as either a "formal description of a system, or a detailed plan of the system at component level to guide its implementation", or as "the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time."

The Architecture Development Method (ADM) is core of TOGAF which describes a method for developing and managing the lifecycle of enterprise architecture.

TOGAF topics[edit]

Enterprise architecture domains[edit]

TOGAF is based on four interrelated areas of specialization called architecture domains:

• Business architecture which defines the business strategy, governance, organization, and key business processes of the organization
• Applications architecture which provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization with the frameworks for services to be exposed as business functions for integration
• Data architecture which describes the structure of an organization's logical and physical data assets and the associated data management resources
• Technical architecture, or technology architecture, which describes the hardware, software, and network infrastructure needed to support the deployment of core, mission-critical applications

Architecture Development Method[edit]

The Architecture Development Method (ADM) is applied to develop an enterprise architecture which will meet the business and information technology needs of an organization. It may be tailored to the organization's needs and is then employed to manage the execution of architecture planning activities.^[13]

The process is iterative and cyclic. Each step checks with Requirements. Phase C involves some combination of both Data Architecture and Applications Architecture. Additional clarity can be added between steps B and C in order to provide a complete information architecture.

Performance engineering working practices are applied to the Requirements phase, and to the Business Architecture, Information System Architecture, and Technology architecture phases. Within Information System Architecture, it is applied to both the Data Architecture and Application Architecture.

Enterprise Continuum[edit]

The Enterprise Continuum is a way of classifying solutions and architectures on a continuum that ranges from generic foundation architectures through to tailored organization-specific both within and outside the Architecture Repository.^[14] These include architectural models, architectural patterns, architecture descriptions, and other artifacts. These artifacts may exist within the enterprise and also in the IT industry at large.

The Enterprise Continuum consists of both the Architecture Continuum and the Solutions Continuum. The Architecture Continuum specifies the structuring of reusable architecture assets and includes rules, representations, and relationships of the information system(s) available to the enterprise. The Solutions Continuum describes the implementation of the Architecture Continuum by defining reusable solutions building blocks.

How To Enforce Your Enterprise Architecture With TOGAF

So you have defined your architectural vision, strategy and blueprints — what's next? 

EA Life Cycle

Enterprise Architecture(EA) has little value without implementation and governance. Simply communicating the EA and expecting the organization to comply is ineffective. 

Once the EA is defined, it is necessary to govern that architecture through implementation. 

 

EA is a cyclical process of EA definition, scope identification, project governance and feedback loops. 

Enter TOGAF

The TOGAF Architecture Development Method (ADM) defines the EA life cycle in a series of steps A-H. 

 

TOGAF Step G - Implementation and Compliance provides a framework to enforce the EA. 

TOGAF Implementation and Compliance

Implementation and Compliance takes place at the project level. It takes the EA as an input and produces two work items: solution building blocks and compliance assessment. 

 

Solution Building Blocks 
Early-on in the project an enterprise architect should work with the solution architects to identify building blocks from the EA blueprint will be incorporated in the solution. 

Compliance Assessment 
Periodic compliance reviews ensure that project solutions are in-line with enterprise architecture. Project stakeholders such as project managers, IT managers, solution architects and lead developers should be accountable to compliance. 

Compliance assessments include a series of checklists for hardware, operating systems, software services, middleware, applications, information management, security, systems, system engineering, methods and tools. 

101 Enterprise Architecture Interview Questions

        posted by John Spacey, Simplicable, January 11, 2013 

It is not easy to interview an Enterprise Architect (EA). Enterprise Architects are an organization's most important technical influencers and innovators. A good Enterprise Architect should have the following skills: 



That's a lot to go though in an interview. Here are a few questions that may provide a starting point. 

Core Enterprise Architecture 
1. What is Enterprise Architecture? 

2. Typically, what stakeholders would be involved in the Enterprise Architecture lifecycle? 

3. What is an architectural pattern? 

4. How do you manage changes to the Enterprise Architecture in 
a turbulent environment? 

5. What recent technology trends are important to Enterprise Architecture? 

6. What are the most important artifacts of an Enterprise Architecture? 

7. Walk me through a time when you led Enterprise change. 

8. What personal qualities make for a good Enterprise Architect? 

9. How do you sell the benefits of SOA to executives? 

10. How does Enterprise Architecture support business goals and strategy? 

11. How can you tell if an Enterprise Architecture is comprehensive? 

12. Is it possible to calculate ROI for SOA? 

13. How do you go about identifying the key business activities in an organization’s value-chain? 

14. Can you give an example where you created a architectural roadmap? How did you align project solutions with the roadmap? 

15. Can you give an example where you championed a project? How did you justify the project to the business? 

16. What was the most complex project in which you assumed a leadership role? What challenges did you face? 

17. How would you go about appraising an Enterprise Architecture in terms of completeness of scope? 

18. What metrics can be used to validate conformance of a solution to an architecture? 

19. Can you give an example where you helped establish a IT governance process? 

20. Can you provide an example in which you provided break-through architectural thinking? 

21. Can you give an example where you applied strategic architectural thinking to impact business results? 

22. Can you give an example where you championed a business stakeholders’ requirements? 

23. Is it possible to calculate ROI for Enterprise Architecture? 

24. Can you give an example in which you evangelized architectures and strategies to executives? 

25. Can you give me an example in which you allocated architectural activities to multiple architects? 

26. Can you give an example where you guided an organization’s strategy? 

27. Can you give an example where you pointed out weak links in technical plans? 

28. Can you give an example where you drove a business initiative by promoting cross-organizational participation? 

29. Can you provide examples where you applied different data modeling techniques for different purposes? 

30. Can you provide me an example where you proposed a solution that satisfied business requirements? What architectural alternatives did you consider? 

31. Have you ever introduced a new standard into an organization? What was it? How did you ensure adoption of the standard? 

32. Give me an example where someone challenged your architectural decisions. 

33. What was the most difficult architectural question anyone ever asked you? How did you answer it? 

34. Give me an example where you defined and executed a strategy. 

35. What IT industry trends are you most interested in at the moment? 

36. How do you maintain your skills and stay current with IT trends? 

37. Have you ever helped to mediate opposing architectural viewpoints? 

38. What tools have you used to create and manage Architectural artifacts? 

39. Can you describe a situation where a key decision you made was wrong? How did you correct the situation? 

40. Can you describe a document you created that demonstrated your ability to effectively communicate architectural decisions? Did the document generate two-way communication? 

Enterprise Architecture Frameworks 
41. What is your favorite Enterprise Architecture framework? Why? 

42. Do you have experience with any TOGAF Certified Tools? 

43. What four architecture domains does TOGAF deal with? 

44. What is the TOGAF Enterprise Continuum? 

45. Can you describe the TOGAF Architecture Compliance Review Process? 

SOA Architecture 
46. Can you give me a recent example of your SOA projects? How did you handle security? 

47. What is a SOA service contract and why is it important? 

48. What is the difference between services and components? 

49. What SOA design patterns have you used in the past? 

50. What design principles do you use when architecting SOA services? 

51. How can you achieve loose coupling of services? 

52. How do you define a successful SOA? 

53. What works better top-down or bottom-up service identification? 

54. How can services supporting long running processes be scaled effectively? 

55. How can a SOA avoid redundant service logic? 

Methodologies 
56. What is the difference between agile and scrum? 

57. Give me an example where you worked with stakeholders to document functional and non-functional requirements. How did you prioritize the requirements? 

58. Can you give an example where you worked with a project manager to identify elements of a project plan that put the project plan at risk? 

59. What is a project communication plan? 

60. What is a project charter? What essential elements should be captured in a project charter? 

IT service management 
61. How would you migrate a traditional application to cloud infrastructure? 

62. How might IT service management processes differ between a small-scale and large-scale enterprise? 

63. Can you give an example where you prepared a Risk Assessment for IT Services? 

64. Can you name 3 kinds of SLA? 

65. What is Network Policy Enforcement? 

66. What is a Operational Level Agreement? 

67. What is ITIL? 

68. What is the difference between Incident Management and Problem Management? 

69. What is the difference between Change and Release management? 

70. What are the key activities associated with Capacity Management? 

Security 
71. What is Cross Site Scripting? 

72. Can you give me an architectural overview of public-key cryptography? 

73. From a security perspective, what is more important to focus on: threats or vulnerabilities? 

74. What is the goal of enterprise information security? 

75. What is Federated Identity Management? 

Solution Architecture 
80. What innovative solutions have you created? 

81. How do you version a service inventory? 

82. If you had to both compress and encrypt data for transmission, which would you do first? Why? 

83. Can you explain the bridge pattern? 

84. What is a design pattern? 

85. What is the difference between Object Oriented and Aspect Oriented design? 

86. In Java, when should you use an interface and when an abstract class? 

87. What is the difference between an Abstract Factory and a Factory? (Design Patterns) 

88. What is a UML deployment diagram? 

89. What factors impact project success? 

90. Can you describe the role of a solution architect during the different phases of the SDLC? 

General 
91. Are you a Big Picture thinker? Can you give me an example? 

92. What do you know about our company? 

93. What do you do to build and manage your professional network? 

94. Have you ever worked within an organization that has a siloed structure? How did you deal with it? 

95. What was the best project you ever worked on? How did you contribute? 

96. How do you deal with difficult people? 

97. What are the three tools you need most to do your job? 

98. Can you describe your leadership style? 

99. Have you ever mentored someone? 

100. Where do you see your career 5 years from now? 

101. What is your experience in the area of IT financial management? 

36. Architecture Deliverables

Chapter Contents

36.1 Introduction | 36.2 Deliverable Descriptions

This chapter provides descriptions of deliverables referenced in the Architecture Development Method (ADM).

36.1 Introduction

This chapter defines the deliverables that will typically be consumed and produced across the TOGAF ADM cycle. As deliverables are typically the contractual or formal work products of an architecture project, it is likely that these deliverables will be constrained or altered by any overarching project or process management for the enterprise (such as CMMI, PRINCE2, PMBOK, or MSP).

This chapter therefore is intended to provide a typical baseline of architecture deliverables in order to better define the activities required in the ADM and act as a starting point for tailoring within a specific organization.

The TOGAF Content Framework (see Part IV, 33. Introduction) identifies deliverables that are produced as outputs from executing the ADM cycle and potentially consumed as inputs at other points in the ADM. Other deliverables may be produced elsewhere and consumed by the ADM.

Deliverables produced by executing the ADM are shown in the table below.

Deliverable	Output from...	Input to...
Architecture Building Blocks	F, H	A, B, C, D, E
(see 36.2.1 Architecture Building Blocks)
Architecture Contract	-	-
(see 36.2.2 Architecture Contract)
Architecture Definition Document	B, C, D, E, F	C, D, E, F, G, H
(see 36.2.3 Architecture Definition Document)
Architecture Principles	Preliminary,	Preliminary,
(see 36.2.4 Architecture Principles)	A, B, C, D	A, B, C, D, E, F, G, H
Architecture Repository	Preliminary	Preliminary,
(see 36.2.5 Architecture Repository)		A, B, C, D, E, F, G, H,
		Requirements Management
Architecture Requirements	B, C, D, E, F,	C, D,
Specification (see 36.2.6 Architecture Requirements Specification)	Requirements Management	Requirements Management
Architecture Roadmap	B, C, D, E, F	B, C, D, E, F
(see 36.2.7 Architecture Roadmap)
Architecture Vision	A, E	B, C, D, E, F, G, H,
(see 36.2.8 Architecture Vision)		Requirements Management
Business Principles, Business Goals, and Business Drivers	Preliminary, A, B	A, B
(see 36.2.9 Business Principles, Business Goals, and Business Drivers)
Capability Assessment	A, E	B, C, D, E, F
(see 36.2.10 Capability Assessment)
Change Request	F, G, H	-
(see 36.2.11 Change Request)
Communications Plan	A	B, C, D, E, F
(see 36.2.12 Communications Plan)
Compliance Assessment	G	H
(see 36.2.13 Compliance Assessment)
Implementation and Migration Plan	E, F	F
(see 36.2.14 Implementation and Migration Plan)
Implementation Governance Model	F	G, H
(see 36.2.15 Implementation Governance Model)
Organizational Model for Enterprise	Preliminary	Preliminary,
Architecture (see 36.2.16 Organizational Model for Enterprise Architecture)		A, B, C, D, E, F, G, H,
		Requirements Management
Request for Architecture Work	Preliminary, F, H	A, G
(see 36.2.17 Request for Architecture Work)
Requirements Impact Assessment	Requirements Management	Requirements Management
(see 36.2.18 Requirements Impact Assessment)
Solution Building Blocks	G	A, B, C, D, E, F, G
(see 36.2.19 Solution Building Blocks)
Statement of Architecture Work	A, B, C, D, E, F, G, H	B, C, D, E, F, G, H,
(see 36.2.20 Statement of Architecture Work)		Requirements Management
Tailored Architecture Framework	Preliminary, A	Preliminary,
(see 36.2.21 Tailored Architecture Framework)		A, B, C, D, E, F, G, H,
		Requirements Management

36.2 Deliverable Descriptions

The following sections provide example descriptions of deliverables referenced in the ADM.

Note that not all the content described here need be contained in a particular deliverable. Rather, it is recommended that external references be used where possible; for example, the strategic plans of a business should not be copied into a 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.

36.2.1 Architecture Building Blocks

Architecture documentation and models from the enterprise's Architecture Repository; see Part IV, 37. Building Blocks.

36.2.2 Architecture Contract

Purpose

Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective architecture governance (see Part VII, 50. Architecture Governance). By implementing a governed approach to the management of contracts, the following will be ensured:

• A system of continuous monitoring to check integrity, changes, decision-making, and audit of all architecture-related activities within the organization
• Adherence to the principles, standards, and requirements of the existing or developing architectures
• Identification of risks in all aspects of the development and implementation of the architecture(s) covering the internal development against accepted standards, policies, technologies, and products as well as the operational aspects of the architectures such that the organization can continue its business within a resilient environment
• A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts
• A formal understanding of the governance organization responsible for the contract, their level of authority, and scope of the architecture under the governance of this body

Content

Typical contents of an Architecture Design and Development Contract are:

• 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

Typical contents of a Business Users' Architecture Contract are:

• 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 Agreement (SLA))

For more detail on the use of Architecture Contracts, see Part VII, 49. Architecture Contracts.

36.2.3 Architecture Definition Document

Purpose

The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target).

A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture.

The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:

• The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.
• The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

Content

Typical contents of an Architecture Definition Document are:

• Scope
• Goals, objectives, and constraints
• Architecture principles
• Baseline Architecture
• Architecture models (for each state to be modeled):
  • Business Architecture models
  • Data Architecture models
  • Application Architecture models
  • Technology Architecture models
• Rationale and justification for architectural approach
• Mapping to Architecture Repository:
  • Mapping to Architecture Landscape
  • Mapping to reference models
  • Mapping to standards
  • Re-use assessment
• Gap analysis
• Impact assessment
• Transition Architecture:
  • Definition of transition states
  • Business Architecture for each transition state
  • Data Architecture for each transition state
  • Application Architecture for each transition state
  • Technology Architecture for each transition state

36.2.4 Architecture Principles

Purpose

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results.

Content

See Part III, 23. Architecture Principles for guidelines and a detailed set of generic architecture principles, including:

• Business principles (see 23.6.1 Business Principles)
• Data principles (see 23.6.2 Data Principles)
• Application principles (see 23.6.3 Application Principles)
• Technology principles (see 23.6.4 Technology Principles)

36.2.5 Architecture Repository

Purpose

The Architecture Repository acts as a holding area for all architecture-related projects within the enterprise. The repository allows projects to manage their deliverables, locate re-usable assets, and publish outputs to stakeholders and other interested parties.

Content

See Part V, 41. Architecture Repository for a detailed description of the content of an Architecture Repository.

36.2.6 Architecture Requirements Specification

Purpose

The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.

As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective:

• The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architect.
• The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.

Content

Typical contents of an Architecture Requirements Specification are:

• Success measures
• Architecture requirements
• Business service contracts
• Application service contracts
• Implementation guidelines
• Implementation specifications
• Implementation standards
• Interoperability requirements
• IT Service Management requirements
• Constraints
• Assumptions

36.2.7 Architecture Roadmap

Purpose

The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. The Architecture Roadmap highlights individual work packages' business value at each stage. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps. The Architecture Roadmap is incrementally developed throughout Phases E and F, and informed by readily identifiable roadmap components from Phase B, C, and D within the ADM.

Content

Typical contents of an Architecture Roadmap are:

• Work package portfolio:
  • Work package description (name, description, objectives, deliverables)
  • Functional requirements
  • Dependencies
  • Relationship to opportunity
  • Relationship to Architecture Definition Document and Architecture Requirements Specification
  • Business value
• Implementation Factor Assessment and Deduction matrix, including:
  • Risks
  • Issues
  • Assumptions
  • Dependencies
  • Actions
  • Inputs
• Consolidated Gaps, Solutions, and Dependencies matrix, including:
  • Architecture domain
  • Gap
  • Potential solutions
  • Dependencies
• Any Transition Architectures
• Implementation recommendations:
  • Criteria measures of effectiveness of projects
  • Risks and issues
  • Solution Building Blocks (SBBs)

36.2.8 Architecture Vision

Purpose

The Architecture Vision is created early on in the ADM cycle. It provides a summary of the changes to the enterprise that will accrue from successful deployment of the Target Architecture. The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome. Early agreement on the outcome enables the architects to focus on the detail necessary to validate feasibility. Providing an Architecture Vision also supports stakeholder communication by providing a summary version of the full Architecture Definition.

Content

Typical contents of an Architecture Vision are:

• Problem description:
  • Stakeholders and their concerns
  • List of issues/scenarios to be addressed
• Objective of the Statement of Architecture Work
• Summary views necessary for the Request for Architecture Work and the Version 0.1 Business, Application, Data, and Technology Architectures created; typically including:
  • Value Chain diagram
  • Solution Concept diagram
• Mapped requirements
• Reference to Draft Architecture Definition Document

36.2.9 Business Principles, Business Goals, and Business Drivers

Purpose

Business principles, business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. Many factors that lie outside the consideration of architecture discipline may nevertheless have significant implications for the way that architecture is developed.

Content

The content and structure of business context for architecture is likely to vary considerably from one organization to the next.

36.2.10 Capability Assessment

Purpose

Before embarking upon a detailed Architecture Definition, it is valuable to understand the baseline and target capability level of the enterprise. This Capability Assessment can be examined on several levels:

• What is the capability level of the enterprise as a whole? Where does the enterprise wish to increase or optimize capability? What are the architectural focus areas that will support the desired development of the enterprise?
• What is the capability or maturity level of the IT function within the enterprise? What are the likely implications of conducting the architecture project in terms or design governance, operational governance, skills, and organization structure? What is an appropriate style, level of formality, and amount of detail for the architecture project to fit with the culture and capability of the IT organization?
• What is the capability and maturity of the architecture function within the enterprise? What architectural assets are currently in existence? Are they maintained and accurate? What standards and reference models need to be considered? Are there likely to be opportunities to create re-usable assets during the architecture project?
• Where capability gaps exist, to what extent is the business ready to transform in order to reach the target capability? What are the risks to transformation, cultural barriers, and other considerations to be addressed beyond the basic capability gap?

Content

Typical contents of a Capability Assessment are:

• Business Capability Assessment, including:
  • Capabilities of the business
  • Baseline state assessment of the performance level of each capability
  • Future state aspiration for the performance level of each capability
  • Baseline state assessment of how each capability is realized
  • Future state aspiration for how each capability should be realized
  • Assessment of likely impacts to the business organization resulting from the successful deployment of the Target Architecture
• IT Capability Assessment, including:
  • Baseline and target maturity level of change process
  • Baseline and target maturity level of operational processes
  • Baseline capability and capacity assessment
  • Assessment of the likely impacts to the IT organization resulting from the successful deployment of the Target Architecture
• Architecture maturity assessment, including:
  • Architecture governance processes, organization, roles, and responsibilities
  • Architecture skills assessment
  • Breadth, depth, and quality of landscape definition with the Architecture Repository
  • Breadth, depth, and quality of standards definition with the Architecture Repository
  • Breadth, depth, and quality of reference model definition with the Architecture Repository
  • Assessment of re-use potential
• Business Transformation Readiness Assessment, including:
  • Readiness factors
  • Vision for each readiness factor
  • Current and target readiness ratings
  • Readiness risks

36.2.11 Change Request

Purpose

During implementation of an architecture, as more facts become known, it is possible that the original Architecture Definition and requirements are not suitable or are not sufficient to complete the implementation of a solution. In these circumstances, it is necessary for implementation projects to either deviate from the suggested architectural approach or to request scope extensions. Additionally, external factors - such as market factors, changes in business strategy, and new technology opportunities - may open up opportunities to extend and refine the architecture.

In these circumstances, a Change Request may be submitted in order to kick-start a further cycle of architecture work.

Content

Typical contents of a Change Request are:

• Description of the proposed change
• Rationale for the proposed change
• Impact assessment of the proposed change, including:
  • 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

36.2.12 Communications Plan

Purpose

Enterprise architectures contain large volumes of complex and inter-dependent information. Effective communication of targeted information to the right stakeholders at the right time is a critical success factor for enterprise architecture. Development of a Communications Plan for architecture allows for this communication to be carried out within a planned and managed process.

Content

Typical contents of a Communications Plan are:

• Identification of stakeholders and grouping by communication requirements
• Identification of communication needs, key messages in relation to the Architecture Vision, communication risks, and Critical Success Factors (CSFs)
• Identification of mechanisms that will be used to communicate with stakeholders and allow access to architecture information, such as meetings, newsletters, repositories, etc.
• Identification of a communications timetable, showing which communications will occur with which stakeholder groups at what time and in what location

36.2.13 Compliance Assessment

Purpose

Once an architecture has been defined, it is necessary to govern that architecture through implementation to ensure that the original Architecture Vision is appropriately realized and that any implementation learnings are fed back into the architecture process. Period compliance reviews of implementation projects provide a mechanism to review project progress and ensure that the design and implementation is proceeding in-line with the strategic and architectural objectives.

Content

Typical contents of a Compliance Assessment are:

• Overview of project progress and status
• Overview of project architecture/design
• Completed architecture checklists:
  • Hardware and operating system checklist
  • Software services and middleware checklist
  • Applications checklists
  • Information management checklists
  • Security checklists
  • System management checklists
  • System engineering checklists
  • Methods and tools checklists

36.2.14 Implementation and Migration Plan

Purpose

The Implementation and Migration Plan provides a schedule of the projects that will realize the Target Architecture. The Implementation and Migration Plan includes executable projects grouped into managed portfolios and programs. The Implementation and Migration Strategy identifying the approach to change is a key element of the Implementation and Migration Plan.

Content

Typical contents of an Implementation and Migration Plan are:

• Implementation and Migration Strategy:
  • Strategic implementation direction
  • Implementation sequencing approach
• Project and portfolio breakdown of implementation:
  • Allocation of work packages to project and portfolio
  • Capabilities delivered by projects
  • Milestones and timing
  • Work breakdown structure
  • May include impact on existing portfolio, program, and projects

It may contain:

• Project charters:
  • Included work packages
  • Business value
  • Risk, issues, assumptions, dependencies
  • Resource requirements and costs
  • Benefits of migration, determined (including mapping to business requirements)
  • Estimated costs of migration options

36.2.15 Implementation Governance Model

Purpose

Once an architecture has been defined, it is necessary to plan how the Transition Architecture that implements the architecture will be governed through implementation. Within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.

The Implementation Governance Model ensures that a project transitioning into implementation also smoothly transitions into appropriate architecture governance.

Content

Typical contents of an Implementation Governance Model are:

• Governance processes
• Governance organization structure
• Governance roles and responsibilities
• Governance checkpoints and success/failure criteria

36.2.16 Organizational Model for Enterprise Architecture

Purpose

In order for an architecture framework to be used successfully, it must be supported by the correct organization, roles, and responsibilities within the enterprise. Of particular importance is the definition of boundaries between different enterprise architecture practitioners and the governance relationships that span across these boundaries.

Content

Typical contents of an Organizational Model for enterprise architecture are:

• Scope of organizations impacted
• Maturity assessment, gaps, and resolution approach
• Roles and responsibilities for architecture team(s)
• Constraints on architecture work
• Budget requirements
• Governance and support strategy

36.2.17 Request for Architecture Work

Purpose

This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. Requests for Architecture Work can be created as an output of the Preliminary Phase, a result of approved architecture Change Requests, or terms of reference for architecture work originating from migration planning.

In general, all the information in this document should be at a high level.

Content

Requests for Architecture Work typically include:

• 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

36.2.18 Requirements Impact Assessment

Purpose

Throughout the ADM, new information is collected relating to an architecture. As this information is gathered, new facts may come to light that invalidate existing aspects of the architecture. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.

Content

Typical contents of a Requirements Impact Assessment are:

• 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

36.2.19 Solution Building Blocks

Implementation-specific building blocks from the enterprise's Architecture Repository; see Part IV, 37. Building Blocks.

36.2.20 Statement of Architecture Work

Purpose

The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture development cycle. The Statement of 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.

Content

Typical contents of a Statement of Architecture Work are:

• Title
• Architecture project request and background
• Architecture project description and scope
• Overview of Architecture Vision
• Specific change of scope procedures
• Roles, responsibilities, and deliverables
• Acceptance criteria and procedures
• Architecture project plan and schedule
• Approvals

36.2.21 Tailored Architecture Framework

Purpose

TOGAF provides an industry standard framework for architecture that may be used in a wide variety of organizations. However, before TOGAF can be effectively used within an architecture project, tailoring at two levels is necessary.

Firstly, it is necessary to tailor the TOGAF model for integration into the enterprise. This tailoring will include integration with project and process management frameworks, customization of terminology, development of presentational styles, selection, configuration, and deployment of architecture tools, etc. The formality and detail of any frameworks adopted should also align with other contextual factors for the enterprise, such as culture, stakeholders, commercial models for enterprise architecture, and the existing level of Architecture Capability.

Once the framework has been tailored to the enterprise, further tailoring is necessary in order to tailor the framework for the specific architecture project. Tailoring at this level will select appropriate deliverables and artifacts to meet project and stakeholder needs.

See Part II, 6.4.5 Tailor TOGAF and, if any, Other Selected Architecture Framework(s) for further considerations when selecting and tailoring the architecture framework.

Content

Typical contents of a Tailored Architecture Framework are:

• Tailored architecture method
• Tailored architecture content (deliverables and artifacts)
• Configured and deployed tools
• Interfaces with governance models and other frameworks:
  • Corporate Business Planning
  • Enterprise Architecture
  • Portfolio, Program, Project Management
  • System Development/Engineering
  • Operations (Services)