1093110.1093111

8/3/2019 1093110.1093111.

http://slidepdf.com/reader/full/10931101093111 1/6

Opportunities and Solution of TOGAF

Diajukan untuk memenuhi kelulusan matakuliah Kapita Selekta pada

Jurusan Teknik Informatika

Oleh

Isom Nur Salim (1093110)

Jesica Metalliana Nur Vad’aq (1093111)

Widyanto Samuel (1093124)

Teknik Informatika 2C

PROGRAM DIPLOMA III TEKNIK INFORMATIKA

POLITEKNIK POS INDONESIA

BANDUNG

2011

8/3/2019 1093110.1093111.


Gbr 1. Opportunities and Solution of TOGAF

8/3/2019 1093110.1093111.


Approach

Phase E concentrates on how to deliver the architecture. It takes into account the completeset of gaps between the Target and Baseline Architectures in all architecture domains, and logicallygroups changes into work packages within the enterprise's portfolios. This is an effort to build a best-

fit roadmap that is based upon the stakeholder requirements, the enterprise's business transformationreadiness, identified opportunities and solutions, and identified implementation constraints. The key isto focus on the final target while realizing incremental business value.

Phase E is the initial step on the creation of the Implementation and Migration Plan which iscompleted in Phase F. It provides the basis of a well considered Implementation and Migration Planthat is integrated into the enterprise's portfolio in Phase F.

The following four concepts are key to transitioning from developing to delivering a TargetArchitecture:

Architecture Roadmap

Work Packages

Transition Architectures

Implementation and Migration Plan

The Architecture Roadmap lists individual work packages in a timeline that will realize the TargetArchitecture.

Each work package identifies a logical group of changes necessary to realize the Target Architecture.

A Transition Architecture describes the enterprise at an architecturally significant statebetween the Baseline and Target Architectures. Transition Architectures provide interim TargetArchitectures upon which the organization can converge.

The Implementation and Migration Plan provides a schedule of the projects that will realizethe Target Architecture.

Inputs

This section defines the inputs to Phase E.

Reference Materials External to the Enterprise

Architecture reference materials

Product information

Non-Architectural Inputs

Request for Architecture Work

Capability Assessment

Communications Plan

Planning methodologies

Architectural Inputs

Organizational Model for Enterprise Architecture including:o Scope of organizations impactedo Maturity assessment, gaps, and resolution approacho Roles and responsibilities for architecture team(s)

8/3/2019 1093110.1093111.


o Constraints on architecture worko Budget requirementso Governance and support strategy

Governance models and frameworks for:o Corporate Business Planningo Enterprise Architecture

o Portfolio, Program, Project Managemento System Development/Engineeringo Operations (Service)

Tailored Architecture Framework including:o Tailored architecture methodo Tailored architecture content (deliverables and artifacts)o Configured and deployed tools

Statement of Architecture Work

Architecture Vision

Architecture Repository including:o Re-usable building blockso Publicly available reference modelso Organization-specific reference modelso Organization standards

Draft Architecture Definition Document, including:o Baseline Business Architecture, Version 1.0 (detailed)o Target Business Architecture, Version 1.0 (detailed)o Baseline Data Architecture, Version 1.0 (detailed)o Target Data Architecture, Version 1.0 (detailed)o Baseline Application Architecture, Version 1.0 (detailed)o Target Application Architecture, Version 1.0 (detailed)o Baseline Technology Architecture, Version 1.0 (detailed)o Target Technology Architecture, Version 1.0 (detailed)

Draft Architecture Requirements Specification including:o Architectural requirementso Gap analysis results (from Business, Data, Application, and Technology Architecture)o IT Service Management requirements

Change Requests for existing business programs and projects

Candidate Architecture Roadmap components from Phases B, C, and D

Steps

The level of detail addressed in Phase E will depend on the scope and goals of the overallarchitecture effort.

The order of the steps in Phase E (see below) as well as the time at which they are formallystarted and completed should be adapted to the situation at hand in accordance with the established

architecture governance.

All activities that have been initiated in these steps must be closed during the Create the ArchitectureRoadmap & Implementation and Migration Plan step

Determine/Confirm Key Corporate Change Attributes

This step determines how the enterprise architecture can be best implemented to takeadvantage of the organization's business culture. This should include the creation of anImplementation Factor Assessment and Deduction matrix to serve as a repository for architectureimplementation and migration decisions. The step also includes assessments of the transitioncapabilities of the organization units involved (including culture and abilities), and assessments of theenterprise (including culture and skill sets).

8/3/2019 1093110.1093111.


The resulting factors from the assessments should be documented in the Implementation FactorAssessment and Deduction matrix. For organizations where enterprise architecture is wellestablished, this step can be simple, but the matrix has to be established so that it can be used as anarchive and record of decisions taken.

Determine Business Constraints for Implementation

