Erik Gfesser, Arsitek Utama untuk Praktik Data SPR – Seri Wawancara

Erik bergabung dengan praktik data Emerging Technology Group SPR sebagai Arsitek Utama pada tahun 2018.

Erik menjadi ahli dalam data, pengembangan open source menggunakan Java, dan arsitektur perusahaan yang praktis, termasuk membangun PoC, prototipe, dan MVP.

Apa yang awalnya menarik Anda untuk mempelajari mesin pembelajaran?

Kemampuan aplikasi untuk terus belajar. Saya memulai karir pengembangan saya sebagai analis data senior menggunakan SPSS di sebuah perusahaan riset pasar global, dan kemudian mengintegrasikan penggunaan mesin aturan bisnis yang disebut Drools ke dalam aplikasi yang saya bangun untuk klien, tetapi output dari semua pekerjaan ini pada dasarnya statis.

Saya kemudian bekerja melalui pelatihan perbaikan proses, selama waktu instruktur mendemonstrasikan secara rinci bagaimana mereka dapat memperbaiki, melalui statistik dan metode lain, proses bisnis yang digunakan oleh klien mereka, tetapi output ini juga sebagian besar difokuskan pada titik waktu. Pengalaman saya bekerja untuk memperbaiki produk perawatan kesehatan yang saya dan rekan saya bangun selama periode waktu yang sama adalah apa yang menunjukkan kepada saya mengapa pembelajaran terus-menerus diperlukan untuk upaya tersebut, tetapi sumber daya yang sekarang tersedia tidak ada pada saat itu.

Menariknya, minat saya pada mesin pembelajaran telah menjadi lingkaran penuh, karena penasihat pasca sarjana saya memperingatkan saya terhadap spesialisasi dalam apa yang kemudian disebut kecerdasan buatan, karena musim dingin AI pada saat itu. Saya memilih untuk menggunakan istilah seperti ML karena istilah-istilah ini memiliki konotasi yang lebih sedikit, dan karena bahkan AWS mengakui bahwa lapisan layanan AI-nya sebenarnya hanya merupakan abstraksi tingkat yang lebih tinggi yang dibangun di atas lapisan layanan ML-nya. Meskipun beberapa hype ML di luar sana tidak realistis, ini menyediakan kemampuan yang kuat dari perspektif pengembang, selama praktisi ini mengakui bahwa nilai yang diberikan oleh ML hanya sebaik data yang diproses olehnya.

Anda adalah advokat besar untuk open source, bisa Anda membahas mengapa open source sangat penting?

Salah satu aspek tentang open source yang saya telah perlu menjelaskan kepada eksekutif selama beberapa tahun adalah bahwa manfaat utama dari open source bukanlah bahwa penggunaan perangkat lunak tersebut tersedia tanpa biaya moneter, tetapi bahwa kode sumbernya tersedia secara gratis.

Tambahnya, pengembang yang menggunakan kode sumber ini dapat memodifikasinya untuk keperluan mereka sendiri, dan jika perubahan yang disarankan disetujui, membuat perubahan tersebut tersedia untuk pengembang lain yang menggunakannya. Faktanya, gerakan di balik perangkat lunak open source dimulai karena pengembang menunggu lama bagi perusahaan komersial untuk membuat perubahan pada produk yang mereka lisensikan, sehingga pengembang mengambil inisiatif untuk menulis perangkat lunak dengan fungsionalitas yang sama, membukanya untuk diperbaiki oleh pengembang lain.

Open source komersial memanfaatkan keuntungan-keuntungan ini, kenyataannya adalah bahwa banyak produk modern menggunakan open source di balik layar, bahkan ketika varian komersial dari perangkat lunak tersebut biasanya menyediakan komponen tambahan yang tidak tersedia sebagai bagian dari rilis open source tertentu, menyediakan diferensiasi serta dukungan jika diperlukan.

Pengalaman pertama saya dengan open source terjadi saat membangun produk perawatan kesehatan yang saya sebutkan sebelumnya, menggunakan tooling seperti Apache Ant, yang digunakan untuk membangun perangkat lunak, dan produk DevOps awal yang disebut Hudson (basis kode yang kemudian menjadi Jenkins). Alasan utama di balik keputusan kami untuk menggunakan produk open source ini adalah bahwa mereka menyediakan solusi yang lebih baik daripada alternatif komersial, atau merupakan solusi inovatif yang tidak ditawarkan oleh entitas komersial, serta lisensi komersial dari beberapa produk yang kami gunakan sangat terbatas, menyebabkan birokrasi yang berlebihan ketika datang untuk membutuhkan lebih banyak lisensi, karena biaya yang terlibat.

