Rabu, 10 Mei 2017

MILC Progress #4

Kami melanjutkan kembali pembuatan proyek tugas besar IMK pada hari Minggu, 7 Mei 2017.
Pada gambar di atas, terlihat penakar yang terhubung dengan penampung air (Coca-cola 1.5 L) dan pengaduk (botol 300 ml pada paling bawah).
Pada dasarnya, botol penakar bergerak pada lintasannya menggunakan prinsip pesawat sederhana, yaitu katrol yang gerakannya dibantu oleh motor yang berada di bawah penakar.
Botol penakar akan bergerak mendekati penampung untuk mengalirkan air ke pengaduk dan sebaliknya — bergerak ke bawah untuk mengalirkan air dari penampung ke penakar.
Penakar dapat naik dan turun secara otomatis. Motor akan selalu berada pada posisi ON untuk menerima masukan pengguna. Sebelum masuk ke pengaduk, botol penakar akan mengukur jumlah air yang mengalir dari penampung. Bila telah sesuai jumlah yang ditentukan (misal 300 ml) maka air akan mengalir ke pengaduk. Pada intinya, botol penakar mengukur dan bergerak secara otomatis.









Laporan Tugas Akhir Interaksi Manusia dan Komputer


Posting kali ini melengkapi sebuah posting yang telah diterbitkan beberapa minggu lalu.

Latar Belakang
Produk ini ditujukan bagi orang-orang yang cukup sibuk sehingga kurang memiliki waktu luang untuk membuat minuman sendiri.
Bagi sebagian orang, dispenser mereka terletak di ruang dapur yang terasa jauh dari tempat mereka mengerjakan tugas-tugas mereka. Dengan menggunakan MILC, mereka bisa membuat minuman hanya melalui aplikasi berbasis website. 

Produk ini menggunakan jaringan internet untuk menerima perintah dari pengguna dan mengirimkan data ke dispenser.
Alternatif Pemecahan Masalah
Alternatif yang diajukan ialah pembuatan mesin semacam robot yang bertugas untuk mengantarkan minuman ke meja pengguna. Robot tersebut dapat menerima perintah pengguna untuk mengambil minuman di ruang dapur. Sayangnya, alternatif ini tidak dapat diwujudkan saat ini karena terbatasnya waktu dan kurang terjangkaunya teknologi yang harus dibeli untuk dapat mengimplementasikan alternatif solusi ini.
Solusi yang kami pilih ialah MILC – MILC is Liquid Conditioner, sebuah dispenser yang memanfaatkan jaringan internet untuk melakukan tugas-tugasnya. Salah satu tugas utamanya ialah untuk membantu orang-orang membuat minuman dan mengatur suhu air pada dispenser sesuai keinginan.
Spesifikasi Desain
Sistem MILC memiliki dua masukan utama, yaitu air yang ditampung pada botol berkapasitas 1.5 Liter dan bubuk yang ditampung pada sebuah boks berkapasitas maksimal 300 gram. Perintah pengguna untuk membuat minuman juga termasuk salah satu masukan sistem; besaran yang dapat diukur yakni kecepatan transmit data.
Keluarannya sistem ialah ialah larutan air yang sudah dicampur dengan bubuk. Kapasitas maksimal larutan tersebut yaitu 300 ml. MILC juga dapat mengirimkan suhu air saat ini kepada pengguna dalam satuan Celsius.
Komponen-komponen yang digunakan untuk membuat sistem MILC yaitu:
  1. Arduino Uno 1 buah
  2. Beberapa kabel jumper
  3. Driver motor L298N 1 buah
  4. Modul Wi-Fi ESP8266
  5. Sensor suhu DS18B20
  6.  Motor DC 3 buah
  7.  Sensor ultrasonik HC-SR04 2 buah
  8. Kertas duplex
  9. Breadboard 1 buah
  10. Selang 1 meter
  11. Lem tembak dan isinya 5 buah
  12. Botol bekas 1.5 L 1 buah
  13. Kardus bekas
  14. Kertas HVS
  15. Botol bekas 0.3 L 2 buah
  16. Sedotan bekas 1 pak
  17. Kabel tie 5 buah
  18. Cutter dan isinya bila perlu
  19. Gunting
  20. Isolasi hitam/electric tape
  21. Double tape foam/isolasi bolak balik
  22. Solder dan timah secukupnya
Protokol yang dipakai adalah HTTP, dibantu dengan modul Wi-Fi ESP8266.
Desain Perangkat Keras

