Arsitektur Enterprise:Pertemuan 11-Metode ADM,Fase Pada TOGAF ADM

Metode ADM

Metode pada ADM dibagi menjadi delapan sequential phases (A to H) dan dua phase khusus lainnya: preliminary phase dan requirements management phase. Gambar 1 menampilkan diagram TOGAF yang paling sering dirujuk, yang merangkum pendekatan ini melalui pemecahan empat bagian tingkat tinggi: bisnis, teknologi informasi (TI), perencanaan, dan perubahan. Urutan fase A ke H dipecah sebagai berikut:

Semua phases dideskripsikan seperti ini:

Meskipun perkembangan fase dijelaskan secara berurutan (dari A ke H), urutan ini dapat ditinjau dan disesuaikan sesuai dengan konteksnya, terutama dalam bentuk iterasi dalam siklus ADM.

Gambar 1. Architecture development method (ADM)—TOGAF

• Meskipun perkembangan fase dijelaskan secara berurutan (dari A ke H), urutan ini dapat ditinjau dan disesuaikan sesuai dengan konteksnya, terutama dalam bentuk iterasi dalam siklus ADM. Secara lebih umum, diagram “crop cycle" harus dianggap sebagai struktur referensi alih-alih suatu perkembangan yang tidak berubah, terutama karena tetap mungkin, dan bahkan lebih disukai, untuk mempertanyakan atau menyesuaikan kapan saja bagian dari hasil yang diperoleh sebelumnya.
• Identifikasi dari kendala baru atau formulasi ulang atau penambahan rincian persyaratan dapat menyebabkan aspek baru tertentu muncul, aspek yang tidak cukup dieksploitasi selama fase  sebelumnya. Sebagai contoh, dokumen keluaran utama fase A, “architecture vision,” hanya divalidasi secara definitif selama fase F. Namun, high-quality elaboration menyiratkan perkembangan konvergen, yang tidak mempersoalkan prinsip-prinsip dan foundations yang didefinisikan pada permulaan.

Gambar 2. Typical path of an ADM cycle.

• Figure presents an overview of the progression of an ADM cycle, from the preliminary phase right through to phase H. This typical path is guided by one major goal: the need to obtain the expected result by mastering each step of the process. This goal requires rigorous preparation, a description of the target with regard to what already exists for all facets (business, information system, and technology), precise evaluation of the gaps and risks determining the choice of trajectory, and finally evaluation of the results and careful management of any adjustments made.
• TOGAF describes each step of each phase in detail. This does not mean that the realization of each of these steps is systematic. Some results are already available, either because they are produced by other entities or because they are linked to more general activities. For example, if architecture principles are recorded as results from phase A, they can simply be checked where they already exist. The main thing here is that the presence and conformity of each result must be checked, just like a checklist associated with each phase.

Fase-Fase Pada TOGAF ADM

1. The preliminary phase
Tujuan pada phase ini adalah untuk mempersiapkan enterprise untuk merealisasikan pekerjaan architecture :

• The organization and governance of the architecture
• General principles
• Methods
• Tools
• The architecture repository
• The start of the ADM cycle

Dengan cara ini, preliminary phase bukan bagian dari siklus ADM tetapi dapat dipertimbangkan kapan saja selama siklus ADM sebagai bagian dari evolusi praktik EA, terutama dalam konteks menggunakan maturity model sebagai cara mengidentifikasi peluang untuk inisiatif transisi. Kegiatan pada preliminary phase pada dasarnya cross-organizational, terkait dengan tata kelola umum arsitektur perusahaan, dan tujuannya adalah untuk memungkinkan perusahaan menguasai manajemen dan transformasi arsitekturnya. Namun, selama fase pendahuluan itulah dimulainya siklus ADM tertentu dan disiapkan. Ini dirinci dalam dokumen "Request for Architecture Work", yang berisi semua elemen yang membentuk dasar dari proyek perubahan arsitektur perusahaan (sponsor, tujuan strategis, kendala, kerangka anggaran, dan rencana strategis). Dokumen ini merupakan panduan referensi kontrak untuk kemajuan seluruh siklus TOGAF itu sendiri, dari fase A dan seterusnya.