Seiring waktu, saya telah melihat penawaran open source terus berkembang, menyediakan inovasi yang sangat dibutuhkan. Misalnya, banyak masalah yang saya dan rekan saya hadapi saat membangun produk perawatan kesehatan ini kemudian diselesaikan oleh produk Java open source inovatif yang kami mulai gunakan yang disebut Spring Framework, yang masih kuat setelah lebih dari satu dekade, ekosistemnya sekarang meluas jauh melampaui beberapa inovasi yang awalnya disediakan, sekarang dianggap umum, seperti injeksi ketergantungan.

Anda telah menggunakan open source untuk membangun PoC, prototipe, dan MVP. Bisa Anda berbagi pengalaman Anda di balik beberapa produk ini?

Seperti yang saya jelaskan dalam salah satu prinsip yang saya sampaikan kepada klien baru-baru ini, pembangunan untuk platform data yang kami bangun untuk mereka harus terus dilakukan secara iteratif seiring waktu. Komponen yang dibangun untuk platform ini tidak boleh diharapkan untuk tetap statis, karena kebutuhan berubah dan komponen baru serta fitur komponen akan tersedia seiring waktu.

Saat membangun fungsi platform, selalu mulai dengan apa yang paling layak sebelum menambahkan lonceng dan peluit yang tidak perlu, yang dalam beberapa kasus bahkan termasuk konfigurasi. Mulai dengan apa yang fungsional, pastikan Anda memahaminya, dan kemudian kembangkannya. Jangan buang waktu dan uang untuk membangun apa yang memiliki kemungkinan rendah untuk digunakan, tetapi upayakan untuk mendahului kebutuhan masa depan.

MVP yang kami bangun untuk produk ini secara eksplisit perlu dibangun sehingga kasus penggunaan tambahan dapat terus dibangun di atasnya, bahkan jika itu datang dengan implementasi dari satu kasus penggunaan, untuk deteksi anomali biaya. Tidak seperti klien ini, produk yang saya bangun sebelumnya memiliki sejarah sebelum kedatangan saya. Dalam kasus ini, pemangku kepentingan telah debat selama tiga tahun (!) tentang bagaimana mereka harus mendekati produk yang mereka cari untuk dibangun. Seorang eksekutif klien menjelaskan bahwa salah satu alasan dia membawa saya adalah untuk membantu perusahaan melewati beberapa debat internal ini, terutama karena produk yang dia cari untuk dibangun perlu memuaskan hierarki organisasi yang terlibat.

Saya menemukan bahwa perang ini sebagian besar terkait dengan data yang dimiliki oleh klien, anak perusahaan, dan pelanggan eksternal, sehingga dalam kasus ini seluruh backlog produk berputar di sekitar bagaimana data ini akan diambil, disimpan, diamankan, dan dikonsumsi untuk satu kasus penggunaan yang menghasilkan jaringan penyedia kesehatan untuk analisis biaya.

Lebih awal dalam karir saya, saya datang untuk memahami bahwa kualitas arsitektur yang disebut “kegunaan” tidak terbatas pada pengguna akhir saja, tetapi juga pengembang perangkat lunak itu sendiri. Alasannya adalah kode yang ditulis perlu dapat digunakan seperti antarmuka pengguna yang perlu dapat digunakan oleh pengguna akhir. Agar produk menjadi dapat digunakan, bukti konsep perlu dibangun untuk menunjukkan bahwa pengembang akan dapat melakukan apa yang mereka tetapkan untuk dilakukan, terutama ketika terkait dengan pilihan teknologi yang mereka buat. Tetapi bukti konsep hanya awal, karena produk terbaik ketika berkembang seiring waktu. Menurut saya, dasar untuk MVP seharusnya dibangun pada prototipe yang menunjukkan beberapa kestabilan sehingga pengembang dapat terus mengembangkannya.

Saat mengulas buku ‘Machine Learning at Enterprise Scale’ Anda menyatakan bahwa ‘penggunaan produk, kerangka kerja, dan bahasa open source bersama dengan arsitektur yang gesit yang terdiri dari campuran komponen open source dan komersial menyediakan kelenturan yang banyak perusahaan butuhkan tetapi tidak segera menyadari dari awal’. Bisa Anda menjelaskan secara rinci mengapa Anda percaya bahwa perusahaan yang menggunakan open source lebih gesit?

Banyak produk data komersial menggunakan komponen open source utama di balik layar, dan memungkinkan pengembang untuk menggunakan bahasa pemrograman populer seperti Python. Perusahaan yang membangun produk ini tahu bahwa komponen open source yang mereka pilih untuk mengintegrasikan memberikan mereka keunggulan awal karena komponen-komponen ini sudah banyak digunakan oleh komunitas.