Besaran yang ingin diukur dari lingkungan ialah suhu dan jumlah air serta jumlah bubuk. Bubuk dan air ditampung pada dua penampung yang berbeda. Kemudian sensor suhu (DS18B20) dipasang pada penampung air untuk mengetahui suhu air, sedangkan sensor ultrasonik (HC-SR04) digunakan pada kedua penampung untuk mengetahui jumlah air dan bubuk yang tersisa.
Kami menggunakan Arduino Uno dan Driver Motor L298N sebagai mikrokontrollernya. Driver Motor L298N berfungsi sebagai pengendali motor DC (aktuator) yang berfungsi mengendalikan gerak naik dan turunnya botol penakar.
Data berupa jumlah dan suhu air beserta jumlah bubuk dikirim ke web server Apache menggunakan modul Wi-Fi ESP8266. Dari web server, sistem dapat menerima perintah pembuatan minuman khusus dari pengguna dan memprosesnya sehingga minuman dapat dibuat.
Desain Perangkat Lunak

Gambar di samping ialah flow chart sistem MILC. Pertama, sistem akan menerima perintah dari pengguna. Apabila perintah berupa pemunculan Status saja, maka sistem akan menampilkan status berupa jumlah sisa dan suhu air, sisa bubuk, status pemanas (Nyala/Mati) dan status pembuatan (Sudah Jadi/Belum Jadi).
Saat hendak membuat minuman, sistem akan memeriksa data jumlah air dan minuman untuk memastikan bahwa minuman bisa dibuat. Bila tidak, maka sistem akan mengirimkan notifikasi kepada pengguna melalui web. 
Bila jumlah air dan bubuk mencukupi, maka sistem akan memberi perintah pada Motor DC untuk menggerakkan botol penakar ke atas dan ke bawah. Botol penakar akan turun ke bawah untuk menampung air, kemudian naik ke atas untuk mengalirkan air ke botol pengaduk melalui saluran (saat ini berupa sedotan).
Setelah minuman telah selesai diaduk, minuman akan dituangkan ke gelas yang tersedia dan pengguna akan diberitahu melalui web.
Desain User Interaction


Saat ini, hanya interface di atas yang baru diimplementasikan. Pemanas dapat diaktifkan menggunakan sebuah command yang nanti dikirimkan ke server. Sistem MILC pun juga mampu membuat minuman dengan menggunakan sebuah command.

Bila bubuk atau air kurang mencukupi, maka sistem akan mengirimkan notifikasi bahwa minuman tidak dapat dibuat.


Implementasi Perangkat Keras




Dispenser ini memiliki dua penampung yang berisi air dan bubuk tertentu — misalnya kopi.
Di samping itu, pengguna dapat mengatur suhu air panas sesuai keinginan mereka dan memberikan perintah kepada dispenser untuk membuat minuman. MILC dilengkapi dengan pengaduk yang berfungsi melarutkan bubuk dengan air panas.
Sistem MILC juga secara otomatis akan menakar air sesuai keinginan pengguna dengan botol penakar air yang bergerak secara otomatis ke bawah untuk mengisi air dan bergerak ke atas untuk mengalirkan air ke suatu botol pengaduk. Pergerakan botol ini dikendalikan oleh driver motor L298N.
Masalah kami ialah terlalu berfokus pada masalah mekanik, yaitu menentukan mekanisme katup terbaik untuk mengalirkan air ke botol penakar. Selain itu, masalah pada sensor ESP8266 yang memunculkan error RTO juga menghambat penyelesaian proyek. Pengaturan daya antarkomponen juga menjadi masalah.


Implementasi Perangkat Lunak


Kode di atas adalah kode terima.php. Kode ini berfungsi sebagai media bagi sensor ESP8266 menerima dan mengirimkan data ke server. Format transfer data dibuat custom sesuai format yang kami buat.



Kode di atas ialah potongan kode info.php. Kode ini berfungsi menampilkan database  yang berisi kondisi dispenser saat ini dalam bentuk tabel kepada pengguna. Kode ini juga berfungsi sebagai media bagi user untuk memberikan instruksi kepada sistem dispenser MILC.
Kode terakhir ialah kode default.php. Kode ini berfungsi untuk menampilkan info database secara real-time. 

Pengujian

Kami melakukan pengujian untuk seetiap komponen yang digunakan pada sistem ini. Berikut adalah daftar pengujiannya.
Nama pengujian
Metode
Parameter
Hasil Pengujian
Keterangan
Pengujian Arduino Uno
Black box
Komunikasi data
Arduino dapat digunakan dan diprogram
-
Pengujian sensor suhu (DS18B20)
Black box
Nilai sensor
Nilai sensor benar
Terkadang tetdapat kabel yang tidak pas sehingga nilai bacaan sensor salah
Pengujian sensor ultrasonik (HC-SR04)
Black box
Nilai sensor
Nilai sensor benar
Terkadang tetdapat kabel yang tidak pas sehingga nilai bacaan sensor salah
Pengujian aktuator motor DC
Black box
Daya putar motor
Motor dapat berfungsi dengan baik
Memerlukan daya yang lebih untuk mendapatkan torsi yang besar. Memerlukan rangkaian tambahan untuk catu daya motor.
Pengujian mekanisme katup
Black box
Daya angkat katup
Katup dapat membuka dan menutup
Torsi kurang cukup kuat untuk mengangkat tabung dengan isi yang banyak.
Pengujian koneksi modul Wi-Fi ESP8266
Black box
Komunikasi data
Data dapat dikirim dan diterima
Sering terjadi RTO (Request Time Out)
Pengujian website
Black box
Tampilan website
Tampilan website dapat dioperasikan
-
Pengujian database
Black box
Tabel database
Database dapat menyimpan data transmini
-


