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

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

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

Apa yang awalnya menarik Anda untuk mempelajari machine learning?

Kemampuan aplikasi untuk terus belajar. Saya memulai karir pengembangan saya sebagai analis data senior menggunakan SPSS di sebuah perusahaan riset pasar global, dan kemudian menggabungkan 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 menunjukkan secara rinci bagaimana mereka dapat memperbaiki, melalui statistik dan metode lain, proses bisnis yang digunakan oleh klien mereka, tetapi di sini juga outputnya sebagian besar berfokus pada titik waktu. Pengalaman saya bekerja untuk memperbaiki produk perawatan kesehatan yang dibangun oleh rekan saya dan saya selama periode waktu yang sama menunjukkan kepada saya mengapa pembelajaran terus-menerus diperlukan untuk upaya tersebut, tetapi sumber daya yang sekarang tersedia tidak ada pada saat itu.

Menariknya, ketertarikan saya pada machine learning telah menjadi lingkaran penuh, karena pembimbing akademis 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 hipe ML di luar sana tidak realistis, ini menyediakan kemampuan yang kuat dari perspektif pengembang, selama praktisi ini mengakui bahwa nilai yang disediakan oleh ML hanya sebaik data yang diproses olehnya.

Anda adalah advokat open source yang besar, bisakah Anda membahas mengapa open source sangat penting?

Satu aspek tentang open source yang saya butuhkan untuk menjelaskan kepada eksekutif selama bertahun-tahun adalah bahwa manfaat utama dari open source bukanlah bahwa penggunaan perangkat lunak ini tersedia tanpa biaya moneter, tetapi bahwa kode sumbernya tersedia secara gratis.

Selain itu, pengembang yang menggunakan kode sumber ini dapat memodifikasinya untuk keperluan mereka sendiri, dan jika perubahan yang disarankan disetujui, membuat perubahan ini tersedia untuk pengembang lain yang menggunakannya. Pada kenyataannya, 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 yang dikomersialkan memanfaatkan keuntungan ini, kenyataannya adalah bahwa banyak produk modern menggunakan open source di bawah tudung, bahkan ketika varian komersial dari perangkat lunak ini biasanya menyediakan komponen tambahan yang tidak tersedia sebagai bagian dari rilis open source, menyediakan perbedaan 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 pada saat itu yang disebut Hudson (basis kode yang kemudian menjadi Jenkins). Alasan utama di balik keputusan kami untuk menggunakan produk open source ini adalah bahwa produk ini menyediakan solusi yang lebih baik daripada alternatif komersial, atau merupakan solusi inovatif yang tidak ditawarkan oleh entitas komersial, tidak menyebutkan bahwa lisensi komersial dari beberapa produk yang kami gunakan sangat terbatas, menyebabkan birokrasi yang berlebihan ketika datang untuk memerlukan 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 open source Java 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 disediakannya, sekarang dianggap umum, seperti injeksi ketergantungan.

Anda telah menggunakan open source untuk membangun PoC, prototipe, dan MVP. Bisakah Anda berbagi pengalaman Anda tentang 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 tetap statis, karena kebutuhan berubah dan komponen serta fitur komponen baru akan tersedia seiring waktu.

Saat membangun fungsionalitas platform, selalu mulai dengan apa yang paling viabel 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 membangun apa yang memiliki kemungkinan rendah untuk digunakan, tetapi berusaha untuk mendahului kebutuhan di masa depan.

MVP yang kami bangun untuk produk ini secara eksplisit perlu dibangun sehingga kasus penggunaan tambahan dapat terus dibangun di atasnya, bahkan jika datang dengan implementasi dari satu kasus penggunaan, untuk deteksi anomali biaya. Tidak seperti klien ini, produk sebelumnya yang saya bangun memiliki sejarah di baliknya 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 masuk 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 layanan 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 bahwa kode yang ditulis perlu dapat digunakan sama seperti antarmuka pengguna 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 tertentu yang mereka buat. Tetapi bukti konsep hanya awal, karena produk terbaik ketika berkembang seiring waktu. Menurut saya, dasar untuk MVP, bagaimanapun, sebaiknya dibangun pada prototipe yang menunjukkan beberapa stabilitas sehingga pengembang akan dapat terus mengembangkannya.

Ketika Anda meninjau 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 pada awalnya’. Bisakah Anda menjelaskan lebih lanjut mengapa Anda percaya bahwa perusahaan yang menggunakan open source lebih gesit?

Banyak produk data komersial menggunakan komponen open source utama di bawah tudung, dan memungkinkan pengembang untuk menggunakan bahasa pemrograman populer seperti Python. Perusahaan yang membangun produk ini tahu bahwa komponen open source yang mereka pilih untuk menggabungkan memberikan mereka awal yang lebih cepat ketika komponen ini sudah banyak digunakan oleh komunitas.

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

Selain itu, dokumentasi untuk komponen tersebut sebagian besar tidak tersedia secara publik, memaksa ketergantungan pengembang terus-menerus pada perusahaan ini. 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 dalam komunitas, meminimalkan bagian yang perlu pengembang ketergantung pada entitas komersial untuk melakukan pekerjaan mereka.