2. Phase A (vision)

Phase A is the first phase of the ADM cycle, triggered by the validation of the “Request for Architecture Work” document. Phase A has two main goals:

• First, phase A further develops and enriches elements resulting from the preliminary phase, such as architecture principles, key indicators, and the organization or planning of elaboration work.
• Second, phase A prepares subsequent phases by providing a general representation of the baseline andtarget architectures. At this stage, these remain high-level representations, whose goal is to highlight structuring points and typical solutions.
  

Communication plays a key role during this phase. All stakeholders must have the same understanding, in order to obtain consensus on orientations and expected results. Other points are also dealt with, such as the identification of fundamental requirements, their links to strategic goals, or risk management. The “Architecture vision” document constitutes the main output of this phase. To sum up, at the end of phase A we have a common vision of:

• Organization: the stakeholders, their roles, their respective involvement
• Orientation: a consensus on the principles, goals, major requirements, and constraints
• The scope covered, the most impacted parts
• The roadmap: the ADM cycle development plan, the resources, and the budget allocated
• A macroscopic vision of baseline architecture and target architecture
• Major risks and associated risk reduction actions

In other words, we know where we’re going, how we’re getting there, and with whom. Note that at this stage the perspective is horizontal, and covers all architecture domains (business, information system, and technology), unlike the following three phases, which operate vertically, focusing on one particular domain.

3. Phases B, C, and D (Elaboration of Business, Information System, and Technology Architectures)

• Most of the content of the following three phases—B (Business), C (Information System), and D (Technology)—consists in detailing the target and baseline architecture, measuring the gap between the two, and evaluating the impact of change on all facets of the enterprise. The combination of these elements is used to draft the roadmap for transition. This first draft of the roadmap is elaborated progressively throughout phases B, C, and D, and serves as the foundation for phases E and F, which are in charge of defining the transformation plan (Figure 3).
• Each phase begins with the definition of the views that will be used to materialize the baseline and target architectures. Remember that the goal of these views is to adapt the representations of the architecture to each stakeholder’s viewpoint.
• Architecture descriptions are consigned to the architecture definition document (central document). This document is enriched during each phase, before being finalized and validated prior to the start of migration work. Concretely, each phase will complete the chapter(s) that concerns it, so that the document spans all architecture domains.
• Of course, as well as depending on each situation, the choice of target architecture also integrates recurrent questions. Consequently, TOGAF recommends that the repository be reviewed before each decision in order to reuse the experience accumulated during earlier work wherever possible. This repository review is noted as a “checklist” action at the start of each phase, so as to conform to the norms in place within the enterprise and to promote general harmonization.

Gambar 3. Main activities common to phases B, C, and D.

Impact assessment should be considered in a cross-organizational way, for two reasons. First, because each phase evaluates its impact beyond its own scope. During phase B, for example, the impact of evolutions on technical elements is also assessed. If, for example, the executive management team decides to remove a product range, it is easy to work out the consequences of this decision on the corresponding database. Second, because the sheer number of relationships within an enterprise can lead to all sorts of unexpected side effects on entities outside the initial scope.

Phase B (business architecture)
The structural similarity of phases B, C, and D should not detract from the determining role of phase B, since it is the business that drives the architecture in all its forms. The formalization of business elements (requirements, processes, entities) is the prelude to all valid logical or technical constructions. This is all the more true when we consider that the goal of phase B is also to demonstrate the pertinence of the work being carried out. Goals are established during the earlier phases, but it is only when business architecture elements are precisely developed that the target solution can be installed and its consequences observed. For example, the description of modifications carried out on a business process shows the real-life result of these modifications on tasks run by operators, new services to provide, or modifications applied to exchanged information.

In terms of architecture descriptions, phase B mainly concentrates on the following elements:

• Business motivation elements (drivers, goals, objectives)
• Organizational units
• Business functions and services
• Business processes
• Business roles and actors
• Business entities

Business entities describe key business concepts and provide the essential entry point to phase C (in the Data Architecture subphase). Business processes are often the key to understanding an enterprise’s real activity, and by extension its architecture.