Kesimpulan

Produk yang dibuat untuk meyelesaikan permasalahan orang-orang yang cukup sibuk sehingga kurang memiliki waktu luang untuk membuat minuman sendiri, kini dapat direalisasikan. Alat yang kami rancang dapat diproduksi dengan biaya yang cukup murah sehingg dapat menjangkau seluruh kalangan di masyarakat. Untuk pengembangan alat ini selanjutnya mungkin harus dibuat mekanisme-mekanisme mekanik yang lebih tepat agar setiap program yang akan dijalankan dapat bejalan dengan semestinya.

MILC Progress #3


Progress yang kami lakukan pada tanggal 6 Mei 2017. Agenda kami ialah membuat mekanisme katup pada botol penakar. Hal ini terbilang cukup sulit karena kami harus melakukan engineering pada beberapa komponennya.
Pertama-tama, setelah mekanisme buka/tutup katup penakar selesai digunakan menggunakan sedotan dan motor, selanjutnya ialah merancang bagaimana penakar tersebut bisa naik mendekati botol penampung bubuk (Coca-cola 1.5 L) dan turun mendekati gelas penampung campuran air dan bubuk.
Hal ini diwujudkan dengan menempelkan botol pada dua sedotan yang telah ditempelkan pada sepotong kertas duplex sebagai rel botol sehingga botol bisa melaju naik dan turun. Agar dapat melaju secara otomatis, maka perlu digunakan sebuah motor yang bergerak dengan kecepatan tertentu.
Kecepatan putar motor diatur dengan memberikan masukan tegangan tertentu pada motor. Pada kasus ini, kami memberikan tegangan sekitar 3.3 Volt (kalau tidak salah). Pada salah satu gambar, terlihat kami sedang menempelkan sebuah sekrup pada salah satu sisi motor. Kami menguji kekuatan putarannya dengan menempelkannya pada salah satu snack yang kami beli sebagai kudapan. Meskipun dapat melubangi snack tersebut, namun saat itu kami berpikir bahwa putaran motor ditakutkan kurang kuat sehingga kami memutuskan mengurangi muatan air pada penampung (Coca-cola 1.5 L) agar tidak terlalu membebani penakar.
Salah satu gambar di atas menunjukkan kegiatan menempelkan sepotong duplex kecil pada bagian atas dan bawah duplex yang terpasang botol penakar. Hal ini tujuannya untuk membatasi laju botol agar tidak melesat terlalu jauh dari yang diinginkan. Kami juga berencana memasang karton pada sisi kanan dan kiri botol agar botol tetap berada pada jalurnya. Saat itu, kami takut bahwa botol penakar kurang erat tertempel pada kertas duplex.
Kami mengerjakan tugas ini dari jam 20.00 WIB hingga pukul 01.30 WIB dini hari. Tentu saja, terdapat canda tawa pada selang pengerjaan tugas, termasuk yang . . . kurang baik untuk dibicarakan di sini. 










MILC Progress #2

Progress yang dilakukan pada kali ini adalah medesain mekanisme dari alat yang akan kami buat yaitu dispenser pintar. Desain yang akan dibuat pertama-tama difokuskan ke mekanisme katup untuk menatur air dan bubuk minumal yang akan didistribusikan dalam alat. Terdapat beberapa alternatif dalam membuat mekanisme katup pada alat kami.
  1. Mekanisme katup dengan mur dan baut
  2. Mekanisme katup dengan membengkokan selang ke kanan/kiri
  3. Mekanisme katup dengan menaikturunkan tabung penakar

Pada setiap percobaan mekanisme katup ditemukan kelemahan untuk itu dipilih satu dari ketiga alternatif diatas. Mekanisma yang dipilih bukan mekanisme yang terbaik melainkan mekanisme yang bisa dibuat sekarang dengan bahan dan waktu yang ada. Berikut ini merupakan gambaran bagaimana alat kami bekerja.



Senin, 08 Mei 2017

[Re-Post] TOGAF, Salah satu Metodologi dalam pembuatan IT Blue Print

