Struktur organisasi DataOps yang Ideal

Komunikasi eksternal organisasi cenderung mencerminkan komunikasi internalnya. Itulah yang diajarkan Melvin Conway kepada kami, dan itu berlaku untuk rekayasa data. Jika Anda tidak memiliki operasi data yang jelas atau tim “DataOps”, output data perusahaan Anda akan sama berantakannya dengan inputnya.

Operasi data adalah proses perakitan infrastruktur untuk menghasilkan dan memproses data, serta memeliharanya. Ini juga nama tim yang melakukan (atau harus melakukan) pekerjaan ini—operasi data, atau DataOps. Apa yang dilakukan DataOps? Nah, jika perusahaan Anda memelihara pipeline data, meluncurkan satu tim di bawah moniker ini untuk mengelola saluran pipa tersebut dapat membawa elemen organisasi dan kontrol yang sebelumnya kurang.

DataOps juga tidak hanya untuk perusahaan yang menjual data mereka. Sejarah terbaru telah membuktikan bahwa Anda memerlukan tim operasi data tidak peduli asal atau penggunaan data itu. Pelanggan internal atau pelanggan eksternal, semuanya sama. Anda memerlukan satu tim untuk membangun (atau jujur saja, mewarisi dan kemudian membangun kembali) pipeline. Mereka haruslah orang yang sama (atau, untuk banyak organisasi, orang) yang menerapkan alat pengamatan dan pelacakan serta memantau kualitas data di keempat atributnya.

Dan tentu saja, orang-orang yang membangun pipeline haruslah orang yang sama yang mendapatkan peringatan PagerDuty yang ditakuti ketika dasbor tidak berfungsi—bukan karena itu menghukum, tetapi karena itu mendidik. Ketika orang benar-benar memiliki kepentingan langsung, cara mereka membangun sesuatu akan berbeda. Ini adalah insentif yang baik dan memungkinkan pemecahan masalah yang lebih baik dan resolusi yang lebih cepat.

Terakhir namun tidak kalah pentingnya, tim operasi data membutuhkan misi—misi yang melampaui sekadar “memindahkan data” dari titik A ke titik B. Dan itulah sebabnya bagian “operasi” dari judul mereka sangat penting.

Operasi data membangun proses yang tangguh untuk memindahkan data demi tujuan yang dimaksudkan. Semua data harus pindah karena suatu alasan. Seringkali, alasannya adalah pendapatan. Jika tim operasi data Anda tidak dapat melacak garis yang jelas dari tujuan akhir itu, seperti tim penjualan yang memiliki perkiraan yang lebih baik dan menghasilkan lebih banyak uang, hingga aktivitas manajemen pipeline mereka, Anda memiliki masalah.

Tanpa operasi, masalah akan muncul saat Anda meningkatkan skala:

• Duplikasi data
• Kolaborasi bermasalah
• Menunggu data
• Plester yang akan meninggalkan bekas luka
• Masalah penemuan
• Alat yang terputus
• Inkonsistensi pencatatan
• Kurangnya proses
• Kurangnya kepemilikan dan SLA

Jika terjadi pemutusan sambungan, Anda hanya mempraktikkan manajemen data yang biasa saja. Manajemen data adalah aspek pemeliharaan rote dari operasi data. Meskipun penting, hal ini tidak strategis. Saat Anda berada dalam mode pemeliharaan, Anda mencari alasan kegagalan kolom atau pipeline yang hilang dan menambalinya, tetapi Anda tidak punya waktu untuk merencanakan dan meningkatkan.

Pekerjaan Anda menjadi “operasi” sejati ketika Anda mengubah tiket masalah menjadi perbaikan berulang. Seperti, misalnya, Anda menemukan kesalahan transformasi yang berasal dari mitra, dan Anda mengirim email kepada mereka untuk memperbaikinya sebelum mencapai pipeline Anda. Atau Anda menerapkan spanduk “peringatan“ di dasbor eksekutif Anda yang memberi tahu mereka ketika ada yang salah sehingga mereka tahu untuk menunggu penyegaran. Operasi data, sama seperti operasi pengembang, bertujuan untuk menempatkan sistem intuitif yang dapat diulang, dapat diuji, dapat dijelaskan, dan pada akhirnya mengurangi upaya untuk semua.

Itu operasi data vs manajemen data. Jadi pertanyaannya kemudian menjadi, bagaimana seharusnya tim operasi data itu disusun?