Komponen open source dengan komunitas yang kuat lebih mudah dijual, karena kesadaran yang mereka bawa ke meja. Produk komersial yang sebagian besar terdiri dari sumber tertutup, atau bahkan open source yang sebagian besar hanya digunakan oleh produk komersial tertentu, sering memerlukan pelatihan oleh vendor, atau lisensi untuk menggunakan perangkat lunak.

Tambahnya, dokumentasi untuk komponen tersebut sebagian besar tidak tersedia secara publik, memaksa ketergantungan pengembang pada perusahaan tersebut untuk melakukan pekerjaan mereka. Ketika komponen open source yang diterima secara luas seperti Apache Spark menjadi fokus utama, seperti dengan produk seperti Databricks Unified Analytics Platform, banyak item ini sudah tersedia di komunitas, meminimalkan bagian yang pengembang perlu bergantung pada entitas komersial untuk melakukan pekerjaan mereka.

Tambahnya, karena komponen seperti Apache Spark diterima secara luas sebagai alat standar industri, kode juga dapat dengan mudah bermigrasi di seluruh implementasi komersial dari produk tersebut. Perusahaan akan selalu cenderung mengintegrasikan apa yang mereka anggap sebagai diferensiasi kompetitif, tetapi banyak pengembang tidak ingin menggunakan produk yang sepenuhnya baru karena ini membuktikan menantang untuk berpindah antara perusahaan, dan cenderung memutuskan hubungan mereka dengan komunitas yang mereka harapkan.

Dari pengalaman pribadi, saya telah bekerja dengan produk tersebut di masa lalu, dan bisa jadi menantang untuk mendapatkan dukungan yang kompeten. Dan ini ironis, mengingat bahwa perusahaan tersebut menjual produk mereka dengan harapan bahwa dukungan akan disediakan dalam waktu yang tepat. Saya telah mengalami mengirimkan permintaan tarik ke proyek open source, dengan perbaikan yang dimasukkan ke dalam build pada hari yang sama, tetapi tidak bisa mengatakan hal yang sama tentang proyek komersial yang pernah saya kerjakan.

Sesuatu yang lain yang Anda percayai tentang open source adalah bahwa itu menyediakan ‘akses ke komunitas pengembang yang kuat.’ Seberapa besar beberapa komunitas ini dan apa yang membuat mereka efektif?

Komunitas pengembang di sekitar produk open source tertentu dapat mencapai ratusan ribu. Tingkat adopsi tidak selalu menunjukkan kekuatan komunitas, tetapi merupakan indikator yang baik bahwa ini adalah kasusnya karena cenderung menghasilkan siklus virtuos. Saya menganggap komunitas kuat ketika mereka menghasilkan diskusi yang sehat dan dokumentasi yang efektif, dan di mana pengembangan aktif terjadi.

Ketika seorang arsitek atau pengembang senior bekerja melalui proses untuk memilih produk mana yang akan dimasukkan ke dalam apa yang mereka bangun, banyak faktor biasanya berperan, tidak hanya tentang produk itu sendiri dan bagaimana komunitasnya, tetapi tentang tim pengembangan yang akan mengadopsi produk ini, apakah mereka cocok untuk ekosistem yang dikembangkan, apa yang terlihat seperti roadmap, dan dalam beberapa kasus apakah dukungan komersial dapat ditemukan jika diperlukan. Namun, banyak aspek ini menjadi tidak relevan dalam ketiadaan komunitas pengembang yang kuat.

Anda telah meninjau ratusan buku di situs web Anda, apakah ada tiga buku yang dapat Anda rekomendasikan kepada pembaca kami?

Ini hari-hari saya membaca sangat sedikit buku pemrograman, dan sementara ada pengecualian, kenyataannya adalah bahwa buku-buku ini biasanya sudah ketinggalan zaman sangat cepat, dan komunitas pengembang biasanya menyediakan alternatif yang lebih baik melalui forum diskusi dan dokumentasi. Banyak buku yang saya baca sekarang tersedia secara gratis untuk saya, baik melalui buletin teknologi yang saya langgani, penulis dan publicis yang menghubungi saya, atau yang dikirim oleh Amazon.