Artikel ini saya tulis, sebenarnya untuk mendokumentasikan terkait dengan beberapa pekerjaan terkait dengan apa yang sedang saya kerjakan bersama Team dalam hal pembuatan IT Blue Print (cetak biru IT) untuk suatu perusahaan. Dan seperti yang sudah pernah saya sampaikan dalam tulisan saya sebelumnya mengenai mengapa IT Blue Print dibutuhkan ?, tulisan ini menyambung dari tulisan saya sebelumnyna, hanya saja pada tulisan ini saya akan berbicara mengenai Metodologi TOGAF (The Open Group Architecture Framework) yang umum digunakan untuk pembuatan IT Blue Print (Ada juga metodologi lainnya seperti : Zachman , Enterprise Architecture, dll).
Saat ini ada beragam jenis  framework   yang menunjukkan perkembangan konsep arsitektur  enterprise, diantaranya adalah  Zachman framework,  Federal Enterprise Architecture Framework  (FEAF),  DoD Architecture Framework (DoDAF),  Treasury Enterprise Architecture Framework  (TEAF), serta  The Open Group Architectural Framework  (TOGAF).  Menurut hasil survei yang dilakukan oleh  Institute For Enterprise Architecture Development  (IFEAD)   tahun 2005, frame wor k   yang paling banyak digunakan dalam dunia industri maupun pemerintahan adalah Zachman (25%), TOGAF (11%) ,  dan FEAF (9%). Hasil perbandingan penggunaan jenis  framework   terlihat pada Gambar 1.

Gambar  Hasil survei pemakaian framework   (IFEAD 2005) 

Sejarah
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.
Versi terakhir adalah TOGAF 9.1, diluncurkan pada tanggal 1 Desember 2011. Sebuah perkembangan evolusi dari TOGAF 8, TOGAF 9  mencakup banyak fitur baru termasuk :
  • Peningkatan kekakuan, termasuk Konten Metamodel resmi yang menghubungkan artefak TOGAF bersama-sama ( walaupun ada beberapa masalah dengan Metamodel tersebut ) .
  • Penghapusan perbedaan yang tidak perlu.
  • Banyak lagi contoh dan template.
Panduan dan teknik tambahan meliputi:
  • Sebuah pendekatan bisnis berbasis formal arsitektur.
  • Kemampuan bisnis berbasis perencanaan.
  • Bimbingan tentang cara menggunakan TOGAF untuk mengembangkan Arsitektur dan Keamanan SOAs.
The Open Group menyediakan TOGAF gratis kepada organisasi untuk tujuan non-komersial internal mereka sendiri. Jadi The  open  group  architecture  framework  (TOGAF)  adalah  suatu  framework  untuk  arsitektur  perusahaan  yang memberikan  pendekatan  yang  komprehensif  untuk  merancang,  perencanaan,  pelaksanaan,  dan  tata  kelola  arsitektu informasi  perusahaan. TOGAF  merupakan  level  atas  dan  pendekatan  holistik  untuk  desain,  yang  biasanya  dimodelkan pada empat tingkat, yaitu bisnis, aplikasi, data, dan teknologi.
TOGAF memiliki pandangan sendiri, yang dapat ditentukan baik sebagai deskripsi formal dari suatu sistem, atau rencana rinci  dari  sistem  pada  tingkat  komponen  untuk  memandu  pelaksanaan,  atau  sebagai struktur  komponen,  hubungannya, prinsip-prinsip dan pedoman yang mengatur desain dan evolusi.
Ruang Lingkup
Awalnya TOGAF digunakan oleh Departemen Pertahanan Amerika Serikat namun pada perkembangannya TOGAF banyak digunakan pada berbagai bidang seperti perbankan, industri manufaktur, Departemen Negara dan juga pendidikan.
Kelebihan dan Kekurangan
      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)
TOGAF (The Open Group Architecture Framework) muncul dengan cepat dan merupakan kerangka kerja serta metode yang dapat diterima secara luas dalam pengembangan arsitektur perusahaan. Berawal dari Technical Architecture for Information Management atau (TAFIM) di Departemen Pertahanan Amerika Serikat, kerangka kerja itu diadopsi oleh Open Group pada pertengahan 1990an. Spesifikasi pertama TOGAF diperkenalkan pada tahun 1995, dan TOGAF 8 (Enterprise Edition) dirilis pada awal 2004. Pada saat ini sudah ada TOGAF 9 yang secara keseluruhan melengkapi versi sebelumnya.
TOGAF memberikan metode yang detil tentang bagaimana membangun dan mengelola serta mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan ADM (Architecture Development Method).
Tujuan dari arsitektur enterprise adalah untuk mengoptimalkan seluruh perusahaan ke lingkungan terpadu yang tanggap terhadap perubahan dan mendukung strategi bisnis. Arsitektur enterprise yang baik memungkinkan kita untuk mencapai keseimbangan yang tepat antara efisiensi teknologi informasi dan inovasi bisnis. Hal ini memungkinkan unit bisnis individu untuk berinovasi secara aman untuk mengejar keunggulan kompetitif mereka. Keuntungan yang dihasilkan dari arsitektur enterprise yang baik membawa manfaat bisnis yang penting, yang jelas terlihat dalam laporan laba atau rugi bersih dari perusahaan atau organisasi.
Karakteristik Togaf
Sebagai kerangka kerja perancangan arsitektur, TOGAF memiliki beberapa karakteristik, antara lain:
  • Termasuk dalam 3 kerangka kerja perancangan arsitektur yang paling sering digunakan (Schekkerman, 2003).
  • Merupakan kerangka kerja yang bersifat open-standard.
  • Bersifat netral –> fits all
  • Diterima oleh masyarakat internasional secara luas –> fits all
  • Pendekatannya bersifat menyeluruh (holistic).
  • Dibutuhkan metode yang fleksibel untuk mengintegrasikan unit-unit informasi dan juga sistem informasi dengan platform dan standar yang berbeda-beda.
  • TOGAF mampu untuk melakukan integrasi untuk berbagai sistem yang berbeda-beda
  • TOGAF adalah kerangka kerja umum dan dimaksudkan untuk digunakan dalam berbagai macam lingkungan, ia menyediakan konten kerangka kerja yang fleksibel dan extensible yang mendasari seperangkat pengiriman arsitektur generik.
  • TOGAF cenderung bersifat generik dan 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.
  • Fokus pada siklus implementasi (ADM) dan proses –> process driven
  • Kunci TOGAF adalah metode – TOGAF Architecture Development Method (ADM – Metode Pengembangan Arsitektur) – untuk mengembangkan suatu arsitektur enterprise yang membahas kebutuhan bisnis.
  • TOGAF relatif mudah diimplementasikan –> fits all
  • TOGAF bersifat open source, sehingga bersifat netral terhadap teknologi dari vendor tertentu –> fits all

