Jumat, 30 Desember 2011

2 Pengenalan TOGAF

The Open Group Architecture Technique (TOGAF) adalah sebuah framework yang dikembangkan oleh The Open Group’s Architecture Framework pada tahun 1995. Awalnya TOGAF digunakan oleh Departemen Pertahanan Amerika Serikat namun pada perkembangannya TOGAF banyak digunakan pada berbagai bidang seperti perbankan, industri manufaktur dan juga pendidikan. TOGAF ini digunakan untuk mengembangkan enterprise architecture, dimana terdapat metode dan tools yang detil untuk mengimplementasikannya, hal inilah yang membedakan dengan framework EA lain misalnya framework Zachman. Salah satu kelebihan menggunakan framework TOGAF ini adalah karena sifatnya yang fleksibel dan bersifat open source. 

TOGAF memandang enterprise architecture ke dalam empat kategori yaitu:
  1. Business Architecture: Mendeskripsikan tentang bagaimana proses bisnis untuk mencapai tujuan organisasi.
  2. Application Architecture: Merupakan pendeskripsian bagaimana aplikasi tertentu didesain dan bagaimana interaksinya dengan apikasi lainnya.
  3. Data Architecture: Adalah penggambaran bagaimana
    penyimpanan, pengelolaan dan pengaksesan data pada perusahaan.
  4. Technical Architecture: Gambaran mengenai infastruktur hardware dan software yang mendukung aplikasi dan bagaimana interaksinya.
TOGAF secara umum memiliki struktur dan komponen sebagai berikut:
  1. Architecture Development Method (ADM): Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci bagaimana menentukan sebuah enterprise architecture secara spesifik berdasarkan kebutuhan bisnisnya.
  2. Foundation Architecture (Enterprise Continuum): Foundation Architecture merupakan sebuah “framework-within-a-framework” dimana didalamnya tersedia gambaran hubungan untuk pengumpulan arsitektur yang relevan, juga menyediakan bantuan petunjuk pada saat terjadinya perpindahan abstraksi level yang berbeda. Foundation Architecture dapat dikumpulkan melalui ADM. Terdapat tiga bagian pada foundation architecture yaitu Technical Reference Model, Standard Information dan Building Block Information Base.
  3. Resource Base: Pada bagian ini terdapat informasi mengenai guidelines, templates, checklists, latar belakang
    informasi dan detil material pendukung yang membantu arsitek didalam penggunaan ADM.
TOGAF- Architecture Development Method (ADM)
Architecture Development Method (ADM) merupakan metodologi lojik dari TOGAF yang terdiri dari delapan fase utama untuk pengembangan dan pemeliharaan technical architecture dari organisasi. ADM membentuk sebuah siklus yang iteratif untuk keseluruhan proses, antar fase, dan dalam tiap fase di mana pada tiap-tiap iterasi keputusan baru harus diambil. Keputusan tersebut dimaksudkan untuk menentukan luas cakupan enterprise, level kerincian, target waktu yang ingin
dicapai dan asset arsitektural yang akan digali dalam enterprise continuum.
ADM merupakan metode yang umum sehingga jika diperlukan pada prakteknya ADM dapat disesuaikan dengan kebutuhan spesifik tertentu, misalnya digabungkan dengan framework yang lain sehingga ADM menghasilkan arsitektur yang spesifik terhadap organisasi. ADM dapat dikenali dengan penggambaran siklus yang terdiri dari delapan langkah proses.

Secara singkat kedelapan fase ADM adalah sebagai berikut:
  1. Fase Preliminary: Framework and Principles: Merupakan fase persiapan yang bertujuan untuk mengkonfirmasi komitmen dari stakeholder, penentuan framework dan metodologi detil yang akan digunakan pada pengembangan EA.
  2. Fase A : Architecture Vision. Fase ini memiliki tujuan untuk memperoleh komitmen manajemen terhadap fase ADM ini, memvalidasi prinsip, tujuan dan pendorong bisnis, mengidentifikasi stakeholder. Terdapat beberapa langkah untuk mencapaian tujuan fase ini dengan inputan berupa permintaan untuk pembuatan arsitektur, prinsip arsitektur dan enterprise continuum. Output dari fase ini adalah: (1) pernyataan persetujuan pengerjaan arsitektur yang meliputi: Scope dan konstrain serta rencana pengerjaan arsitektur, (2) prinsip arsitektur termasuk prinsip bisnis, (3) Architecture Vision.
  3. Fase B : Business Architecture. Fase B bertujuan untuk (1) memilih sudut pandang terhadap arsitektur yang bersesuaian dengan bisnis dan memilih teknik dan tools yang tepat (2) mendeskripsikan arsitektur bisnis eksisting dan target pengembangannya serta analisis gap antara keduanya. Inputan untuk fase B berasal dari output fase A, sedangkan
    outputnya adalah revisi terbaru dari hasil ouput fase A ditambah dengan arsitektur bisnis eksisting dan target pengembangannya secara detil serta hasil analisis gap, business architecture report dan kebutuhan bisnis yang telah diperbaharui.
  4. Fase C : Information Systems Architectures. Tujuan fase ini adalah untuk mengembangkan arsitektur target untuk data dan/atau domain aplikasi. Pada arsitektur data misalkan untuk menentukan tipe dan sumber data yang diperlukan untuk mendukung bisnis dengan cara yang dimengerti oleh stakeholder. Pada arsitektur aplikasi untuk menentukan jenis
    sistem aplikasi yang dibutuhkan untuk memproses data dan mendukung bisnis.
  5. Fase D : Technology Architecture. Untuk pengembangan arsitektur teknologi target yang akan menjadi basis implementasi selanjutnya.
  6. Fase E : Opportunities and Solutions. Secara umum merupakan fase untuk mengevaluasi dan memilih cara pengimplemetasian, mengidentifikasi parameter strategis untuk perubahan, perhitungan cost dan benefit dari proyek serta menghasilkan rencana implementasi secara keseluruhan berikut strategi migrasinya.
  7. Fase F : Migration Planning: Fase ini bertujuan untuk mengurutkan implementasi proyek berdasarkan prioritas dan daftar tersebut akan menjadi basis bagi rencana detil implementasi dan migrasi.
  8. Fase G : Implementation Governance. Merupakan tahapan memformulasikan rekomendasi untuk setiap implementasi proyek, membuat kontrak arsitektur yang akan menjadi acuan implementasi proyek serta menjaga kesesuaiannya dengan arsitektur yang telah ditentukan.
  9. Fase H : Architecture Change Management. Pada akhir fase ini diharapkan terbentuk skema proses manajemen perubahan arsitektur.
  10. Requirements Management Bertujuan untuk menyediakan proses pengelolaan kebutuhan arsitektur sepanjang fase pada siklus ADM, mengidentifikasi kebutuhan enterprise, menyimpan lalu memberikannya kepada fase yang relevan.

Artikel Terkait perkategori

2 komentar:

  1. ada contoh pengimplementasian/penelitian yg bisa di share?

    BalasHapus
  2. Terima kasih atas kunjungan anda. Tentu saja ada, hanya saja belum bisa di share, harus mendapat ijin dari pemiliknya dulu.

    BalasHapus

 

Blog CIO Indonesia Copyright © 2011 - |- Template created by O Pregador - |- Powered by Blogger Templates