(1) Salah satu buku dari O’Reilly yang saya rekomendasikan adalah “In Search of Database Nirvana”. Penulis membahas secara rinci tantangan yang dihadapi oleh mesin kueri database untuk mendukung beban kerja yang meliputi spektrum OLTP di satu ujung, hingga analitik di ujung lain, dengan beban kerja operasional dan intelijen bisnis di tengah. Buku ini dapat digunakan sebagai panduan untuk menilai mesin database atau kombinasi mesin kueri dan penyimpanan, yang ditujukan untuk memenuhi kebutuhan beban kerja, apakah itu transaksional, analitik, atau campuran keduanya. Selain itu, cakupan penulis tentang “pendulum database yang bergoyang” dalam beberapa tahun terakhir sangat baik.

(2) Sementara banyak hal telah berubah di ruang data selama beberapa tahun terakhir, karena produk analitik data baru terus diperkenalkan, “Disruptive Analytics” menyajikan sejarah singkat dan dapat diakses dari 50 tahun terakhir inovasi dalam analitik yang belum pernah saya lihat di tempat lain, dan membahas dua jenis gangguan: inovasi gangguan dalam rantai nilai analitik, dan gangguan industri oleh inovasi dalam analitik. Dari perspektif startup dan praktisi analitik, kesuksesan dimungkinkan dengan mengganggu industri mereka, karena menggunakan analitik untuk membedakan produk adalah cara untuk membuat model bisnis yang mengganggu atau menciptakan pasar baru. Dari perspektif berinvestasi dalam teknologi analitik untuk organisasi mereka, mendekati dengan cara menunggu dan melihat mungkin masuk akal karena teknologi yang berisiko gangguan adalah investasi yang berisiko karena umur yang singkat.

(3) Salah satu teks bisnis teknologi terbaik yang saya baca adalah “The Limits of Strategy”, oleh salah satu pendiri Research Board (yang diakuisisi oleh Gartner), sebuah think tank internasional yang menyelidiki perkembangan di dunia komputasi dan bagaimana perusahaan harus beradaptasi. Penulis menyajikan catatan yang sangat rinci dari banyak percakapannya dengan pemimpin bisnis, memberikan analisis yang mendalam sepanjang tentang pengalaman mereka membangun (bersama istrinya) sekelompok klien, perusahaan besar yang memerlukan strategi mereka untuk disesuaikan dengan dunia komputasi yang meledak. Seperti yang saya komentari dalam tinjauan saya, apa yang membedakan buku ini dari upaya terkait lainnya adalah dua karakteristik yang tampaknya bertentangan: cakupan industri yang luas, dan kedekatan yang hanya tersedia melalui interaksi tatap muka.

Anda adalah Arsitek Utama untuk praktik data SPR. Bisa Anda menjelaskan apa yang SPR lakukan?

SPR adalah konsultan teknologi digital yang berbasis di daerah Chicago, yang mengirimkan proyek teknologi untuk berbagai klien, dari perusahaan Fortune 1000 hingga startup lokal. Kami membangun pengalaman digital ujung-ke-ujung menggunakan berbagai kemampuan teknologi, mulai dari pengembangan perangkat lunak kustom, pengalaman pengguna, data, dan infrastruktur cloud, hingga coaching DevOps, pengujian perangkat lunak, dan manajemen proyek.

Apa beberapa tanggung jawab Anda dengan SPR?

Sebagai arsitek utama, tanggung jawab utama saya adalah untuk mengarahkan pengiriman solusi untuk klien, memimpin arsitektur dan pengembangan untuk proyek, dan ini sering berarti mengenakan topi lain seperti pemilik produk karena kemampuan untuk berhubungan dengan bagaimana produk dibangun dari perspektif tangan adalah sangat penting dalam hal bagaimana pekerjaan harus diprioritaskan, terutama ketika membangun dari awal. Saya juga ditarik ke dalam diskusi dengan klien potensial ketika keahlian saya diperlukan, dan perusahaan baru-baru ini meminta saya untuk memulai serangkaian sesi yang berkelanjutan dengan rekan arsitek di praktik data untuk membahas proyek klien, proyek sampingan, dan apa yang rekan saya lakukan untuk tetap mengikuti teknologi, serupa dengan apa yang saya jalankan untuk konsultasi sebelumnya, meskipun pertemuan internal ini lebih spesifik untuk praktik data.

Untuk sebagian besar karir saya, saya telah berspesialisasi dalam pengembangan open source menggunakan Java, melakukan sejumlah besar pekerjaan data sepanjang jalan. Selain dua spesialisasi ini, saya juga melakukan apa yang rekan saya dan saya sebut “praktis” atau “pragmatis” arsitektur perusahaan, yang berarti melakukan tugas arsitektur dalam konteks apa yang akan dibangun, dan sebenarnya membangunnya, bukan hanya berbicara tentang itu atau menggambar diagram tentang itu, menyadari tentu saja bahwa tugas-tugas lain ini juga penting.