Struktur dan Komponen dari TOGAF
Dalam bidang pendidikan TOGAF telah diimplementasikanoleh Monash University. Berikut ini adalah struktur dan komponen dari TOGAF :
1. Architecture Development Method
Architecture Development Method menjelaskan bagaimana menemukan sebuah arsitektur perusahaan/organisasi secara khusus berdasarkan kebutuhan bisnisnya. Ini merupakan bagian utama dari TOGAF.
Bentuk diagram TOGAF-ADM adalah seperti pada gambar berikut ini.
 Image_2
Gambar  Bentuk struktur dari TOGAF-ADM
2. Foundation Architecture (Enterprise Continuum)
Foundation Architecture merupakan sebuah “framework-within-a-framework” yang menyediakan hubungan bagi pengumpulan asset arsitektur yang relevan dan menyediakan bantuan petunjuk pada saat terjadinya perpindahan abstraksi level yang berbeda.
Foundation Architecture terdiri dari:
a. Technical Reference Model
Menyediakan sebuah model dan klasifikasi dari platform layanan generik.
b. Standard Information Base
Menyediakan standar-standar dasar dari informasi.
c. Building Block Information Base
Menyediakan blok-blok dasar informasi di masa yang akan datang.
3. Resource Base
Bagian ini memberikan sumber-sumber informasi  idelines, templates, checklists,latar belakang informasi dan detil  material pendukung yang membantu arsitek di dalam penggunaan Architecture Development Method.
TOGAF digunakan sebagai framework untuk arsitektur sistem informasi perguruan tinggi karena cocok dengan karakteristik perguruan tinggi dan sistem informasinya itu sendiri, yaitu:
  1. Dibutuhkan suatu metoda yang fleksibel untuk mengintegrasikan unit-unit informasi dan mungkin juga sistem perencanaan sistem informasi (SI) dengan flatform dan standar yang berbeda-beda. TOGAF mampu untuk melakukan integrasi untuk berbagai sistem yang berbeda-beda.
  2. TOGAF cenderung merupakan suatu metoda yang bersifat generik serta fleksibel yang dapat mengantisipasi segala macam artefak yang mungkin muncul dalam proses perancangan (karena TOGAF memiliki resource base yang sangat banyak), standarnya diterima secara luas, dan mampu mengatasi perubahan.
  3. TOGAF mudah diimplementasikan.
  4. TOGAF bersifat open source .

Arsitektur Enterprise Togaf
TOGAF membagi arsitektur enterprise ke dalam empat kategori, yaitu sebagai berikut :
  1. Business architecture, menjelaskan proses binis untuk memenuhi tujuannya.
  2. Application architecture, menjelaskan bagaimana aplikasi khusus dirancang dan bagaimana aplikasi berinteraksi satu dengan yang lainnya.
  3. Data architecture, menjelaskan bagaimana enterprise datastores diatur dan diakses.
  4. Technical architecture, menjelaskan infrasrtuktur hardware dan software yang mendukung aplikasi dan interaksinya.