Identify any business drivers that would constrain the sequence of implementation. Thisshould include a review of the business and strategic plans, at both a corporate and line-of-businesslevel, and a review of the Enterprise Architecture Maturity Assessment.

Review and Consolidate Gap Analysis Results from Phases B to D

Consolidate and integrate the gap analysis results from the Business, Information Systems,and Technology Architectures (created in Phases B to D) and assess their implications with respect topotential solutions and inter-dependencies.

Review the Phase B, C, and D gap analysis results and consolidate them in a single list. The

gaps should be consolidated along with potential solutions to the gaps and dependencies. Arecommended technique for determining the dependencies is to use sets of views such as theBusiness Interaction matrix, the Data Entity/Business Function matrix, and the Application/Functionmatrix to completely relate elements from different architectural domains.

Rationalize the Consolidated Gaps, Solutions, and Dependencies matrix. Once all of the gapshave been documented, re-organize the gap list and place similar items together. When grouping thegaps, refer to the Implementation Factor Assessment and Deduction matrix and review theimplementation factors. Any additional factors should be added to the Implementation FactorAssessment and Deduction matrix.

Review Consolidated Requirements Across Related Business Functions

Assess the requirements, gaps, solutions, and factors to identify a minimal set ofrequirements whose integration into work packages would lead to a more efficient and effectiveimplementation of the Target Architecture across the business functions that are participating in thearchitecture. This functional perspective leads to the satisfaction of multiple requirements through theprovision of shared solutions and services. The implications of this consolidation of requirements withrespect to architectural components can be significant with respect to the provision of resources. Forexample, several requirements raised by several lines of business can be resolved through theprovision of a shared set of Business Services and Information System Services within a workpackage or project.

Consolidate and Reconcile Interoperability Requirements

Consolidate the interoperability requirements identified in previous phases. The ArchitectureVision and Target Architectures, as well as the Implementation Factor Assessment and Deductionmatrix and Consolidated Gaps, Solutions, and Dependencies matrix, should be consolidated andreviewed to identify any constraints on interoperability required by the potential set of solutions.

A key outcome is to minimize interoperability conflicts, or to ensure such conflicts areaddressed in the architecture. Re-used Solution Building Blocks (SBBs), Commercial Off-The-Shelf(COTS) products, and third-party service providers typically impose interoperability requirements thatconflict. Any such conflicts must be addressed in the architecture, and conflicts must be consideredacross all architecture domains (Business, Applications, Data, and Technology).

There are two basic approaches to interoperability conflicts; either create a building block that

transforms or translates between conflicting building blocks, or make a change to the specification ofthe conflicting building blocks.

8/3/2019 1093110.1093111.


Identify Transition Architectures

Where the scope of change to implement the Target Architecture requires an incrementalapproach, then one or more Transition Architectures may be necessary. These provide an ability toidentify clear targets along the roadmap to realizing the Target Architecture. The TransitionArchitectures should provide measurable business value. The time-span between successive

Transition Architectures does not have to be of uniform duration.

Development of Transition Architectures must be based upon the preferred implementation approach,the Consolidated Gaps, Solutions, and Dependencies matrix, the listing of projects and portfolios, aswell as the enterprise's capacity for creating and absorbing change.

Determine where the difficult activities are, and unless there are compelling reasons, implement themafter other activities that most easily deliver missing capability.

Create the Architecture Roadmap & Implementation and Migration Plan

Consolidate the work packages and Transition Architectures into the Architecture Roadmap,

Version 0.1, which describes a timeline of the progression from the Baseline Architecture to theTarget Architecture. The timeline informs the Implementation and Migration Plan. The ArchitectureRoadmap frames the migration planning in Phase F. Identified Transition Architectures and workpackages should have a clear set of outcomes. The Architecture Roadmap must demonstrate howthe selection and timeline of Transition Architectures and work packages realizes the TargetArchitecture.

The detail of the Architecture Roadmap, Version 0.1 should be expressed at a similar level ofdetail to the Architecture Definition Document developed in Phases B, C, and D. Where significantadditional detail is required before implementation the architecture is likely transitioning to a differentlevel.

The Implementation and Migration Plan must demonstrate the activity necessary to realizethe Architecture Roadmap. The Implementation and Migration Plan forms the basis of the migrationplanning in Phase F. The detail of the Implementation and Migration Plan, Version 0.1 must bealigned to the detail of the Architecture Roadmap and be sufficient to identify the necessary projectsand resource requirements to realize the roadmap.

When creating the Implementation and Migration Plan there are many approaches toconsider, such as a data-driven sequence, where application systems that create data areimplemented first, then applications that process the data. A clear understanding of the dependenciesand lifecycle of in-place SBBs is required for an effective Implementation and Migration Plan.

Finally, update the Architecture Vision, Architecture Definition Document, and ArchitectureRequirements Specification with any additional relevant outcomes from this phase.

1093110.1093111

Documents