Selain itu, karena komponen seperti Apache Spark diterima secara luas sebagai alat standar industri, kode juga dapat dengan mudah bermigrasi di seluruh implementasi komersial produk ini. Perusahaan akan selalu cenderung menggabungkan apa yang mereka anggap sebagai perbedaan kompetitif, tetapi banyak pengembang tidak ingin menggunakan produk yang benar-benar baru karena ini membuktikan menantang untuk berpindah antara perusahaan, dan cenderung memutuskan hubungan mereka dengan komunitas yang kuat 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 pelanggan bahwa dukungan akan disediakan dalam waktu yang tepat. Saya telah memiliki pengalaman 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 apa pun yang 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 sangat 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 kecenderungan mereka untuk menghasilkan siklus virtuos. Saya menganggap komunitas kuat ketika mereka menghasilkan diskusi yang sehat dan dokumentasi yang efektif, dan di mana pengembangan aktif sedang berlangsung.

Ketika seorang arsitek atau pengembang senior bekerja melalui proses untuk memilih produk open source mana yang akan digabungkan ke dalam apa yang mereka bangun, banyak faktor biasanya berperan, tidak hanya tentang produk itu sendiri dan apa yang komunitasnya, tetapi tentang tim pengembang yang akan mengadopsi produk ini, apakah mereka cocok untuk ekosistem yang dikembangkan, apa yang terlihat seperti peta jalan, dan dalam beberapa kasus apakah dukungan komersial dapat ditemukan jika diperlukan.

Namun, banyak aspek ini menjadi tidak penting 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?

Saat ini saya membaca sangat sedikit buku pemrograman, dan meskipun 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 saat ini disediakan 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 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 dari keduanya. Selain itu, cakupan penulis tentang “bandul database” dalam beberapa tahun terakhir sangat baik.

(2) Meskipun 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 saya belum pernah 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, mengambil pendekatan tunggu dan lihat 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 pengembangan di dunia komputasi dan bagaimana perusahaan harus beradaptasi. Penulis menyajikan catatan yang sangat rinci dari banyak percakapan dengan pemimpin bisnis, menyediakan analisis yang tajam di seluruh tentang pengalaman mereka membangun (bersama istrinya) sekelompok klien, perusahaan besar yang memerlukan menyelaraskan strategi mereka 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: keluasan industri, dan kedekatan yang hanya tersedia melalui interaksi tatap muka.

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

SPR adalah konsultan teknologi digital yang berbasis di daerah Chicago, 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 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 arsitek lain di praktik data untuk mendiskusikan proyek klien, proyek sampingan, dan apa yang rekan saya lakukan untuk tetap mengikuti teknologi, serupa dengan apa yang saya miliki untuk konsultan sebelumnya, meskipun pertemuan internal untuk firma lain ini melibatkan praktik teknologi mereka secara keseluruhan, bukan khusus untuk pekerjaan data.

Untuk sebagian besar karir saya, saya telah berspesialisasi dalam pengembangan open source menggunakan Java, melakukan jumlah pekerjaan data yang semakin banyak seiring waktu. 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 benar-benar membangunnya, bukan hanya berbicara tentang hal itu atau menggambar diagram tentang hal 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 secara tradisional ditarik oleh industri teknologi antara pengembangan perangkat lunak dan pekerjaan data tidak lagi didefinisikan dengan baik, sebagian karena alat antara dua 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 sebutkan sebelumnya yang tim saya dan saya implementasikan di AWS dari awal tahun ini untuk CIO dari konsultan 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 ini akan dibangun oleh organisasi IT korporat yang dijalankan oleh CIO, tujuannya adalah bahwa platform ini akan digunakan oleh organisasi lain di luar IT korporat juga untuk mengonsolidasikan aset data dan analisis data di seluruh perusahaan menggunakan arsitektur yang sama, membangun di atasnya untuk memenuhi kebutuhan kasus penggunaan dari masing-masing organisasi.

Seperti banyak perusahaan yang mapan, penggunaan Microsoft Excel sangat umum, dengan spreadsheet yang umum 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 alat 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 Anda ingin bagikan tentang open source, SPR atau proyek lain yang Anda kerjakan?

Proyek lain (baca tentangnya di sini dan di sini) yang saya pimpin baru-baru ini melibatkan implementasi Databricks Unified Analytics Platform yang sukses, 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 dapat diharapkan untuk berbagai produk asuransi, dengan beberapa 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 tidak adanya versi komprehensif, pengetahuan suku dan dokumentasi yang tidak lengkap, dan dokumentasi dan dukungan Databricks yang belum matang sehubungan dengan penggunaan R pada saat itu (implementasi Azure dari Databricks baru saja dirilis secara umum beberapa bulan sebelum proyek ini).

Untuk mengatasi tantangan utama 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 mereka. Pekerjaan kami meyakinkan Ilmuwan Data Utama yang awalnya sangat skeptis bahwa Databricks adalah jalan yang benar, dengan tujuan mereka setelah keberangkatan kami untuk bermigrasi model yang tersisa ke Databricks secepat mungkin.

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