TOGAF menggambarkan dirinya sebagai sebuah “kerangka,” namun bagian terpenting dari TOGAF adalah Architecture Development Method (ADM). ADM adalah resep untuk menciptakan arsitektur. Mengingat bahwa ADM adalah bagian dari TOGAF, TOGAF dikategorikan sebagai proses arsitektur sedangkan ADM sebagai metodologi.
Dipandang sebagai proses arsitektur, TOGAF melengkapi Zachman yang dikategorikan sebagai taksonomi arsitektur. Zachman memberitahukan bagaimana mengkategorikan artefak. Sedangkan TOGAF menciptakan prosesnya.
TOGAF pandangan dunia arsitektur enterprise sebagai kontinum dari arsitektur, mulai dari yang sangat umum sampai kepada yang sangat spesifik. TOGAF’s ADM menyediakan proses untuk mengemudikan gerakan dari umum ke khusus.
 TOGAF adalah sebuah landasan Arsitektur karena terdapat prinsip-prinsip arsitektural yang secara teoritis akan digunakan oleh organisasi TI.
Model Diagram TOGAF ADM (The Open Group Architecture FrameWork Architecture Development Method).
TOGAF memberikan metode yang detil bagaimana membangun dan mengelola serta mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan Architecture Development Method (ADM) (Open Group, 2009. Yang di kutip dari jurnal Roni Yunis, Kridanto Surendro, 2009).
ADM merupakan metode generik yang berisikan sekumpulan aktivitas yang digunakan dalam memodelkan pengembangan arsitektur enterprise. Metode ini juga dibisa digunakan sebagai panduan atau alat untuk merencanakan, merancang, mengembangkan dan mengimplementasikan arsitektur sistem informasi untuk organisasi (Yunis dan Surendro, 2008. Yang di kutip dari jurnal Roni Yunis, Kridanto Surendro, 2009).
 TOGAF ADM merupakan metode yang fleksibel yang dapat mengantifikasi berbagai macam teknik pemodelan yang digunakan dalam perancangan, karena metode ini bisa disesuaikan dengan perubahan dan kebutuhan selama perancangan dilakukan.
 Image_2
Gambar  Architecture Development Method
TOGAF ADM juga menyatakan visi dan prinsip yang jelas tentang bagaimana melakukan pengembangan arsitektur enterprise, prinsip tersebut digunakan sebagai ukuran dalam menilai keberhasilan dari pengembangan arsitektur enterprise oleh organisasi (Open Group, 2009. Yang di kutip dari jurnal Roni Yunis, Kridanto Surendro, 2009), prinsip-prinisip tersebut dapat dijelaskan sebagai berikut :
a. Prinsip Enterprise
Pengembangan arsitektur yang dilakukan diharapkan mendukung seluruh bagian organisasi, termasuk unit-unit organisasi yang membutuhkan.
b. Prinsip Teknologi Informasi (TI)
Lebih mengarahkan konsistensi penggunaan TI pada seluruh bagian organisasi, termasuk unit-unit organisasi yang akan menggunakan.
c. Prinsip Arsitektur
d. Merancang arsitektur sistem berdasarkan kebutuhan proses bisnis dan bagaimana mengimplementasikannya.
Langkah awal yang perlu diperhatikan pada saat mengimplementasikan TOGAF ADM adalah mendefinisikan persiapan-persiapan yaitu dengan cara mengidentifikasi kontek arsitektur yang akan dikembangkan, kedua adalah mendefenisikan strategi dari arsitektur dan menetapkan bagian-bagian arsitektur yang akan dirancang, yaitu mulai dari arsitektur bisnis, arsitektur sistem informasi, arsitektur teknologi, serta menetapkan kemampuan dari arsitektur   yang akan dirancang dan dikembangkan (Harrison dan Varveris, 2006. Yang di kutip dari jurnal Roni Yunis, Kridanto Surendro, 2009).

ARCHITECTURE DEVELOPMENT METHOD
Elemen kunci dari TOGAF adalah  Architecture Development Method (ADM) yang memberikan gambaran spesifik untuk proses pengembangan arsitektur enterprise (Lise 2006). ADM adalah fitur penting yang memungkinkan perusahaan mendefinisikan kebutuhan bisnis dan membangun arsitektur spesifik untuk memenuhi kebutuhan itu. ADM terdiri dari tahapan-tahapan yang dibutuhkan dalam membangun arsitektur  enterprise, tahapan-tahapan ADM diperlihatkan pada gambar di bawah ini.
Image_2
Sebagai komponen inti, TOGAF ADM menyediakan serangkaian proses iteratif mulai dari menyusun arsitektur, transisi, hingga mengelola proses realisasi arsitektur. TOGAF ADM terdiri atas sepuluh fase sebagai berikut:
1. Preliminary Phase – fase ini mencakup aktivitas persiapan untuk menyusun kapabilitas arsitektur termasuk kustomisasi TOGAF dan mendefinisikan prinsip-prinsip arsitektur. Tujuan fase ini  adalah untuk menyakinkan setiap orang yang terlibat di dalamnya bahwa pendekatan ini untuk mensukseskan proses arsitektur. Pada fase ini harus menspesifikasikan who, what,  why, when, dan where dari arsitektur itu sendiri.
  • What adalah ruang lingkup dari usaha.
  • Who adalah siapa yang akan memodelkannya, siapa orang yang akan bertanggung jawab untuk mengerjakan arsitektur tersebut, dimana mereka akan dialokasikan dan bagaimana peranan mereka.
  • How adalah bagaimana mengembangkan arsitekture  interprise, menentukan  framework dan metode apa yang akan digunakan untuk menangkap informasi.
  • When adalah kapan tanggal penyelesaian arsitektur
  • Why adalah mengapa arsitektur ini dibangun. Hal ini berhubungan dengan tujuan organisasi yaitu bagaimana  arsitektur dapat memenuhi tujuan organisasi.
