Macam-macam Enterprise Architecture Framework

“Ini adalah hasil rangkuman kuliah enterprise architecture di prodi Sistem Informasi Universitas Trunojoyo Madura”

1. ZACHMAN

A. Sejarah Zachman Enterprise Architecture

Kerangka Zachman untuk Arsitektur Enterprise: John Zachman menerbitkan Zachman Framework for Enterprise Architecture pada tahun 1987 dan dianggap sebagai salah satu pelopor dalam domain ini. Menurut Zachman , “peningkatan cakupan desain dan tingkat kompleksitas implementasi sistem informasi memaksa penggunaan beberapa konstruksi logis (atau arsitektur).” Kerangka Zachman didasarkan pada prinsip-prinsip arsitektur klasik yang membentuk persamaan umum. kosa kata dan seperangkat perspektif untuk menggambarkan sistem perusahaan yang kompleks. Kerangka kerja ini tidak memberikan panduan mengenai urutan, proses, atau implementasi, namun berfokus pada memastikan bahwa semua pandangan telah mapan, memastikan sistem yang lengkap terlepas dari urutan kemunculannya. Kerangka Zachman memiliki enam perspektif atau pandangan: Perencana, Pemilik, Perancang, Pembangun, Subkontraktor, dan Pengguna. Penjelasannya adalah sebagai berikut:

1. Planner/ Perencana: yang menetapkan objek dalam pembahasan; latar belakang, lingkup, dan tujuan enterprise.

2. Owner /Pemilik: penerima atau pemakai produk/jasa akhir dari enterprise.

3. Designer/Perancang: perantara antara apa yang diinginkan (pemilik) dan apa yang dapat dicapai secara teknis dan fisik.

4. Builder/ Pembangun: pengawas/pengatur dalam menghasilkan produk/jasa akhir.

5. Subkontraktor: bertanggung jawab membangun dan merakit bagian-bagian dari produk/jasa akhir f. Functioning enterprise: wujud nyata dari produk/jasa akhir.

Karakteristik Zachman Framework:

1. Mengkategorikan deliverables dari EA

2. Kegunaan EA yang terbatas

3. Banyak diadopsi di seluruh dunia

4. Perspektif view yang kurang menyeluruh

5. Merupakan tool untuk perencanaan

Banyak organisasi tertarik untuk membangun arsitektur enterprise mereka dengan menggunakan framework Zachman. Mereka berharap dapat memecahkan masalah ketidaksesuaian antara proses bisnis dan sistem informasi seiring dengan memperoleh tingkat interoperabilitas dan fleksibilitas yang diinginkan di lingkungan TI mereka. Namun, dalam kebanyakan kasus kerangka kerja Zachman tetap sebagai kerangka konseptual lebih dari yang pragmatis. Hal ini menyebabkan keraguan yang serius mengenai apakah perusahaan dapat memuaskan motivasi penggunaan kerangka kerja Zachman.