Menurut saya, tiga spesialisasi ini tumpang tindih satu sama lain dan tidak saling eksklusif. Saya telah menjelaskan kepada eksekutif selama beberapa tahun terakhir bahwa garis yang telah digambar oleh industri teknologi antara pengembangan perangkat lunak dan pekerjaan data tidak lagi didefinisikan dengan baik, sebagian karena alat antara kedua ruang ini telah konvergen, dan sebagian karena, sebagai hasil dari konvergensi ini, pekerjaan data itu sendiri telah menjadi upaya pengembangan perangkat lunak yang besar. Namun, karena praktisi data tradisional biasanya tidak memiliki latar belakang pengembangan perangkat lunak, dan sebaliknya, saya membantu memenuhi kesenjangan ini.

Apa proyek menarik yang saat ini Anda kerjakan dengan SPR?

Baru-baru ini, saya menerbitkan posting pertama dalam seri studi kasus multi-bagian tentang platform data yang saya dan tim saya implementasikan di AWS dari awal tahun lalu untuk CIO dari sebuah konsultasi global yang berbasis di Chicago. Platform ini terdiri dari pipa data, danau data, model data kanonik, visualisasi, dan model pembelajaran mesin, untuk digunakan oleh departemen perusahaan, praktik, dan pelanggan akhir klien. Sementara inti platform akan dibangun oleh organisasi IT perusahaan yang dijalankan oleh CIO, tujuannya adalah bahwa platform ini akan digunakan oleh organisasi lain di luar IT perusahaan untuk mengonsolidasikan aset data dan analisis data di seluruh perusahaan menggunakan arsitektur yang sama, membangun di atasnya untuk memenuhi kebutuhan kasus penggunaan masing-masing organisasi.

Sebagaimana dengan banyak perusahaan yang mapan, penggunaan Microsoft Excel sangat umum, dengan spreadsheet yang biasanya didistribusikan di dalam dan di seluruh organisasi, serta antara perusahaan dan klien eksternal. Selain itu, unit bisnis dan praktik konsultasi telah menjadi terisolasi, masing-masing menggunakan proses dan tooling yang berbeda. Jadi selain mengonsolidasikan aset data dan analisis data, tujuan lainnya adalah untuk mengimplementasikan konsep kepemilikan data, dan memungkinkan berbagi data di seluruh organisasi dengan cara yang aman dan konsisten.

Apakah ada yang lain yang ingin Anda bagikan tentang open source, SPR, atau proyek lain yang Anda kerjakan?

Proyek lain (baca tentangnya di sini dan di sini) yang saya baru-baru ini pimpin melibatkan implementasi yang sukses dari Databricks Unified Analytics Platform, dan migrasi eksekusi model pembelajaran mesin ke platform ini dari Azure HDInsight, distribusi Hadoop, untuk direktur rekayasa data dari sebuah perusahaan asuransi besar.

Semua model yang bermigrasi ini dimaksudkan untuk memprediksi tingkat adopsi konsumen yang diharapkan untuk berbagai produk asuransi, dengan beberapa di antaranya telah bermigrasi dari SAS beberapa tahun sebelumnya ketika perusahaan tersebut beralih ke menggunakan HDInsight. Tantangan terbesar adalah kualitas data yang buruk, tetapi tantangan lainnya termasuk kurangnya versi yang komprehensif, pengetahuan suku dan dokumentasi yang tidak lengkap, dan dokumentasi Databricks yang belum matang dan dukungan yang terkait dengan penggunaan R pada saat itu (implementasi Azure dari Databricks baru saja tersedia secara umum beberapa bulan sebelum proyek ini).

Untuk mengatasi tantangan-tantangan kunci ini, sebagai tindak lanjut dari pekerjaan implementasi kami, saya membuat rekomendasi sekitar otomatisasi, konfigurasi dan versi, pemisahan kepedulian data, dokumentasi, dan perluasan yang diperlukan di seluruh tim data, platform, dan pemodelan. Pekerjaan kami meyakinkan seorang Ilmuwan Data Utama yang awalnya sangat skeptis bahwa Databricks adalah jalan yang benar, dengan tujuan mereka setelah kepergian kami untuk bermigrasi model yang tersisa ke Databricks secepat mungkin.

Ini telah menjadi wawancara yang menarik yang menyentuh banyak subjek, saya merasa seperti saya telah belajar banyak tentang open source. Pembaca yang mungkin ingin belajar lebih banyak dapat mengunjungi situs web perusahaan SPR atau situs web Erik Gfesser.