2. Phase A: Architecture Vision – fase ini merupakan fase inisiasi dari siklus pengembangan arsitektur yang mencakup pendefinisian ruang lingkup, identifikasi stakeholders, penyusunan visi arsitektur, dan pengajuan persetujuan untuk memulai pengembangan arsitektur.
Beberapa tujuan dari fase ini adalah :
  • Menjamin evolusi dari siklus pengembangan arsitektur mendapat pengakuan dan dukungan dari manajemen enterprise.
  • Mensyahkan prinsip bisnis, tujuan bisnis dan pergerakan strategis bisnis organisasi.
  • Mendefinisikan ruang lingkup dan  melakukan identifikasi dan memprioritaskan komponen dari arsitektur saat ini.
  • Mendefiniskan kebutuhan bisnis yang akan dicapai dalam usaha arsitektur ini dan batasannya.
  • Menghasilkan visi arsitektur yang menunjukan respon terhadap kebutuhan dan batasannya.
Beberapa langkah yang dilakukan pada fase ini adalah :
  • Menentukan / menetapkan proyek
  • Mengindentifikasi tujuan dan pergerakan bisnis. Jika hal ini sudah didefinisikan, pastikan definisi ini masih sesuai  dan lakukan klarifikasi terhadap bagian yang belum jelas.
  • Meninjau prinsip arsitektur termasuk prinsip  bisnis. Meninjau ini berdasarkan arsitektur saat ini yang akan dikembangkan. Jika hal ini sudah didefinisikan, pastikan definisi ini masih sesuai  dan lakukan klarifikasi terhadap bagian yang belum jelas.
  • Mendefinisikan apa yang ada di dalam dan di luar rungan lingkup usaha saat ini.
  • Mendefinisikan batasan-batasan seperti waktu, jadwal, sumber daya dan sebagainya.
  • Mengindentifikasikan stakeholder, kebutuhan bisnis dan visi arsitektur.
  • Mengembangkan Statement of Architecture Work.
3. Phase B: Business Architecture – fase ini mencakup pengembangan arsitektur bisnis untuk mendukung visi arsitektur yang telah disepakati. Pada tahap ini tools  dan  method  umum untuk pemodelan seperti:  Integration DEFinition (IDEF) dan  Unified Modeling Language  (UML) bisa digunakan untuk membangun model yang diperlukan.
Beberapa tujuan dari fase ini adalah :
  • Menguraikan deskripsi arsitektur bisnis dasar.
  • Mengembangkan arsitektur bisnis  tujuan, menguraikan strategi produk dan/atau service dan aspek geografis,  informasi, fungsional dan organisasi dari lingkungan bisnis yang berdasarkan  pada prinsip bisnis, tujuan bisnis dan penggerak strategi.
  • Menganalisi gap antara arsitektur saat ini dan tujuan.
  • Memilih titik pandang yang relevan yang memungkinkan arsitek mendemokan bagaimana maksud stakeholder dapat dicapai dalam arsitektur bisnis.
  • Memilih tools dan teknik relevan yang akan digunakan dalam sudut pandang yang dipilih.
Beberapa langkah yang dilakukan di fase ini adalah :
  • Mengembangkan deskripsi asitektur  bisnis saat ini untuk mendukung arsitektur bisnis target.
  • Mengindentifikasi reference model, sudut pandang dan tools
  • Melengkapi arsitektur bisnis
  • Melakukan gap analisis dan membuat laporan
4. Phase C: Information Systems Architectures – Pada tahapan ini lebih menekankan pada aktivitas bagaimana arsitektur sistem informasi dikembangkan. Pendefinisian arsitektur sistem informasi dalam tahapan ini meliputi arsitektur data dan arsitektur aplikasi yang akan digunakan oleh organisasi. Arsitektur data lebih memfokuskan pada bagaimana data digunakan untuk kebutuhan fungsi bisnis, proses dan layanan. Teknik yang bisa digunakan dengan yaitu:  ER-Diagram,  Class Diagram, dan  Object Diagram.
Tujuan dari fase ini adalah mengembangkan arsitektur tujuan dalam domain data dan aplikasi.  Ruang lingkup dari proses bisnis yang didukung dalam fase C dibatasi pada proses-proses yang didukung oleh TI dan  interface  dari proses-proses yang berkaitan dengan non-TI. Implementasi dari arsitektur ini mungkin tidak perlu dalam urutan yang sama, diutamakan terlebih dahulu yang begitu sangat dibutuhkan.
 Beberapa langakah yang diperlukan untuk membuat arsitektur data adalah:
  • Mengembangkan deskripsi arsitektur data dasar
  • Review dan validasi prinsip, reference model, sudut pandang dan tools.
  • Membuat model arsitektur
  • Memilih arsitektur data building block
  • Melengkapi arsitektur data
  • Melakukan gap analysis  arsitektur data saat ini dengan arsitektur data target  dan membuat laporan.