Jadi mari kita kembali ke tempat kita mulai—berbicara tentang bagaimana output sistem Anda mencerminkan struktur organisasi Anda. Jika tim operasi data Anda adalah tim “operasi” hanya dalam nama, dan sebagian besar hanya memelihara, Anda mungkin akan menerima tumpukan permintaan yang backlog permintaan yang semakin membengkak tiada henti. Anda jarang punya waktu untuk mencari udara untuk membuat perubahan pemeliharaan jangka panjang, seperti mengganti sistem atau menyesuaikan proses. Anda terjebak di kondisi respons yang melelahkan respons Jira atau ServiceNow.

Jika, di sisi lain, Anda telah mendirikan (atau meluncurkan kembali) tim operasi data Anda dengan prinsip dan struktur yang kuat, Anda menghasilkan data yang mencerminkan struktur internal berkualitas tinggi Anda. Struktur tim operasi data yang baik menghasilkan data yang baik.

Kumpulkan insinyur data, ilmuwan data, dan analis ke dalam sebuah kelompok atau “pemalut” dan minta mereka mengatasi hal-hal yang mungkin mereka bahas secara terpisah. Tidak dapat dipungkiri, ketiga perspektif ini menghasilkan keputusan yang lebih baik, lebih sedikit saling lempar tanggung jawab, dan wawasan yang lebih jauh ke depan. Contohnya, daripada ilmuwan data menulis buku catatan yang membingungkan dan kemudian memberikannya kepada engineer hingga menimbulkan proses revisi berulang, ilmuwan dan analis data bisa membicarakan kebutuhan mereka, sementara engineer menjelaskan cara pengerjaan yang tepat.
Banyak tim operasi data telah menggunakan pendekatan kerja semacam ini. Krishna Puttaswamy dan Suresh Srinivas di Uber mengatakan bahwa, “Tim perlu dibangun sebagai tim ‘keseluruhan lapisan,’ sehingga para data engineer dapat mengelola dan memahami seluruh perjalanan data dari awal hingga akhir”. Dan di situs perjalanan Agoda, tim insinyur menggunakan pemalut untuk alasan yang sama.

Lakukan ini bahkan jika Anda hanya satu orang. Setiap peran adalah “topi” yang harus dipakai seseorang . Untuk memiliki tim operasi data yang berfungsi tinggi, ada baiknya mengetahui topi mana di mana, dan siapa pemilik data untuk apa. Anda juga perlu mengurangi rentang kontrol masing-masing individu ke tingkat yang dapat dikelola. Mungkin dengan menggambarnya seperti ini akan membantu Anda membuat alasan untuk merekrut.

Apa yang dimaksud dengan manajemen tim operasi data? Lapisan koordinasi di atas struktur pemalut Anda yang berperan sebagai pemimpin pelayan. Mereka mengelola proyek, melatih, dan membuka blokir. Idealnya, mereka adalah orang yang paling berpengetahuan di tim.

Kami telah menemukan struktur ideal kami sendiri, digambarkan, meskipun ini sedang dalam proses. Yang penting untuk dicatat adalah ada satu orang yang memimpin dengan visi untuk data (VP). Di bawah mereka adalah beberapa pemimpin yang memandu berbagai disiplin data menuju visi itu (Direktur), dan di bawahnya, tim interdisipliner yang memastikan organisasi data dan fitur data bekerja bersama. (Ucapan terima kasih kepada Data Solution Architect kami, Michael Harper, untuk ide-ide ini.)

Memilih metrik North Star membantu semua orang yang terlibat memahami apa yang seharusnya mereka optimalkan. Tanpa kesepakatan seperti itu, konflik akan muncul. Mungkin “pelanggan” data internal Anda mengeluh bahwa datanya lambat. Tetapi prosesnya menjadi lambat karena pada dasarnya Anda tahu mereka ingin memprioritaskan kualitas meskipun tidak mereka katakan.

Common DataOps North Star: Kualitas data, otomatisasi (proses berulang), dan desentralisasi proses (alias swasembada pengguna akhir).

Setelah Anda memiliki North Star, Anda juga dapat menentukan sub-metrik atau sub-prinsip yang mengarah ke North Star tersebut, yang hampir selalu merupakan indikator lagging.

Atur tim sehingga kelompok yang berbeda di dalamnya harus sering berinteraksi dan meminta kelompok lain untuk hal-hal. Interaksi ini bisa menjadi sesuatu yang tak ternilai harganya. “Di mana para ilmuwan data dan insinyur belajar tentang cara kerja satu sama lain, tim ini bergerak lebih cepat dan menghasilkan lebih banyak,” kata Amir Arad, Senior Engineering Manager di Agoda.

