Implementasi Data Vault Ketika Liburan

Jika pekerjaan membebani sedemikian rupa, sering kali hidup kita menjadi tidak imbang. Boleh jadi proyek pengembangan properti kita bikin pusing sejak membuat gambarnya. Setelah itu pendanaan bikin kita bolak balik depresi. Saat pekerjaan yang sesungguhnya bergulir, yaitu konstruksi, waktu tidur semakin dipepet. Pagi harinya kita butuh lebih banyak kopi dan doping.

Syukurlah tiga tahun terakhir saya beruntung punya kesempatan off dari pekerjaan. Perjalanan ibadah atau sekedar melancong menjadi mimpi lama yang terwujud. Sebenarnya perjalanan bisnis bisa juga punya efek rekreasi. Tapi kerja tetap kerja. Kita butuh waktu off untuk mengasah gergaji kita. Melihat keindahan dan kebesaran alam. Terlebih lagi Penciptanya. Melihat ragam budaya, sejarah, dan bahasa. Membina lagi hubungan agar lebih positif. Tentu saja dengan aktivitas fisik harian ribuan langkah dan “puluhan lantai” atau ratusan meter elevasi.

Lima belas tahunan yang lalu, saya terlibat dalam proyek pengembangan data warehouse. Sebelumnya saya sudah bereksperimen dengan proyek OLAP, sambil belajar dari buku Ralph Kimball, The Data Warehouse Toolkit. Pendekatan Kimball terkesan sederhana. Memang itu yang jadi sasaran beliau. User tidak butuh kompleksitas, kata beliau dalam suatu seminar di Jakarta sekitar tahun 1997. Model star schema adalah yang cocok untuk pengguna. Memang begitu...