5. Phase D: Technology Architecture –Membangun arsitektur teknologi yang diinginkan, dimulai dari penentuan jenis kandidat teknologi yang diperlukan dengan menggunakan  Technology Portfolio Catalog yang meliputi perangkat lunak dan perangkat keras. Dalam tahapan ini juga mempertimbangkan alternatif-alternatif yang diperlukan dalam pemilihan teknologi.
Beberapa langkah yang diperlukan  untuk membuat arsitektur teknologi yaitu:
  • Membuat deskripsi dasar dalam format TOGAF
  • Mempertimbangkan  reference model arsitektur yang berbeda, sudut pandang dan tools.
  • Membuat model arsitektur dari building block
  • Memilih services portfolio yang diperlukan untuk setiap building block
  • Mengkonfirmasi bahwa tujuan bisnis tercapai
  • Menentukan kriteria pemilihan spesifikasi
  • Melengkapi definisi arsitektur
  • Melakukan  gap analysis antara arsitektur teknologi saat ini dengan arsitektur teknologi target.
6. Phase E: Opportunities and Solutions –  Pada tahap ini akan dievaluasi model yang telah dibangun untuk arsitektur saat ini dan tujuan, indentifikasi proyek utama yang akan dilaksanakan untuk mengimplementasikan arsitektur tujuan dan klasifikasikan sebagai pengembangan baru atau penggunaan kembali sistem yang  sudah ada. Pada fase ini juga akan direview gap analysis yang sudah dilaksanakan pada fase D.
Tujuan dari fase ini  adalah :
  • Mengevaluasi dan memilih pilihan implementasi yang diidentifikasikan dalam pengembangan arsitektur target yang bervariasi
  • Identifikasi parameter strategik untuk perubahan dan proyek yang akan dilaksanakan dalam pergerakan dari lingkungan saat ini ke tujuan.
  • Menafsirkan ketergantungan, biaya dan manfaat dari proyek-proyek yang bervariasi.
  • Menghasilkan sebuah implementasi keseluruhan dan strategi migrasi dan sebuah rencana implementasi detail.
7. Phase F: Migration and Planning – Pada fase ini akan dilakukan analisis resiko dan biaya. Tujuan dari fase ini adalah untuk memilih proyek implementasi yang bervariasi menjadi urutan prioritas. Aktivitas mencakup penafsiran ketergantungan, biaya, manfaat dari proyek migrasi yang bervariasi. Daftar  prioritas proyek akan berjalan untuk membentuk dasar dari perencanaan implementasi detail dan rencana migrasi.
8. Phase G: Implementation Governance – fase ini mencakup pengawasan terhadap implementasi arsitektur.
Tujuan dari fase ini adalah :
  • Untuk merumuskan rekomendasi dari tiap-tiap proyek implementasi
  • Membangun kontrak arsitektur untuk memerintah proses deployment dan implementasi secara keseluruhan
  • Melaksanakan fungsi pengawasan secara tepat selagi sistem sedang diimplementasikan dan dideploy
  • Menjamin kecocokan dengan arsitektur yang didefinisikan oleh proyek implementasi dan proyek lainnya.
9.  Phase H: Architecture Change Management – fase ini mencakup penyusunan prosedur-prosedur untuk mengelola perubahan ke arsitektur yang baru.  Pada fase ini akan diuraikan  penggerak perubahan dan bagaimana memanajemen perubahan tersebut, dari pemeliharaan sederhana sampai perancangan kembali arsitektur. ADM menguraikan strategi dan rekomendasi pada tahapan ini. Tujuan dari fase ini adalah untuk menentukan/menetapkan proses manajemen perubahan arsitektur untuk arsitektur  enterprice  yang baru dicapai dengan kelengkapan dari fase G. Proses ini akan secara khusus menyediakan monitoring berkelanjutan  dari hal-hal seperti pengembangan teknologi baru dan perubahan dalam lingkungan bisnis dan menentukan apakah untuk menginisialisasi secara formal siklus evolusi arsitektur yang baru.
10. Requirements Management – menguji proses pengelolaan architecture requirements sepanjang siklus ADM berlangsung.


Sumber: https://bambangsuhartono.wordpress.com/2014/02/26/togaf-salah-satu-metodologi-dalam-pembuatan-it-blue-print/