وَمَا هَٰذِهِ ٱلْحَيَوٰةُ ٱلدُّنْيَآ إِلَّا لَهْوٌ وَلَعِبٌ ۚ وَإِنَّ ٱلدَّارَ ٱلْءَاخِرَةَ لَهِىَ ٱلْحَيَوَانُ ۚ لَوْ كَانُوا۟ يَعْلَمُونَ

“Dan tiadalah kehidupan dunia ini melainkan senda gurau dan main-main. Dan sesungguhnya akhirat itulah yang sebenarnya kehidupan, kalau mereka mengetahui.” (QS. Al-Ankabut:64)

Thursday, 2 July 2020

Arsitektur Enterprise: Pengantar pada Framework TOGAF

Sejarah TOGAF
  • TOGAF (The Open Group Architecture Framework) muncul dengan cepat dan merupakan kerangka kerja serta metode yang dapat diterima secara luas dalam pengembangan arsitektur perusahaan
  • TOGAF dimulai awal 1990-an sebagai metodologi untuk pengembangan arsitektur teknis, dan telah dikembangkan oleh The Open Group ke dalam kerangka arsitektur enterprise yang luas. Pada tahun 1995 , versi pertama dari TOGAF (TOGAF 1.0) disajikan. Versi ini terutama didasarkan pada Architecture Framework Teknis Pengelolaan Informasi (TAFIM), dikembangkan sejak tahun 1980 oleh an Departemen Pertahanan AS.
  • Pada bulan Desember 2001 TOGAF 7, “Edisi Teknis “, diterbitkan TOGAF 8 (“Enterprise Edition”) pertama kali diterbitkan pada bulan Desember 2002 dan diterbitkan dalam bentuk diperbarui TOGAF 8.1 pada bulan Desember 2003. Sekitar tahun 2005 menjadi TOGAFTM merek dagang terdaftar dari The Open Group. Pada bulan November 2006 Open Group dirilis TOGAF 8.1.1. Menurut The Open Group , pada Februari 2011, lebih dari 15.000 individu TOGAF Bersertifikat. Pada September 2012 register resmi memiliki lebih dari 20.000 individu bersertifikat.
The TOGAF Document?
Dokumen Togaf dibagi menjadi 7 bagian yaitu:
  1. Introduction
  2. ADM(Architecture Development Method)
  3. ADM Guidelines
  4. Architecture Content
  5. Enterprise Continuum and Tools
  6. Reference Models
  7. Architecture Capability Framework
Gambar di atas menyajikan pengelompokan berbagai macam bagian pada dokumen
TOGAF yaitu : Method, Best practice, Component, Repository dan Governance

  • ADM ( “Architecture Development Method”) pada bagian II adalah is the main entry point to the TOGAF reference document, with its crop circle diagram (or TOGAF wheel), which describes the different phases of the method.
  • Part III membahas mengenai guidelines and best practices linked to the ADM, from security and gap analysis to stakeholder management. It should be noted that in general TOGAF does not provide “standard solutions” but rather a series of  practices “that work,” accompanied by more or less detailed examples.
  • Part IV (architecture content) is dedicated to the tangible elements used in development work: deliverables, catalogs, matrices, diagrams, or the “building blocks” that constitute the architecture.
  • Parts V and VI berfokus pada repository enterprise architecture, dan partitioning, typology, dan  tools.
  • Part VII (“Architecture Capability Framework”) deals with architecture governance, including repository management.
TOGAF : KEY POINT
  • The ADM crop circle diagram menyajikan struktur dari method with its phases and transitions and is the first striking image encountered when broaching TOGAF. Pada fase ini mendefiniskan high-level work stages, which consume and provide products (deliverables). Masing-masing dari delapan fase berkontribusi untuk mencapai tujuan strategis yang ditentukan, dari visi keseluruhan arsitektur (fase A) hingga pemeliharaan arsitektur yang digunakan (fase H). Urutan ini, yang disebut siklus ADM, terjadi dalam konteks proyek arsitektur yang dikelola oleh manajemen eksekutif perusahaan.
  • The work carried out is supervised by the architecture board, in partnership with all the business and IS stakeholders. As you can see, the proposed path is a cycle, which finishes by looping back on itself. Admittedly, this is merely a schematic representation that only partially represents reality. However, it does successfully express the continuous nature of enterprise architecture work, which responds to the constant demands of businesses.
  • The central position occupied by requirements management in the diagram is testament to the pivotal role it plays within the ADM cycle. Strictly speaking, requirements management is more a permanent activity than a phase. However, the term “phase” is used to designate it in order to harmonize vocabulary. The same is true for the preliminary phase, which groups cross-organizational activities such as the definition of context, methods and tools for enterprise architecture, and the start of an ADM cycle.
  • Fundamentally, the aim of an ADM cycle is to successfully complete a transformation project, whose aim is to enable the enterprise to respond  to a set of business goals.
The “TOGAF crop circle diagram” with the ADM phases

0 komentar :

Post a comment