Amir mengatakan dia menemukan salah satu nilai tersembunyi untuk sedikit redundansi lintas fungsi adalah Anda membuat orang mengajukan pertanyaan yang tidak terpikirkan oleh siapa pun di tim itu untuk ditanyakan.

“Kesenjangan pengetahuan teknik sebenarnya cukup keren. Itu bisa menyebabkan mereka meminta kami untuk menyederhanakan,” kata Amir. “Mereka mungkin berkata, ‘Tapi mengapa kita tidak bisa melakukan itu?‘ Dan terkadang, kita kembali dan menyadari bahwa kita tidak membutuhkan kode itu atau tidak membutuhkan server itu. Kadang, mereka yang bukan pakar justru memberikan perspektif atau ide baru.

Sama seperti DevOps, tim operasi data terbaik tidak terlihat, dan terus bekerja untuk membuat diri mereka menjadi mubazir. Daripada mencoba menjadi pahlawan yang turun tangan setiap saat namun justru melemahkan sistem, lebih baik mengambil peran sebagai pemimpin yang melayani. Bertujuan untuk, seperti yang dikatakan Lao Tzu, memimpin orang ke solusi dengan cara yang membuat mereka berpikir, “Kami melakukannya sendiri.”

Perlakukan tim operasi data Anda seperti tim produk. Pelajari pelanggan Anda. Simpan backlog perbaikan. Bertujuan untuk membuat alat cukup berguna sehingga data benar-benar digunakan.

Tidak ada yang namanya “terlalu dini” untuk pemantauan dan pengamatan data. Analogi yang sering digunakan untuk memaafkan penundaan pemantauan adalah, “Kami sedang membangun pesawat saat dalam penerbangan.” Bayangkan kembali visual itu. Bukankah visual itu memberi tahu Anda semua yang perlu Anda ketahui tentang kelangsungan hidup jangka panjang Anda? Analogi yang jauh lebih baik adalah arsitektur lama yang kita kenal. Semakin lama Anda menunggu untuk merakit fondasi, semakin mahal untuk memasangnya, dan semakin banyak masalah yang ditimbulkan oleh kekurangannya.

Baca: Apa yang dimaksud dengan observabilitas data?

Keputusan yang Anda buat sekarang dengan infrastruktur data Anda akan, seperti yang dikatakan Jenderal Maximus , “Gema dalam kekekalan.” Peretasan pertumbuhan hari ini adalah mimpi buruk kekacauan sistem internal yang sangat besar dan mengubah data di masa mendatang. Anda perlu mendapatkan dukungan eksekutif untuk membuat keputusan yang tidak nyaman tetapi benar, seperti memberi tahu semua orang bahwa mereka perlu menjeda permintaan karena Anda membutuhkan seperempat untuk memperbaiknya.

CASE adalah singkatan dari “copy and steal everything” (salin dan curi semuanya), sebuah cara yang sangat sederhana untuk mengatakan, jangan membangun semuanya dari awal. Ada begitu banyak layanan mikro yang berguna dan penawaran sumber terbuka saat ini. Gunakan capaian dan karya besar yang sudah ada sebagai pijakan, kemudian fokus pada 40% pipeline yang harus dikembangkan secara khusus, dan pastikan kualitasnya unggul.

Periksalah tiket di backlog Anda. Seberapa sering Anda bereaksi daripada mencegah masalah? Berapa banyak masalah yang telah Anda atasi memiliki akar masalah yang dapat diidentifikasi dengan jelas? Berapa banyak perbaikan yang bisa Anda lakukan secara permanen? Semakin proaktif Anda dalam mengantisipasi masalah, semakin mirip Anda bekerja seperti tim data ops yang sebenarnya. Dan, semakin membantu Anda akan menemukan alat bantu observabilitas data . Visibilitas penuh dapat membantu Anda melakukan transisi dari sekadar mempertahankan hingga meningkatkan secara aktif.

Tim yang secara aktif meningkatkan struktur mereka secara aktif meningkatkan data mereka. Harmoni internal mengarah pada harmoni eksternal, dalam hubungan yang akan membuat Melvin Conway bangga.

Pelajari lebih lanjut tentang platform observabilitas data berkelanjutan IBM® Databand dan bagaimana platform ini membantu mendeteksi insiden data lebih awal, menyelesaikannya lebih cepat, dan memberikan data yang lebih tepercaya kepada bisnis. Jika Anda siap untuk melihat lebih dalam, pesan demo hari ini.