Namun demikian, mengimplementasikan pendekatan star schema bisa jadi cerita lain, tergantung skala pengembangannya. Jika skalanya kecil, pendekatan ini paling baik. Pengalaman saya lima belas tahunan yang lalu menunjukkan proyek EDW dengan banyak subyek area - katakanlah puluhan tabel fakta dengan dimensi antara lima puluh sampai seratus atau bahkan lebih (jangan bahas dulu variasi kompleksitas dimensi dan tabel fakta - memakan waktu yang lama. Tiga tahun! Sakit kepala bertambah ketika kami sadar kebutuhan user sudah berubah selama tiga tahun itu. Proyek lanjutan untuk penyesuaian EDW yang sudah dibangun tidak dapat dikatakan sederhana. Conformed dimensions sulit dijaga. Akhirnya harus kompromi. Hasilnya adalah unconformed conformed dimensions

Liburan? Ah... situasi sulit dalam pengembangan dan enhancement EDW bikin liburan ga nyaman. Itupun kalau sempat. Kritik dan ketidakpuasan user terbayang-bayang terus. Apakah ini memang harus terjadi? Terjadi terus? Tentu saja tidak! Ada cara bekerja yang lebih cerdas, efektif, dan efisien. Pengguna bisa happy. Kita juga bisa. Coba deh bayangkan jalan-jalan ke tempat ini, sementara EDW berbasis Data Vault dari Dan Linstedt, yang sudah berkali-kali kita deploy tiga tahun terakhir dengan time to market yang mengesankan, berjalan lancar. Liburan makin menyenangkan karena proyek-proyek di tangan tetap terkendali dengan baik. Makasih ya, Laksmi.

Bagaimana? Mengesankan bukan? Gambar di atas saya ambil di Pamukkale, Turki, baru-baru ini. Sumber air panas menjadi sebab tempat ini menarik bagi bangsa Helenik untuk membangun Hierapolis. Air panasnya masih mengalir hingga kini, dan saya sempat merasakan hangatnya ketika merendamkan kaki di alirannya. Air panas ini juga mengaliri kontur yang berbukit-bukit membentuk travertine. Atau barangkali kisah penganut Nasrani bersembunyi di Goreme dari bangsa Romawi mampu menginspirasi kita dengan nilai kesabaran dan kecerdasan dalam membangun kota dan hunian yang aman dan reliable, seperti gambar-gambar berikut.

Kembali dari perjalanan yang luar biasa ini, saya masih terbayang dengan peradaban masa lalu yang sangat mencengangkan. Kemudian melewati jalan-jalan mulus antar dan di dalam kota-kota di Turki menambah keyakinan bagaimana penataan yang benar mampu membangkitkan kembali peradaban di masa sekarang menyongsong masa depan, setara dengan bangsa-bangsa maju lainnya.

Kota-kota yang bersih dan tertata rapi mengingatkan saya pada hubs di pemodelan DV. Jalan-jalan yang menghubungkan antar kota atau yang menghubungkan satu jalan dengan lainnya mengingatkan saya pada links. Baik kota maupun jalan memiliki properti detilnya masing-masing. Membuat jalan baru tidak harus membongkar jalan dan jembatan yang sudah dibangun sebelumnya dengan benar. Mengembangkan kota tidak berarti harus membongkar terlebih dahulu apa yang sudah dikembangkan sebelumnya dengan benar. Semua ini membuktikan manusia mempunyai kemampuan menata dengan baik, asalkan tahu cara-cara menata yang benar tersebut. Secara top down dan sekaligus bottom up, dengan mengkombinasikan kebaikan dari keduanya. Kalau ga percaya, tanya ke Yudha. Kami telah melewati perjalanan ini bersama. Implementasi EDW berbasis DV maksudnya, bukan ke Turki, tapi kayaknya dia tertarik jalan-jalan ke Turki.

Saya sih berpikir positif bahwa pembaca percaya dengan kehebatan Data Vault. Setidaknya mulai percaya. Itu langkah awal keberhasilan implementasi EDW saat liburan. Kuncinya? Buka pikiran dan belajar dari ahlinya, serta... jangan malas baca! Jangan hanya mengandalkan pendekatan star schema (star schema punya nilai tambahnya sendiri; don’t get me wrong!) yang terbukti tidak robust untuk membangun EDW - EDW sebagai saksi sejarah kehidupan. Saya pinjam istilah saksi sejarah ini dari Ahmal, yang selalu mampu menjawab tantangan pekerjaan. Tentu saja dengan sedikit penyesuaian mengikuti konteks tulisan

Selengkapnya.....

Data Warehouse di Hadoop

Sejak teknologi Hadoop ngetren beberapa tahun lalu, banyak praktisi yang berpikir untuk menerapkan data warehousing dengan teknologi big data ini. Bahkan muncul juga istilah baru (yes, another buzzword) data lake sebagai pengganti atau pelengkap data warehouse. Di kantor kami, ada juga wawasan ke sana, tetapi masih belum betul-betul bergulir implementasinya.

Sebelum kita menjajaki lebih jauh kemungkinan penerapan data lake atau apapun istilahnya dengan menggunakan Hadoop, perlu kita ketahui alasan atau latar belakang munculnya gagasan ini. Ada beberapa alasan. Yang pertama, banyak perusahaan yang menerapkan data warehousing, setelah sukses pengembangan dan implementasinya di tahun-tahun pertama, menghadapi masalah skalabilitas. Pengalaman yang berulang kali terjadi, saya dengar, adalah keharusan untuk merombak atau mengembangkan ulang data warehouse setelah tiga sampai lima tahun. Tentunya konsekuensi biayanya bikin hati miris. Opsi penggunaan teknologi alternatif NoSQL seperti Hadoop untuk mengganti data warehouse yang lama menjadi menarik.

Kedua, teknologi Hadoop adalah teknologi open source yang dipersepsi lebih murah dibandingkan RDBMS seperti katakanlah Oracle dan MS SQL, meskipun pada akhirnya ada biaya yang tetap harus dikeluarkan jika perusahaan membutuhkan support yang dapat diandalkan, misalnya dengan men-subscribe Cloudera atau Hortonworks atau yang lain. Biaya ini tidak terhindarkan, tapi tetap persepsinya lebih murah. Yang bikin masalah adalah Hadoop tidak mengenal fitur update, padahal dalam beberapa hal data warehousing membutuhkan update. Untuk mengatasinya dibutuhkan pendekatan yang berbeda dari sebelumnya. Muncullah beberapa pendekatan baru, di antaranya data lake.

Ketiga, perusahaan membutuhkan segala jenis data, baik yang terstruktur, setengah terstruktur, maupun tidak terstruktur sama sekali. RDBMS tidak pas untuk mengolah data yang setengah terstruktur, apalagi yang tidak terstruktur sama sekali. Teknologi Hadoop dengan schemeless repository punya keunggulan signifikan dibandingkan RDBMS. Pada ujung yang paling ekstrem, katanya, kita bisa cemplungkan segala sesuatu ke dalam Hadoop tanpa harus peduli dengan skema atau struktur tabelnya. Skema baru dibutuhkan ketika membaca data, tidak pada saat menulis data ke Hadoop. Tentu saja kita mesti hati-hati dengan pandangan ekstrem yang too good to be true seperti itu.

Keempat, teknologi Hadoop memungkinkan proses yang sangat paralel dengan mendistribusikan beban pemrosesan ke distributed nodes yang secara mandiri masing-masing memiliki computing power dan storage sekaligus. Karena sifatnya terdistribusi ke simpul-simpul mandiri yang sendirinya memiliki computing power dan storage sekaligus, cluster Hadoop tidak butuh banyak data movement. Itu salah satu sebabnya Hadoop bisa sangat cepat. Di sini kita tidak akan mengelaborasi lebih dalam mengenai arsitektur Hadoop, mekanisme kerja, dan jeroannya. Cukuplah pembaca mencari sendiri di internet artikel-artikel yang hampir tidak terbatas mengenai hal teknis ini. Sebetulnya kemampuan pemrosesan secara paralel ini ada juga di RDBMS seperti Oracle, tapi jika kita menerapkan Hadoop, kita tidak membutuhkan server high end. Ini artinya lebih murah. Jika suatu saat diperlukan tambahan kapasitas, kita tinggal menambah sejumlah server mid range atau bahkan bisa juga low end ke cluster Hadoop yang telah kita miliki. Skalabilitas yang mengagumkan! 

Kembali pada gagasan membuat data warehouse di atas Hadoop, saya ingin menceritakan sedikit mengenai pemodelan dan metodologi Data Vault, saat ini sudah DV 2.0, yang diciptakan oleh Dan Linstedt. Meskipun tidak pernah ketemu langsung dengan beliau, saya berinteraksi intensif dengan teman-teman yang memiliki sertifikat dari Dan Linstedt, sebagiannya anggota atau mantan anggota tim saya, sebagiannya lagi tim Hasnur Ramadhan. Hasnur Ramadhan adalah satu dari sedikit orang Indonesia yang memiliki sertifikasi DV. Bahkan dia berkali-kali memperbaharui sertifikatnya. Tidak heran kalau dia dekat dengan Dan Linstedt.

Dari interaksi dengan orang-orang hebat tersebut dan belajar dari materi Data Vault yang dibawa oleh Ginanjar dan Laksmi waktu dulu mereka berguru ke Dan Linstedt di Colorado ataupun materi yang tersedia di internet, saya dapat memahami metodologi DV ini secara konseptual. Malah pada kondisi tidak tersedia bahan belajar yang cukup, somehow I am capable of connecting the dots. Pemikiran pribadi sering saya diskusikan dengan tim saya, di antaranya Yudha dan Ahmal, dua anak muda berbakat yang memampukan kami menerapkan Data Vault di kantor, tentu saja pada beberapa hal dibantu dan terinspirasi oleh Pak Hasnur dan timnya yang hebat - ketika mereka menjadi konsultan kami di 2015 di proyek Julia.

Baru-baru ini, akhir Januari, Pak Hasnur kasih khabar ke saya. “Lagi di Berlin, ngambil DV 2.0 Bootcamp,” katanya. Tentu saja khabarnya dilengkapi foto berdua Dan Linstedt, yang kelihatan lebih berisi badannya. Saya minta sampaikan salam ke Daniel. Sayang acara sudah selesai dan beliau tidak ketemu lagi dengan Dan Linstedt. Setelah itu, baru berapa hari lalu, Pak Hasnur pamer sertifikat DV 2.0 ke saya lewat pesan WA. Dia juga kasih oleh-oleh gambar arsitektur DV 2.0 terbaru. Dia kemudian menawarkan integrasi DV dengan Cloudera. Kontan aja sifat usil saya muncul. Lantaran tahun 2015 waktu ngobrol dengan Pak Hasnur, saya sudah bilang mau implementasi DV di Hadoop, dan kebetulan saat ini kami memang sedang mencobanya. Saya bilang Pak Hasnur kali ini harus belajar ke kami, tapi dasar dia dari dulu ga mau kalah sama saya. “Ga certified,” katanya! Saya tunjukkan percakapan WA itu ke Yudha dan Ahmal. Kami tertawa-tawa. Lalu salah satunya bilang (bercanda) bahwa itu ofensif. Saya nyantai aja.

Perlu diketahui bahwa DV 2.0 sudah beberapa tahun lalu dipublikasi oleh Dan Linstedt. DV 1.0 jauh lebih awal di tahun 2000-an, yang diciptakannya berdasarkan pengalaman bertahun-tahun sebelumnya menjadi konsultan pengembangan sistem-sistem besar dengan skala terabyte bahkan petabyte. Saya mengikutinya di dunia maya. Saya juga mengikuti Dan Linstedt bubar dengan beberapa rekannya di awal-awal mempromosikan Data Vault. Kemudian dia bermitra dengan orang baru. Pada saat-saat itu, lahirlah DV 2.0.

Terus terang saya mengikuti newsletter dari Dan Linstedt dan rekannya. Beberapa artikel di email dan beberapa video dari "Dan and Sanjay" (ya orang India) saya pelajari. Secukupnya sih, selama saya ada waktu di tengah pekerjaan yang menumpuk. Di tahun 2015 itu, saya sudah tahu dari kiriman email “Dan and Sanjay” bahwa DV 2.0 bisa diterapkan di atas Hadoop. Saya tidak perlu sertifikasi untuk mengatakan bahwa kami akan terapkan DV di atas Hadoop. Saya juga tidak perlu menunggu sertifikasi untuk menerapkan hash key di DV, menggantikan sequence key. Beda dengan Pak Hasnur. Beliau lebih butuh landasan akademik dan profesional. Hal ini bisa dipahami karena beliau adalah konsultan yang jualan di industri.

Mungkin pembaca ada yang ragu juga. Apa memang bisa menerapkan EDW berbasis Data Vault di atas Hadoop? Untuk pembaca yang seperti itu, ada baiknya ikut DV 2.0 Bootcamp atau kelas DV 2.0 lainnya. Jadwalnya sudah dipublikasi. Berdasarkan pengalaman tahun-tahun lalu, penyelenggaraannya tersebar di Amerika, Eropa, dan sedikit di Australia. Di Indonesia? Sayang sekali belum. Kalau Dan Linstedt mau buka kelas di Jakarta, pasti in syaa Allah saya hadir. Malah saya mau traktir dia, tentu saja kalau dia berkenan, dan saya mau pertemukan dia dengan tim saya yang warbiasah.

Pada titik ini, saya ingin menyarankan pembaca yang berencana membuat data warehouse di Hadoop atau membuat data lake, pakailah pemodelan dan metodologi DV 2.0. Data mudah ditata di dalam Data Vault. Menambahkan data baru - apakah hanya kolom baru, atau satu tabel transaksi, atau sekian banyak tabel baru - sangat mudah, tanpa mengganggu tabel-tabel yang sudah ada di DV. Sangat fleksibel! Proses ELT-nya sangat standard dan polanya mudah di-reuse. Kalau ada uang, DWA (Data Warehouse Automation) tools seperti BIReady dan WhereScape akan sangat membantu. Atau pembaca bisa bikin sendiri sistem DWA.

Apakah performance DV akan turun seiring dengan bertambahnya data dan tabel? Tidak, karena DV punya skalabilitas yang tinggi dan mendukung proses yang sangat paralel, terserah mau menggunakan Hadoop atau RDBMS yang mendukung MPP. DV juga sangat sangat sedikit melakukan proses lookup dalam tahapan ELT-nya. Ini tentu mendukung performance yang prima, dan yang tidak kalah penting tidak ada update di dalam proses ELT-nya. Fitur tidak ada update ini yang memungkinkan penerapan DV di Hadoop. Banyak lagi keunggulannya. Kami sudah membuktikannya di tempat kami. Faktanya, penerapan DV di seluruh dunia sangat sangat banyak dan terus tumbuh.

Jika pembaca masih belum percaya dan memilih metode lain atau berusaha membuat sendiri metodenya atau mengabaikan perlunya metodologi sembari mencemplungkan segala sesuatu ke dalam Hadoop, maka bersiaplah untuk membangun data lake tetapi pada akhirnya hanya menghasilkan data swamp! Atau mungkin ada juga yang berpikir persetan dengan Hadoop dan akan tetap menggunakan RDBMS kalau perlu berupa appliance, sembari tetap mengandalkan hanya star schema atau snowflake schema dari Ralph Kimball. Untuk yang memilih jalan ini, siap-siap saja dalam waktu tiga tahun untuk merombak data warehouse yang sudah dikembangkan, sambil menyalahkan infrastruktur!

Selengkapnya.....

Dan Linstedt, Data Vault, dan EDW di Kantor Kami

Saya kenal Dan Linstedt lewat dunia maya saja. Dalam pencarian pendekatan yang lebih efektif dalam mengembangkan sistem informasi, data warehouse khususnya, saya ga sengaja berkunjung ke situs tdan.com di mana Dan Linstedt menjadi salah satu penulisnya. Itu sekitar tahun 2008. 

Dia menulis mengenai Data Vault (sekarang sudah DV 2.0) yang diklaimnya mendapat pengakuan dari Bill Inmon, mbahnya data warehouse. Saya sudah kenal Bill Inmon terlebih dahulu yang bersama Claudia Imhoff memperkenalkan konsep data warehouse berupa Corporate Information Factory (CIF). Saya juga sudah kenal terlebih dahulu dengan Ralph Kimball yang pendekatannya kami gunakan dalam mengembangkan EDW di kantor dari 2002 sampai 2007. 

Dapat dikatakan pendekatan Kimball yg kami gunakan cukup berhasil. Kami ga perlu membuat model data top down ideal enterprise-wide untuk mengembangkan EDW. Jadinya bisa cepat menghasilkan. Murah tentu saja. Tapi dengan berjalannya waktu menjadi semakin sulit untuk menambahkan dan mengintegrasikan data baru ke EDW. Penyakitnya yang utama di antara beberapa hal lainnya adalah kesulitan memelihara tabel conform dimensions seiring dengan penambahan subyek area baru. Dan Linstedt menyebut penyakit ini dimensionitis. 

Sebenarnya sebelum ketemu konsep DV Dan Linstedt, saya menemukan DW 2.0 Bill Inmon terlebih dahulu. DW 2.0 dimaksudkan Inmon sebagai koreksi dari penyimpangan-penyimpangan istilah dalam perkembangan dunia data warehouse. Di 2008, saya minta Laksmi dan Ginanjar mempelajari keduanya: DW 2.0 dari Inmon dan DV (waktu itu sebut saja masih DV 1.0) dari Dan Linstedt.

Kebetulan sekitar tahun 2008 itu, saya tidak lagi in charge dalam pengembangan EDW di kantor. Saya waktu itu dipindah tugas ke QA dan PMO. Kami berusaha mendapatkan buy in terhadap DW 2.0 dan DV. Toh yang mengerjakan adalah kolega kami yang lain. Laksmi dan Ginanjar yang sudah mendapat sertifikasi DV modeling dari Linstedt langsung di Colorado, dengan saya sebagai promotornya, tentunya punya kewajiban moral agar investasi pengetahuan ini tidak sia-sia. 

Apa mau dikata, pembenahan EDW di kantor kami waktu itu tidak bergulir. Pengembangannya stagnan. Operasional EDW yang telah dibangun 2002-2007 terseok-seok. Sampai suatu hari, setelah serangkaian reorganisasi dan dinamika lainnya, tahun 2013 saya ditugaskan kembali menangani EDW di kantor kami. Beruntung divisi baru yang saya pimpin ini diperkuat oleh beberapa kolega lama yang pernah punya eksposur dalam pengembangan EDW sebelumnya, termasuk Laksmi dan Julia.

Saya juga merasa beruntung sekali dengan masuknya dua anak muda cerdas dan berbakat, yg ternyata dari satu sekolahan. Ahmal yang duluan masuk, 2013, kurang lebih berbarengan dengan masuknya saya ke divisi ‘lain sendiri’ itu. Disusul Yudha tahun 2014. Bersama Ahmal, saya berhasil melalui masa survival EDW paling sulit di 2013 dan 2014. Keberhasilan melalui masa paling sulit dengan kondisi morale paling rendah menjadi titik tolak bagi kami untuk menyongsong era baru. 

Selanjutnya, bersama Yudha dan Ahmal, kami berhasil menerapkan DV 2.0 hingga saat ini kami mampu mengembangkan EDW yg sangat modern dengan time to market yang luar biasa. Performance ETL/ELT? Itu juga luar biasa! Penambahan data 250 juta record bisa selesai beberapa jam saja, meskipun hanya dengan server database Oracle menengah. Rencananya mesin database akan kami ganti dengan yang high end, malah Yudha dan Ahmal sedang saya tugaskan untuk bersiap menerapkan DV 2.0 di atas Hadoop, sehingga EDW kami segera masuk ke skala “petabytes and beyond” dengan performance dan skalabilitas yang sangat memuaskan.

Sebenarnya kekuatan dari sisi teknis bukan segalanya, tetapi dalam pengembangan EDW yang ga pernah ada habisnya, kapasitas yang bagus dari sisi teknis merupakan key success factor. Kita dapat menghemat waktu menyelesaikan isu teknis dan dapat mengalokasikan lebih banyak waktu untuk ketemu user. User merasa puas dan yang paling penting “keep coming back” kepada kami. Tentu saja bukan tidak ada masalah sama sekali, tapi masalah dapat diselesaikan, dengan kolaborasi yang baik dan kadang dengan sedikit marah-marah, misalnya pas akhir 2017 kemarin (maaf ya gaes).

Rasa terima kasih tentunya harus juga saya tujukan ke kolega-kolega saya lainnya yang tidak bisa saya sebutkan satu per satu. Dari pihak eksternal, Pak Hasnur Ramadhan dengan tim yang luar biasa juga telah memberikan warna tersendiri dalam warisan kami di divisi yang sekarang ‘menceng dewe’ ini. Bagaimana kisah survival-revival kami mungkin perlu satu buku tersendiri - setidaknya satu artikel tersendiri - untuk menceritakannya. 

O God... I am very grateful for this wonderful experience. 

Selengkapnya.....

Big Data: Big Untung

Seperti penjelasan sekenanya di artikel Big Data: Big Bingung, teknologi big data adalah suatu teknologi yang memungkinkan pengolahan catatan digital yang terus menerus tercipta setiap saat dengan velocity tinggi dan volume besar, baik lokal maupun global, menjadi informasi yang bernilai tinggi. Sumber data digital tersebut bermacam-macam. Variasi dan formatnya juga bermacam-macam.  Data scientist menggunakan big data analytics untuk menemukan (men-discovery) informasi yang bernilai tinggi tersebut, yang kemudian dapat digunakan dalam proses produksi.

Biasanya artikel mengenai big data menyebut internet dan jejaring sosial semacam Facebook dan Twitter sebagai sumber big data. Ya, contoh itu memang paling mudah. Yang agak sulit dimengerti, meskipun sudah berjalan di perusahaan-perusahaan besar, adalah big data berupa streaming yang bersumber dari sensor-sensor yang mengukur dan kemudian mengirim ukurannya ke tempat pengolahan. Misalnya sensor yang terpasang di turbin-turbin produksi General Electric (GE) yang jumlah turbinnya saja di seluruh dunia luar biasa banyak. Apalagi jumlah sensor dan data yang diproduksi secara keseluruhan. Mungkin kita bertanya-tanya apa untungnya buat GE mengumpulkan semua data yang segunung itu?

Ayo, kita hela nafas dikit... Ga apa. Wajar aja kalau big bingung dengan big data. Bayangkan jika data dari sensor turbin-turbin GE yang terpasang di seluruh dunia itu bisa diolah oleh para data scientist GE untuk mengetahui keadaan dari setiap turbin. Setiap saat! Lebay ya? Apakah turbinnya, misalnya di padang pasir Timur Tengah, masih berjalan normal. Apakah kinerja mulai menurun? Apakah ada fungsi yang tiba-tiba tidak berjalan. Dengan pengetahuan itu saja, GE mampu menyediakan layanan yang sangat cepat tanggap ke pengguna turbinnya. Lebih jauh lagi, GE bisa lebih efisien mengelola service termasuk site visit ke padang pasir dengan lebih murah. GE untung. Customer-nya juga untung. Keuntungan dari big data!

Contoh yang lebih sehari-hari misalnya dalam manajemen lalu lintas. Barangkali Bu Airin tiba-tiba terinspirasi menerapkannya di Tangsel. Memang kasus ini agak ngarang sih, tapi who knows? Umpamanya Pemkot Tangsel bisa memasang sensor di seluruh jalanan, untuk permulaannya misalnya di tiap perempatan atau lampu lalu lintas. Sensor itu berfungsi mengukur kondisi lalu lintas. Berapa kecepatan kendaraan? Berapa kendaraan yang lewat? Misalnya saja itu bisa dilakukan. Kemudian setiap sensor mengirim data pengukurannya ke kantor pengelola lalu lintas. Dengan data scientist yang cakap yang kemudian bisa membuat algoritma ciamik untuk pemantauan, kondisi lalu lintas tiap jalanan di Tangsel bisa diketahui setiap saat.

Sebenarnya Bu Airin punya alternatif lain. Bisa saja Bu Airin menyewa satelit khusus memotret dan mengirim gambar Tangsel setiap berapa waktu. Perangkat lunak analytics yang mampu mengolah gambar memang masih harus dibeli, tapi kalau mampu, lagi-lagi Pemerintahan Bu Airin bisa mengetahui kondisi jalanan setiap saat. Dengan pengetahuan itu, manajemen lalu lintas bisa lebih baik. Misalnya, lebih cepat memutuskan kapan harus mengirim petugas. Ke lokasi mana saja. Kantor manajemen lalu lintas kemudian bisa memberikan penerangan ke pengguna jalan agar menghindari area tertentu atau merekomendasikan jalur alternatif, bekerja sama dengan stasiun radio atau lewat akses langsung para pengguna mobile app Pemkot Tangsel. Lebih canggih lagi seandainya dari data satelit atau sensor di atas, yang pasti volumenya luar biasa, Bu Airin dan staf bisa mengembangkan automated traffic control system.

Mahal? Mau murah? Mungkin bisa bekerjasama dengan GoogleMap atau Waze. Basisnya pengumpulan data dari jejaring sosial. Jadi 'sensor' dalam hal ini adalah para pengendara itu sendiri yang mengirim sinyal lokasi dan kecepatannya masing-masing. Saya mendengar dari seorang kawan. Katanya dia pernah membaca berita bahwa Jakarta bermaksud bekerjasama dengan Waze dalam kaitan dengan manajemen lalu lintas ini.

Lalu apa lagi manfaat big data? Kan sayang kalau sudah menyimpan big data yang amat bejibun, tetapi tidak banyak manfaatnya? Mau untung malah buntung. Kita-kita ini pengguna teknologi sudah semestinya berhati-hati. Tidak boleh percaya begitu saja pada vendor. Vendor biasanya mengatakan yang bagus-bagus saja. Malah vendor cukup sering mengiyakan pemanfaatan suatu teknologi yang sebetulnya kurang tepat. Bahasa kerennya: business use case tidak cocok. Pengamat yang berada di pinggiran malah jadi sinis. Wah... si fulan menginisiasi proyek terkait big data atau teknologi apa saja hanya untuk manjang-manjangin pengalaman kerja (credential). Ada apa pula dia dengan vendor itu?

Runyam kan kalau kondisinya jadi penuh curiga gitu? Begini... Saya mau share dikit. Saya diminta baca buku big data @ work karangan Thomas Davenport. Bagus bukunya. Beliau memang bukan orang yang tahu detil mengenai IT. Beliau mungkin lebih tepat kalau disebut sebagai penulis strategi. Di bukunya, beliau membuat tiga kategori business case pemanfaatan big data.

Yang pertama adalah cost/time reduction. Yang kedua adalah new products and services. Yang ketiga adalah internal business decision support. Untuk yang ketiga ini perlu sedikit hati-hati. Thomas Davenport mengatakan:

"Traditional information manajement and analytics were primarily about supporting internal decisions. Big data is somewhat different in this regard..."

"... instead of creating reports or presentations that advise senior executive on internal decisions, data scientists commonly work on customer-facing products and services."

Namun demikian, menurut Davenport, bukannya tidak ada kasus yang bagus untuk pemanfaatan big data dalam mendukung keputusan. Ada ga contoh-contohnya? Ah, tunggu ya, masih ada dua bab yang belum selesai saya baca. In syaa Allah, saya lanjutin di artikel berikutnya. Kalau untuk mendukung riset, ada ga? Mestinya ada. Saya pernah baca, ada peneliti yang menggunakan Google Trend untuk mengikuti 'keyword' tertentu kemudian membandingkannya dengan indikator yang biasa diperoleh secara konvensional.

Selengkapnya.....

Big Data: Big Problem

Di artikel sebelumnya, Big Data: Big Promise, saya sudah sampai pada penjelasan bagaimana para pembisik berkolaborasi dalam memberikan suplai bisikan ke tuannya. Dengan model SECI dari Nonaka-Takeuchi, kita bisa mengelompokkan kegiatan kolaborasi para pembisik dalam empat kegiatan: sosialisasi, eksternalisasi, kombinasi, dan internalisasi. Di artikel itu juga saya sudah menyinggung dalam melakukan empat kegiatan itu, khususnya internalisasi, para pembisik memerlukan data yang diaksesnya dari data warehouse, database, atau DARI MANA SAJA.

Huruf kapital yang digunakan untuk frasa DARI MANA SAJA mencerminkan agitasi dan intimidasi, karena memang jika kita masih big bingung dengan big promise dari big data, tidak perlu terlalu lama menyimpulkan kita menghadapi big problem. Eits... jangan buru-buru. Sebelumnya, mungkin kita perlu meninjau kebalikannya, little data: little problem, dulu.

Dari dulu, buku-buku maupun konsultan suka sekali dengan gambar piramida. Mungkin karena bentuknya memberi kesan kokoh, maka model ini menggoda untuk digunakan. Lagipula Piramida adalah salah satu keajaiban dunia. Dasar piramida mewakili data yang diperoleh dari sumbernya. Masih mentah, raw data. Tengah-tengah piramida hingga puncaknya mewakili hasil pengolahan data dari dasar piramida, untuk menghasilkan informasi bahkan pengetahuan. Di puncak piramida, sang tuan sudah menunggu asupan dari bawah untuk mengambil tindakan atau keputusan!

Kalau piramida itu digunakan untuk menggambarkan sistem informasi atau aplikasi, maka dasarnya adalah transaction processing systems, tengahnya management information systems, dan atasnya decision support systems atau executive information systems. Keren kan? 

Ini dia masalahnya. Keren sih keren, tapi secara pribadi, gambar itu tidak saya sukai. Pertama, ada nuansa bahwa dasar piramida harus terisi utuh dulu sebelum tengah-tengah dan puncak piramida dapat dibangun. Seorang teman kantor, dulu juga saya pernah, ngomong bagaimana mungkin kita bisa membuat MIS dan EIS yang bagus kalau kualitas TPS kita masih rendah, malah banyak yang manual. Sekarang saya tidak sependapat dengan pandangan ini.

Kedua, piramida itu memang terkesan kokoh, tapi tidak menampilkan unsur manusia secara tepat, padahal manusia adalah elemen terpenting dalam suatu sistem informasi, khususnya sistem informasi konsumsi pimpinan strategis. Pembisik-pembisik itu tidak tergambar di piramida. Akhirnya saya bikin model saya sendiri. Staf saya menyebutnya belah ketupat terbelah awan. Hahahaha.

Ini gambar belah ketupat terbelah awan ala saya.

Lho koq dasar piramida yang kokoh dihilangkan? Iya, menurut saya harus dihilangkan. Kekokohannya hanya ilusi. Tumpuan sistem informasi modern tetap saja pada orang-orangnya, yaitu para pembisik. Bagian bawah yang runcing mewakili filosofi saya bahwa untuk mengintegrasikan data dari berbagai sumber diperlukan pendekatan one bite at a time. Ini tidak berarti harus satu sumber saja pada satu saat, tapi integrasikanlah beberapa sumber yang telah tersedia. Ada pertimbangan manageability. Pilihlah yang signifikan. Pake hukum Paretto. Ga perlu kita menunggu semua TPS lengkap dan berkualitas, baru bikin enterprise data warehouse.

Tahu ga? Realitanya para pembisik sudah biasa mencukupkan diri dengan keterbatasan data yang ada dan tetap harus ngasih bisikan. Memang mereka ngedumel, tapi keluh kesahnya itu positif dan memicu kreativitas. Apatah lagi sang tuan? Dalam kondisi tidak ada data sama sekali, ketika tindakan harus diambil, tetap aja beliau buat keputusan. Memang kondisi tanpa data sama sekali adalah ekstrem. Dalam dunia nyata, kondisinya selalu di tengah-tengah. Data ada. Informasi tersedia, tapi ga sempurna. Bualan informasi sempurna hanya ada di ideologi ekonomi yang itu tuh.

One bite at a time memang menggeser tumpuan. Menggeser tanggung jawab dari aplikasi TPS dan MIS semata ke para pembisik. Itu sebabnya para pembisik itu harus digambarkan lebih eksplisit lagi di dalam model. Hingga saat ini, saya masih nyaman dengan gambar awan. Kesannya buat saya adalah magic. Ajaib... Dengan segala keterbatasan, bisnis tetap berjalan. Hidup para pembisik!

Oya, penting juga dicatat proses kolaborasi para pembisik dapat difasilitasi dengan solusi enterprise content management. Sekarang ini, minimal harus difasilitasi email, kemampuan akses secara mobile, dan integrasi dengan office. Idealnya... semua konten terkelola dengan efektif dan efisien di 'satu' tempat dan dapat ditemukan kembali dengan mudah. Kalau saja saya salah satu pembisik, saya barangkali perlu mengetahui bisikan saya di periode yang lalu apa aja, kemudian bisikan orang lain dalam menanggapi bisikan saya seperti apa. Saya mungkin perlu juga me-reuse atau me-leverage bisikan-bisikan orang lain ke dalam bisikan saya. Proses kombinasi!

Masih bersama saya? Mudah-mudahan masih ingat, meskipun artikel ini mulai kepanjangan, one bite at a time ini juga kembali ke joke yang saya lempar di atas, little data: little problem. Model belah ketupat terbelah awan  hemat saya cukup mewakili filosofi dan pendekatan ala saya di atas. Model piramida gimana? Kalau model piramida itu, little data: big problem. Manfaat terbatas, tapi masalah banyak. Cape deh. Pekerjaan ga selesai-selesai.

Nah ini saatnya kita masuk ke penjelasan yang lebih mendalam mengenai big data: big problem... Ah, katanya gambar mewakili ribuan kata. Kira-kira gambar berikut ini mampu menyampaikan pesan ga ya? 

Area baru yang merupakan wilayah big data sangat berbeda dengan area little data. Sumbernya tidak konvensional DARI MANA SAJA dan variasinya luar biasa, di samping volume dan velocity-nya berkali-kali-kali lipat, sampai mencapai APABYTE, hehehe. Area baru ini bisa seluas-luasnya area yang menjadi concern pengambil keputusan. Kalau pengambil keputusan dimaksud adalah pengambil kebijakan ekonomi yang berskala nasional dengan dampak nasional bahkan beyond, bisa dibayangkan seberapa luas area big data yang berpotensi masuk radar beliau. Lagi-lagi, peran pembisik sangat vital, bahkan lebih vital lagi.

Dengan struktur yang ga jelas, big data harus diolah sedemikian rupa oleh pembisik agar berguna. Kalau tidak begitu, cuma menuhin tempat aja, padahal keputusan tetap dapat diambil dengan data seadanya, little data. Malahan dalam perspektif tertentu, big data harus bisa ditransformasi oleh para pembisik menjadi little data yang sudah lebih jelas manfaatnya. Dalam perkataan lain, big data masih bernilai rendah. Potensinya masih harus diolah untuk menghasilkan little data yang lebih bernilai tinggi.

Akhirnya... persoalan-persoalan di atas, meskipun sudah mulai difasilitasi dengan teknologi baru, seperti Hadoop, analytics, information discovery, dan sebagainya, tetap menjadi persoalan, big problem. Barangkali yang terbesar adalah bagaimana manajemen bisa meng-upgrade para pembisiknya menjadi ahli dalam pemanfaatan big data. Ini peran baru para pembisik sebagai ilmuwan data, data scientist

Selengkapnya.....