Phase C (information systems architecture)
Information system architecture is a kind of bridge between the business view and its physical translation. It defines software components (applications and data) that support the automation or realization of business capabilities and functions, without integrating technological realities (this point is dis-cussed in the Phase D part).

Remember that phase C (information system architecture) is itself composed of two subphases: data architecture and application architecture.

These two facets (data and application) are reunited in a single phase because of their proximity in the construction of information system architecture. One of the  expected results consists in allocating each data group to one application  component, which will handle its management, becoming, as it were, the owner  of the data group in question.

Phase D (technology architecture)

• Unsurprisingly, the role of phase D is to establish the technological and physical correspondence of the elements developed during the previous phases. In particular, technology architecture defines the platforms and execution environments on which the applications run and the data sources are hosted for use.
• So what are the links between application architecture and technology architecture? A first approach consists in considering them as two separate elements, so as to avoid any technical “intrusion” into the work of the application architect. The opposite approach would lead us to consider application architecture as a simple reformulation of the technical reality.
• A position that is too dogmatic will lead to a dead end: What is the point of developing a “virtual” application architecture with no link to the reality of the deployed applications? Common sense (and purse strings) calls for more realism. Even though it must remain logical, application architecture (including its service-oriented architecture (SOA) formulation) is not completely separate from its physical translation. The most important thing here is the identification of the role of each application or component, independent of its technical implementation: the fundamental structure is similar and the viewpoint is different, just like a logical service interface, which is not fundamentally modified by its implementation in Java or via a web service.
• Bearing in mind these two perspectives, a question comes to mind: Should we start by describing the technical architecture or the application architecture? This point is linked to the iterations of the ADM cycle, which will be more generally dealt with in Section 2.3. Remember that the ADM
  cycle is a generic framework, which does not forbid intrusions into earlier or later phases (the TOGAF document is strewn with suggestions of this type). In practice, no preestablished choices exist: this is the famous choice between “top down” and “bottom up,” which always finishes with a compromise. The deployment of external tools imposes a type of architecture that can sometimes have a significant impact on application architecture solutions. In other contexts, architecture will be more oriented by architectural principles, for example to obtain a more progressive structure.
• However, let’s get back to the result of phase D: the technological architecture, in other words, a coherent set of software components, infrastructures, and technical platforms. These elements can come from external providers or be produced directly by teams within the enterprise. Moreover, the choice between deploying tools that are available in the marketplace or tools resulting from specific developments is a recurrent theme for an enterprise architect. Here too, the repository will assist in this type of choice by making available a set of common norms, patterns, tools, and practices, which will help harmonize solutions within the enterprise.
  

4. Phases E and F (opportunities and solutions, migration planning)

• At this point of the ADM cycle, the operational realization of architecture transformation truly begins: projects are set up, schedules defined, resources identified, and operational monitoring put in place. The previous phases have provided the target, an overall roadmap, and now their concrete implementation has to be defined.
• Phases E and F look at the scheduling and organization of the implementation of new architecture.  mphasis is placed on building the migration path, which must bring true business benefit to each step.
• During phase E, the results of the elaboration phases (B, C, and D) are consolidated: architectures, requirements, and gaps. This consolidation constitutes the raw material used to define transition architectures, while bearing in mind the enterprise’s capability for change (for example, new applications to develop and evolutions of existing applications, according to the coverage of the business functions). Technical and organization feasibility, compromises between requirements and costs, and integration constraints are also studied.
• Phase F precisely establishes migration scheduling, as well as the constitution of implementationprojects and their organization, goals, and costs.
• Phase F precisely establishes migration scheduling, as well as the constitution of implementation projects and their organization, goals, and costs.

5. Phases G and H (implementation governance, architecture change management)

• Phase G establishes the definitive version of architecture contracts with implementation projects, including recommendations from the architecture board. These signed contracts constitute the basis for conformity reviews of implementation projects.
• Phase H handles the management of the deployed architecture: change management, including the evaluation of change requests that impact the architecture. It should be noted that certain evolution requests can lead to new ADM cycles.

Latihan Pertemuan 11