Ide dasar dibalik Framework Zachman adalah bahwa hal kompleks yang sama dapat digambarkan untuk tujuan yang berbeda dengan cara yang berbeda menggunakan berbagai jenis deskripsi. Setiap baris dalam Zachman framework mewakili perspektif tertentu. Sebuah baris atas atau perspektif tidak selalu memiliki pemahaman yang lebih komprehensif dari perspektif yang lebih rendah. Dalam Zachman framework tahun 1997 baris dijelaskan dari sudut pandang Planner’s view (scope), Owner’s view (enterprise atau model bisnis), Designer’s view (Information System model), Builder’s view (Techn Ide dasar dibalik Framework Zachman adalah bahwa hal kompleks yang sama dapat digambarkan untuk tujuan yang berbeda dengan cara yang berbeda menggunakan berbagai jenis deskripsi.Sebuah baris atas atau perspektif tidak selalu memiliki pemahaman yang lebih komprehensif dari perspektif yang lebih rendah.

Kolom Zachman framework dapat dijelaskan sebagai berikut: masing-masing perspektif memfokuskan perhatian pada pertanyaan mendasar yang sama, jawaban pertanyaan-pertanyaan dari sudut pandang itu, menciptakan representasi deskriptif yang berbeda (yaitu model), yang menerjemahkan dari persepktif yang lebih tinggi ke yang lebih rendah. Kolom Zachman framework adalah sebagai berikut deskripsi data–what (apa), deskripsi fungsi–how (bagaimana), deskripsi jaringan–where (dimana), deskripsi orang–who (siapa), deskripsi waktu–when (bila), gambaran motivasi– mengapa. Menurut Zachman, faktor tunggal yang membuat kerangka kerja yang unik adalah bahwa setiap elemen di kedua sumbu matriks secara eksplisit dibedakan dari semua elemen lain pada sumbu itu. Representasi dalam setiap sel matriks tidak hanya tingkatan detail meningkat, namun sebenarnya adalah representasi berbeda-beda dalam konteks, makna, motivasi, dan penggunaan. Karena setiap elemen pada sumbu secara eksplisit berbeda dari yang lain maka memungkinkan untuk mendefinisikan dengan tepat apa yang termasuk dalam setiap sel. Jenis model atau representasi deskriptif arsitektur dibuat eksplisit di persimpangan baris dan kolom.

Kelebihan dan Kekurangan Zachman Framework

Kelebihan dari Zachman Framework adalah sebagai berikut:

1. Zachman Framework merupakan standar secara de-facto untuk mengklasifikasikan artefak arsitektur Enterprise.

2. Struktur logikal untuk analisis dan presentasi artefak dari suatu perspektif manajemen.

3. Zachman Framework menggambarkan secara parallel baik dari sisi enjinering yang sudah sangat dimengerti maupun paradigma konstruksi.

4. Zachman Framework dikenal secara luas sebagai tool manajemen untuk memeriksa kelengkapan arsitektur dan maturity level.

Sedangkan kekurangan dari Zachman Framework antara lain:

1. Tidak ada proses untuk tahap implementasi.

2. Sulit untuk diimplementasikan secara keseluruhan.

3. Tidak ada contoh maupun ceklis yang siap secara utuh.

4. Perluasan coverage sel-sel tidak jelas.

2.  TOGAF

          A. Sejarah The Open Group Architecture Technique (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.

Kerangka Arsitektur Open Group Architectural (TOGAF): Kerangka Arsitektur Open Group (TOGAF) pertama kali dikembangkan pada tahun 1995 dan didasarkan pada Kerangka Arsitektur Teknis Departemen Pertahanan untuk Manajemen Informasi. TOGAF berfokus pada aplikasi bisnis missioncritis yang menggunakan blok bangunan sistem terbuka. “Elemen kunci TOGAF adalah Architecture Development Method (ADM) yang menentukan proses pengembangan arsitektur enterprise”. TOGAF menjelaskan peraturan untuk mengembangkan prinsip-prinsip yang baik, daripada menyediakan seperangkat prinsip arsitektur. Tiga tingkat prinsip mendukung pengambilan keputusan di seluruh perusahaan; memberikan panduan sumber daya TI; dan mendukung prinsip-prinsip arsitektur untuk pengembangan dan implementasi.

B. Karakteristik Togaf

Sebagai kerangka kerja perancangan arsitektur, TOGAF memiliki beberapa karakteristik, antara lain:

1. Termasuk dalam 3 kerangka kerja perancangan arsitektur yang paling sering  digunakan (Schekkerman, 2003).

2. Merupakan kerangka kerja yang bersifat open-standard.

3. Bersifat netral –> fits all

4. Diterima oleh masyarakat internasional secara luas –> fits all

5. Pendekatannya bersifat menyeluruh (holistic).

6. Dibutuhkan metode yang fleksibeluntuk mengintegrasikan unit-unit informasi dan juga sistem informasi dengan platform dan standar yang berbeda-beda.

7. TOGAF mampu untuk melakukan integrasi untuk berbagai sistem yang berbeda-beda

8. TOGAF adalah kerangka kerja umum dan dimaksudkan untuk digunakan dalam berbagai macam lingkungan, ia menyediakan konten kerangka kerja yang fleksibeldan extensible yang mendasari seperangkat pengiriman arsitektur generik.

9. TOGAF cenderung bersifat generikdan fleksibel karena dapat mengantisipasi segala macam artefak yang mungkin muncul dalam proses perancangan (Resource base TOGAF menyediakan banyak material referensi), standarnya diterima secara luas, dan mampu mengatasi perubahan.

10. Fokus pada siklus implementasi (ADM) dan proses –> process driven

11. Kunci TOGAF adalah metode – TOGAF Architecture Development Method (ADM – Metode Pengembangan Arsitektur) – untuk mengembangkan suatu arsitektur enterprise yang membahas kebutuhan bisnis.

12. TOGAF relatif mudah diimplementasikan –> fits all

13. TOGAF bersifat open source, sehingga bersifat netral terhadap teknologi dari vendortertentu –> fits all

3. TOGAF Enterprise Architecture Category

TOGAF memandang enterprise architecture ke dalam empat kategori. Keempat kategori tersebut adalah:

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.

C. Struktur dan Komponen TOGAF

 

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.

D. 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 seperti yang ditunjukkan pada gambar 9 yang terdiri dari  langkah sembilan 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.

E. Kelebihan dan Kekurangan TOGAF

Kelebihan Togaf

• Sifatnya yang fleksibel dan bersifat open source.
• Sistematis
• Focus pada siklus implementasi (ADM) dan proses
• Kaya akan area teknis arsitektur
• Recource base menyediakan banyak material referensi
• Karena melibatkan banyak pihak terutama industri, di TOGAF banyak memberikan best practice atau kejadian riil di dunia nyata

Kekurangan Togaf

• Tidak ada templates standart untuk seluruh domain (misalnya untuk membuat blok diagram)
• Tidak ada artefak yang dapat digunakan ulang (ready made).

3.     FEAF

A. Sejarah Federal enterprise architecture (FEAF)

Federal enterprise architecture adalah arsitektur enterprise pemerintah federal. Sebuah enterprise architecture menggambarkan keadaan pada saat ini dan masa depan lembaga, dan menjabarkan rencana untuk transisi dari kondisi saat ini ke keadaan masa depan yang diinginkan. Federal enterprise architecture adalah sebuah karya dalam proses untuk mencapai tujuan tersebut. Hal ini dirancang untuk kemudahan berbagi informasi dan sumber daya di seluruh badan-badan federal, mengurangi biaya, dan memperbaiki keadaan masyarakat.

FEA dibangun dengan menggunakan berbagai macam model referensi, yang mengembangkan taksonomi umum dan ontologi untuk menggambarkan sumber daya IT, ini termasuk: Kinerja reference model, bisnis model reference, layanan komponen model reference, data reference model, dan model referensi teknis.

Pada FEAF  arsitektur yang ada diperuntukkan sebagai reference point untuk memfasilitasi koordinasi yang efektif dan efisien dari proses bisnis yang umum, penyisipan teknologi , aliran inforamsi dan investasi pada Federal Agencies. FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan  mengimplementasikan lingkungan operasional pada top-level dan mendukung implementasi dari sistem TI.

Pada gambar tersebut menunjukkan gambaran matriks  5 x 3 FEAF dengan tipe-tipe arsitektur pada sumbu mendatar dan  perspektif pada sumbu lainnya. Hubungan antara produk EA terdapat pada cells matriks.

B. Karakteristik dari FEAF:

1. Merupakan EA Reference Model
2. Standar yang dipakai oleh pemerintahan Amerika Serikat
3. Menampilkan perspektif view yang menyeluruh
4. Merupakan tool untuk perencanaan dan komunikasi.

C.  Struktur komponen FEAF

Struktur komponen FEAF diperuntukkan sebagai reference point untuk memfasilitasi koordinasi yang efektif dan efisien dari proses bisnis, penggunaan teknologi, aliran informasi, dan investasi pada Federal Agencies. FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan mengimplementasikan lingkungan operasional di top-level dan mendukung implementasi dari sistem TI. Objektif dari FEAF memungkinkan pemerintahan federal dan organisasinya mencapai hal berikut (Minoli , 2008):

(a) Meningkatkan teknologi dan mengurangi pengeluaran TI yang berlebih di   pemerintahan.

(b) Memfasilitasi integrasi TI dan sharing data antar institusi.

(c) Menggunakan praktik arsitektur yang umum.

(d) Membantu institusi bertemu mandat legislatif Enterprise Architecturenya.

4.   GARTNER

A. Pandangan Gartner mengenai Enterprise Architecture

Menurut Gartner, arsitektur enterprise adalah mengenai menyatukan tiga unsur yaitu pemilik bisnis, spesialis informasi, pelaksana teknologi. Arsitektur enterprise dalam tampilan Gartner adalah tentang strategi bukan tentang teknik. Hal ini difokuskan pada tujuan. Salah satu visi yang memiliki konsekuensi besar adalah di arsitektur bisnis, informasi dan teknik.

Gartner framework Enterprise Architecture juga menjelaskan empat sudut pandang primer arsitektur: Bisnis, Informasi, Teknologi dan Solusi. Setiap sudut pandang mewakili konsentrasi yang relevan dengan serangkaian stakeholder. kasar, pada Sudut pandang Bisnis mewakili konsentrasiEA, sudut pandang informasi mewakili arus informasi dan konsentrasi pemodelan, sudut pandang teknologi mewakili pelaksanaan teknis dan konsentrasi operasional arsitek teknologi, sudut  pandang  solusi berhubungan langsung dengan masalah penting dalam arsitektur.

B. Revisi Proses Model EA Gartner

Gartner Framework Sebuah dokumen pendamping memperkenalkan Gartner EA Framework, yang mengartikulasikan hubungan antara arsitektur bisnis perusahaan, arsitektur informasi perusahaan dan EA  teknis (ETA) dan sintesis dengan solusi EA (ESA). Meskipun Model Proses EA dan Kerangka EA memiliki kelebihan sendiri dan nilai, mereka dapat digunakan bersamaan. M EA Gartner merupakan pelengkap yang berharga arsitektur: Bisnis, Informasi, Teknologi dan Solusi. Setiap sudut pandang mewakili konsentrasi yang relevan dengan serangkaian stakeholder. Secara kasar, pada Sudut pandang Bisnis mewakili konsentrasi EA, sudut pandang informasi mewakili arus informasi dan konsentrasi pemodelan, sudut pandang teknologi mewakili pelaksanaan teknis dan konsentrasi operasional arsitek teknologi, sudut pandang solusi berhubungan langsung dengan masalah penting dalam arsitektur.

Sebuah dokumen pendamping memperkenalkan Gartner EA Framework, yang mengartikulasikan hubungan antara arsitektur bisnis perusahaan, arsitektur informasi perusahaan dan EA  teknis (ETA) dan sintesis dengan solusi EA (ESA). Meskipun Model Proses EA dan Kerangka EA memiliki kelebihan sendiri dan nilai, mereka dapat digunakan bersamaan. Model proses EA Gartner merupakan pelengkap yang berharga serta  kredibel, kerangka EA vendor-netral. Jadi, jika suatu organisasi telah memilih untuk mengadopsi EA yang berbeda kerangka kerja, model diperkenalkan di sini masih akan menambah nilai yang signifikan dengan disiplin arsitektur. Sebuah framework tidak menjawab pertanyaan tentang apa yang akan diproduksi kapan dan bagaimana itu semua terkait, ini adalah isu yang dibahas oleh model proses. Selama beberapa tahun ke depan, Model Proses EA Gartner akan tetap stabil. Namun, praktek-praktek terbaik ditemukan di antara elemen rinci dari Model Proses EA akan terus berkembang, terutama di area pemodelan masa depan negara.

Tabel 1. Kriteria dan Ringkasan Peringkat Metodologi Enterprise Architecture.  

Criteria	Zachman	TOGAF	FEA	Gartner
Taxonomy completes (taksonomi)	4	2	2	1
Process completeness (kelengkapan proses)	1	4	2	3
Reference model guidance (panduan referensi model)	1	3	4	1
Practice guidance (panduan pelaksanaan)	1	2	2	4
Maturity model	1	1	3	2
Business focus (Fokus bisnis)	1	2	1	4
Governance guidance	1	2	3	3
Partitioning guidance (panduan partisi)	1	2	4	3
Prescriptive catalog (katalog yang memberi petunjuk)	1	2	4	2
Vendor neutrality (netralitas vendor)	2	4	3	1
Information availability (ketersediaan informasi)	2	4	2	1
Time to value	1	3	1	4

Tabel 2. Perbandingan Karakteristik  Enterprise Architecture Framework.

Enterprise architecture framework	Characteristic
TOGAF	Enterprise architecture development methodology, History in defence, Open standard, Neutral, Broad acceptance, Holistic perspective, Process/planning tool.
Zachman	Positioning framework, Catogorizing deliverables, Limited usesfulness EA, History in manufacturing, Broad acceptance, Limited holistic Perspect, Planning tool.
FEAF	Enterprise architecture reference framework, History in enterprise architecture planning, US Gov standard, Broad US Gov acceptance, Holistic Perspective, Planning and communication tool.
Gartner Framework	Strategy, Planning and communication tool

Tabel 3. Perbandingan Komponen Enterprise Architecture Framework

Komponen		Framework
	Zachman	TOGAF	FEAF	Gartner
Data
Function
Network	√
People	√
Time	√
Motivation	√
Arsitektur Bisnis		√	√	√
Arsitektur Data		√	√
Arsitektur Aplikasi		√	√
Arsitektur Teknis		√		√
Arsitektur Technology			√
Arsitektur Informasi				√

Kesimpulan

Ketika mempelajari lebih dalam mengenai enterprise architecture, faktanya tidak ada satupun macam dari pendekatan ini yang terlengkap. Untuk beberapa enterprise, tidak ada satupun macam dari metodologi ini benar-benar lengkap dijadikan sebagai suatu solusi. Ada pendekatan lain yang disebut blended metodology yaitu memilih bagian-bagian dari metodologi, memodifikasi, menggabungkan, dan menyusunnya untuk kebutuhan khusus organisasi. Dalam prakteknya EA Framework yang telah ada, tidak ada yang sempurna, masing-masing memiliki kelebihan dan kekurangan. Bahkan penggunaan EA framework di masing-masing enterprise bisa menjadi berbeda. Hal ini tergantung dengan karakteristik dari enterprise itu sendiri, fokus yang ingin dicapai dan lain-lain.

1. Untuk membangun sebuah sistem informasi yang terintegrasi harus menentukan framework yang sesuai dengan kondisi organisasi/institusi yang ada.
2. Komponen utama dalam sebuah framework adalah pandangan, metode, dan pelatihan.