Sistem Data Cenderung Menuju Produksi

Sepuluh tahun terakhir telah melihat omset hampir lengkap dalam alat yang tersedia untuk seorang profesional data. Melihat Tumpukan Data Modern saat ini, sebagian besar alat (dbt, Looker, Snowflake, Fivetran, Hightouch, Census) tidak tersedia secara komersial pada tahun 2012. Seluruh kategori (ELT, Reverse ETL, cloud warehouses) dan kerangka kerja (aktivasi data, jaring data , struktur data, kontrak data) telah dibuat. (Atau dalam beberapa kasus, praktik SWE yang berusia puluhan tahun telah ditemukan kembali oleh tim data.) Mengikuti Twitter + Substack, proyek sumber terbuka, karier, dan perusahaan telah naik dan turun. Peluang berlimpah.

Kemungkinan dan luas permukaan bagi seorang profesional data untuk memengaruhi arah perusahaan secara substansial lebih besar daripada satu dekade lalu. Sayangnya, area permukaan dari apa yang salah telah tumbuh dengan cepat. Tantangan berkisar dari SLA teknis tingkat rendah hingga sistem, budaya, standar, dan desain organisasi tingkat tinggi. Alat-alat baru ini sangat kuat. Perusahaan dapat membangun dan menghancurkan sistem data dengan kecepatan yang lebih tinggi daripada sebelumnya.

Saya telah mengamati tiga tren untuk sistem data selama lima tahun terakhir, mulai dari vertikal teknis dalam tim data, serta lintas vertikal bisnis yang didukung oleh data. Saya akan mencoba menjelaskan tren ini melalui contoh yang digeneralisasikan ke banyak perusahaan, dan mudah-mudahan menjelaskan peluang, masalah, dan solusi dengan cara yang digeneralisasikan ke tim Anda. Tren, peluang, masalah, dan solusi:

Sistem Cenderung Menuju Produksi

• Rangkuman : pekerjaan dan output data yang berharga akhirnya dikonsumsi dalam kasus penggunaan yang semakin penting / tingkat produksi.
• Peluang : output dari tim data dapat tersebar di area permukaan yang jauh lebih besar dan lebih berdampak.
• Masalah : karena output data dikonsumsi oleh kasus penggunaan yang lebih penting, tidak ada "pengerasan" alur kerja yang sesuai, yang awalnya diatur dengan cara yang sangat ringan.
• Solusi : Buat jalur untuk aliran ringan untuk dipromosikan ke "produksi", rayakan waktu yang dihabiskan untuk pengerasan sistem saat bergerak menuju tingkat produksi.

• Rangkuman : output data yang awalnya ditujukan untuk tujuan tertentu semakin banyak dan tanpa disadari menemukan adopsi di banyak tim dan kasus penggunaan.
• Peluang: wawasan yang dirancang untuk kasus penggunaan tertentu dapat mendorong pengambilan keputusan/hasil yang lebih baik di lebih banyak tim.
• Masalah : tidak ada dua tim yang memiliki spesifikasi yang persis sama, peningkatan untuk satu kasus penggunaan tidak digunakan di tempat lain.
• Solusi : buat komitmen konsumen/produsen + visibilitas ke dalam ketergantungan, pusatkan logika bisnis.

• Ringkasan : Data dapat diubah dalam banyak langkah sepanjang perjalanannya, logika bisnis hidup dalam berbagai alat.
• Peluang : Alat data modern memungkinkan pemangku kepentingan untuk mengakses data dan melakukan transformasi mil terakhir untuk bergerak lebih cepat dan membuka diri.
• Masalah : Logika bisnis di seluruh tumpukan membuat reproduktifitas menjadi tidak mungkin, transformasi mil terakhir tidak menguntungkan konsumen data lainnya.
• Solusi : Kurangi area di mana logika bisnis dapat disuntikkan, buat kebijakan "waktu untuk hidup" pada transformasi last mile, bangun budaya standarisasi + merayakan akses ke basis kode lintas fungsi.

Musim panas 2019 . Munculnya seltzer berduri tidak dapat dihentikan, tetapi masih ada beberapa ibu dan pemilik toko minuman keras pop yang tidak sadar. Anda seorang insinyur analitik di pasar alkohol B2C. Manajer akun Anda (ahli dalam konsumsi alkohol) TAHU Cakar akan terbang dari rak, jika saja Anda bisa mendapatkannya di toko. Ini adalah win/win/win peningkatan pareto pasar yang sulit dipahami, di mana inventaris yang lebih baik menguntungkan pelanggan, pengecer, dan perusahaan. Anda telah ditugaskan untuk mencari tahu barang terlaris yang tidak dimiliki oleh toko minuman keras di jaringan Anda.

1. Penggunaan internal (BI tool / Looker)

Kueri awal mudah ditulis. Ada tabel toko (dengan market_id, SKU terlaris menurut pasar, dan umpan inventaris harian untuk setiap toko). Setiap toko memiliki umpan inventaris harian. Sesuatu seperti ini mendapatkan item terlaris yang tidak dimiliki setiap toko:

select
  s.store_id,
  skus.sku_id,
  skus.market_rank
from dim_stores as s
left join tbl_top_selling_market_skus as skus
  on s.market_id = skus.market_id
left outer join dim_store_inventory as inv
  on s.store_id = inv.store_id
  and inv.sku_id = skus.sku_id
  and inv.remaining_qty > 0
where inv.sku_id is null
order by store_id, skus.market_rank desc
;

…pengelola akun awal memberikan umpan balik di dasbor selama proses berlangsung.

Catatan: Alat BI adalah infrastruktur tim data. Tidak ada wawasan/kasus penggunaan/produk yang meninggalkan domain tim data. Kesalahan memiliki konsekuensi rendah, umpan balik kemungkinan + langsung.

2. Penggunaan internal (Internal Tools / Salesforce)

Namun, tim penjualan / kesuksesan pelanggan / manajemen akun tidak menghabiskan sepanjang hari di Looker — mereka menghabiskan sepanjang hari di Salesforce. Memiliki dua browser yang terbuka adalah rasa sakit. Ini adalah kasus penggunaan ETL terbalik buku teks. Letakkan data di tempat yang akan digunakan . Ini sulit bertahun-tahun yang lalu, sekarang sepele — tandatangani penyedia ETL terbalik, pindahkan titik data Anda dari A ke B dalam waktu kurang dari sehari.

Item terlaris yang tidak dibawa toko sekarang ada di Salesforce. Tim data telah menambahkan konteks untuk tim lain dengan cara yang mudah. Inilah yang dimaksud dengan aktivasi data — memberdayakan tim lain untuk melakukan pekerjaan mereka dengan lebih baik menggunakan alat yang mereka kenal. Lebih banyak manajer akun melihat lebih banyak item inventaris yang hilang, menelepon lebih banyak toko, lebih banyak SKU teratas masuk ke toko minuman keras, lebih banyak penjualan terjadi. Semua orang menang.

…satu manajer akun memperhatikan bahwa toko bir dan anggur memiliki barang-barang minuman keras di daftar barang terlaris mereka. AM menggunakan konteks bisnis mereka, dan melewatkan merekomendasikan barang yang mereka tahu tidak dapat dibawa oleh toko secara legal. Logika bisnis tambahan telah ditambahkan melalui lapisan keputusan manusia.

Catatan: Salesforce BUKAN infrastruktur tim data. Wawasan dan kasus penggunaan telah meninggalkan domain tim data, tetapi bukan perusahaan. Tidak ada yang dihadapi pelanggan. Kesalahan memiliki konsekuensi rendah, tetapi umpan balik tidak dijamin. Logika tambahan telah ditambahkan (melalui penilaian manusia).

3. Penggunaan eksternal (Otomasi Pemasaran)

Implementasi Salesforce sangat membantu, tetapi masih bersifat manual. Manajer akun dan pemilik toko minuman keras menghabiskan terlalu banyak waktu di telepon. Sebagian besar toko minuman keras melakukan pemesanan inventaris seminggu sekali. AM meminta bantuan dari data dan operasi pemasaran untuk merampingkan komunikasi melalui email otomatis dalam irama mingguan.

Beberapa kolom lagi diperlukan, kemudian tabel mentah dibalik ETL menjadi Hubspot / Iterable / Braze. Rekanan CRM memberikan sentuhan akhir pada kampanye email, dan kampanye email berjudul, "Item Teratas yang Tidak Anda Bawa" ditayangkan.

… rekan CRM yang bertanggung jawab atas pemberitahuan email bahwa beberapa item terlaris (berdasarkan hitungan) adalah sedikit alkohol. Ini tidak sesuai dengan visi merek perusahaan/kasus penggunaan yang diinginkan pelanggan. Sebagian besar sistem email memungkinkan lapisan logika tambahan — rekanan CRM menggunakan penilaian mereka untuk memfilter item apa pun dengan volume 50ml atau kurang.

Catatan: Wawasan dan kasus penggunaan telah meninggalkan domain tim data, dan perusahaan. Keluaran tim data sekarang menghadap pelanggan. Kesalahan memiliki konsekuensi yang lebih tinggi, umpan balik cenderung tidak disampaikan dengan benar kepada pemangku kepentingan yang tepat. Logika bisnis tambahan telah ditambahkan (melalui transformasi last-mile di lapisan CRM).

4. Penggunaan luar (Aplikasi Produksi)

Tim data mendengar dari tim AM dan CRM — beberapa toko minuman keras cukup kuno, dan mereka tidak memeriksa email. Toko minuman keras lainnya adalah sekolah baru, dan mereka tidak ingin menunggu seminggu penuh untuk mendapatkan email tentang apa yang sedang tren di pasar mereka. Grup memutuskan untuk mengulang tim aplikasi ritel untuk memasukkan "Barang Teratas yang Tidak Anda Bawa" ke dalam aplikasi produksi yang dijalankan oleh semua pengecer. Tim data memindahkan output mereka ke dalam bucket AWS S3, yang diambil oleh teknisi produksi. Karyawan toko minuman keras sekarang dapat melihat daftar ini setiap hari, tanpa memerlukan pengelola akun atau gesekan email. White Claw dan Whispering Angel masuk ke setiap toko di Amerika.

… satu pengecer mengajukan keluhan kepada Pengecer CX - mereka dengan sengaja berhenti menyimpan Smirnoff Peppermint Vodka setelah liburan. Ini mungkin benar-benar item terlaris L90, tetapi ini sangat musiman, dan mereka tidak ingin melihatnya di daftar yang direkomendasikan. Umpan balik ini sampai ke tim teknik prod, tim itu membuat penyesuaian logika di lapisan aplikasi untuk mengidentifikasi dan menghapus item musiman yang lalu.

Catatan: Wawasan dan kasus penggunaan telah meninggalkan domain tim data, dan perusahaan. Keluaran tim data berhadapan langsung dengan pelanggan. Kesalahan memiliki konsekuensi yang lebih tinggi, umpan balik cenderung tidak disampaikan kepada pemangku kepentingan yang tepat. Logika tambahan telah ditambahkan (melalui logika bisnis di lapisan aplikasi produksi).

Satu hipotetis terakhir: tim teknik yang bertugas mengonsumsi feed inventaris (berbeda dengan tim yang bertanggung jawab atas aplikasi retailer) bermigrasi ke skema inventaris baru. Mereka tidak mengetahui satu langkah pun dari proyek "Item Teratas yang Tidak Anda Bawa", dependensi yang dibangun secara diam-diam oleh tim data di atas pekerjaan mereka, atau dependensi yang dibangun orang lain di atas pekerjaan tim data. Mereka menghapus tabel awal. NULLmengalir ke Looker, Salesforce, Hubspot, dan aplikasi peritel produksi. Tim data telah merusak prod.

Mari rekap apa yang terjadi, baik dan buruk:

Dari sudut pandang seorang profesional data yang memulai karir mereka sebelum "aktivasi data", semua yang baru saja terjadi (kecuali bagian akhir) sungguh luar biasa! Apa yang dimulai sebagai dasbor Looker berubah dengan cepat menjadi aplikasi produksi, dengan nilai bisnis yang ditunjukkan di setiap langkah. Tidak ada sumber daya SWE yang diperlukan hingga akhir—ketika produk yang disarankan telah divalidasi oleh pengguna.

Dampak dan lintasan karier seorang profesional data dibatasi oleh area permukaan yang dapat mereka pengaruhi. Analis intelijen bisnis tahun 2012 dibatasi di Tableau + presentasi internal. Profesional data saat ini BISA memasukkan baris ke Salesforce, memicu email pemasaran, dan membuat produk data untuk konsumsi dalam layanan produksi dan aplikasi. Ini adalah berita yang luar biasa!

Sisi buruknya: profesional data sepuluh tahun yang lalu terbiasa dengan pesan "Hei, data terlihat mati". Skenario kasus terburuk adalah memasukkan metrik yang salah ke dek papan. Hari ini, tim data dapat bangun untuk pemberitahuan Pagerduty bahwa mereka telah merusak Salesforce, Hubspot, dan aplikasi produksi, bahkan jika Pagerduty disiapkan . Aktivasi data telah meningkatkan taruhan dari apa yang dapat dilanggar oleh tim data.

Dalam contoh hipotetis ini, manajer toko dan akun akan terganggu selama satu atau dua hari hingga kesalahan diperbaiki. Semua hal dipertimbangkan — kesalahan ini relatif tanpa biaya.

Itu tidak berarti itu tidak bisa mahal! Bayangkan output ilmu data yang memprediksi churn pelanggan, dan kode promo $5 dikirim saat probabilitas tersebut melewati ambang batas tertentu. Sekarang, bayangkan modelnya dilatih ulang, atau dikalibrasi ulang, atau apa pun secara tidak benar. Pipa aktivasi data yang sama dapat digunakan untuk secara tidak sengaja mengirimkan jutaan dolar kode promo.

Tumpukan data modern membuatnya sangat mudah untuk menghasilkan output data — terlepas dari apakah mereka harus diproduksi, atau jika tim yang membuat input mengetahui bagaimana output dikonsumsi. Alat-alat ini tidak memerlukan kueri atau alur awal untuk dikeraskan karena alat tersebut diangkat ke kasus penggunaan yang lebih penting. Mereka tidak memerlukan persetujuan atau visibilitas dari mereka yang membuat hasil awal.

Jika Anda mengingat logika bisnis tambahan:

• Manajer akun menggunakan penilaian mereka dan tidak merekomendasikan SKU minuman keras ke toko bir/anggur
• Rekanan CRM menghapus SKU <= 50ml karena pertimbangan merek
• Tim aplikasi pengecer menghapus SKU yang sangat musiman karena umpan balik pelanggan

Jadi apa yang bisa kita lakukan untuk memperbaiki masalah ini?

Sistem Cenderung Produksi

Kisah-kisah horor, masalah umum, dan solusi teknis untuk sistem produksi telah ditulis dengan fasih di seluruh data twitter dan substack. Solusinya, sebagian besar, praktik terbaik yang telah diketahui oleh SWE selama beberapa dekade (atau, seperti yang dikatakan Zach Kanter dengan cara lain , rekayasa data status quo hanyalah rekayasa perangkat lunak tanpa praktik terbaik ). Beberapa bagian / prinsip yang paling melekat pada saya untuk tim data:

Tim data tidak mengontrol input mereka (h/t Nick Schrock )

Output data adalah dasar dari banyak keputusan dalam organisasi, terlepas dari apakah manusia atau algoritme yang bertanggung jawab. Namun, tim data tidak mengontrol input mereka seperti yang dilakukan software engineer. Tim data harus defensif dalam perhitungan mereka dengan berinvestasi di QA; untuk masalah masa lalu serta untuk masalah yang belum terjadi. Pengujian ini harus mencakup:

• Validitas baris tunggal ( intsaat Anda mengharapkan int, <50 saat Anda mengharapkan <50)
• Validitas baris agregat (asumsi perincian, konteks bisnis seputar jumlah baris, jumlah baris relatif terhadap kemarin, distribusi agregasi seperti penjumlahan, rata-rata, p90s, median)
• Keberadaan / kedaluwarsa data (tabel waktu terakhir diperbarui)

Biaya kesalahan secara eksponensial lebih tinggi dalam sistem produksi daripada dalam pementasan. Buat pipeline pengujian data dan pengembangan + pola penerapan yang mendeteksi kesalahan dan menguji asumsi sedini mungkin.

Ini adalah solusi yang dapat diterapkan oleh tim data yang memilih alat yang tepat (kami menyukai Great Expectations ) dan berusaha. Itu 20% masalahnya. 80% tantangan organisasi + komunikasi yang tersisa adalah penyebab sistem rusak. Berikut adalah solusi seluruh perusahaan:

Buat knalpot data tingkat produksi

Atau, sengaja membuat data . Perusahaan yang percaya ilmu data itu kuat juga harus percaya dengan sengaja membuat data produksi untuk mendukung pembelajaran mesin dan kasus penggunaan analitik tingkat lanjut (h/t Yali Sasoon). Ini membutuhkan kemitraan dengan para insinyur, dan keselarasan di seluruh perusahaan sehingga data dapat dibuat dengan sengaja, bukan diekstraksi dengan susah payah.

Buat dan rayakan jalan menuju produksi

Perusahaan terlalu sering merayakan iterasi cepat dalam lingkungan pengembangan tanpa mengukir panduan atau waktu untuk mengeraskan pekerjaan menuju tingkat produksi. Rayakan pekerjaan ini, dan ukir waktu dan kepemilikan lintas fungsi yang eksplisit untuk sistem pengerasan.

Sistem Cenderung Menuju Federasi Buta

Sekali lagi — mari rayakan masalah ini! Jika banyak orang menemukan kasus penggunaan bisnis yang berbeda untuk keluaran tim data, Anda melakukan sesuatu dengan benar. Namun, dengan cara yang sama seperti beberapa dasbor ad-hoc dapat membuatnya menjadi dek papan 10 tahun yang lalu, kueri ad-hoc tersebut dapat membuatnya menjadi aplikasi produksi tanpa Anda sadari.

Manfaatkan satu bidang kontrol untuk orkestrasi yang digerakkan oleh peristiwa

Fivetran, dbt, dan Hightouch semuanya memiliki kemampuan untuk menjadwalkan pekerjaan melalui jadwal cron dan UI. Hal ini memungkinkan orkestrasi dibangun dengan cara yang tidak memunculkan visibilitas ke dalam dependensi implisit. Bayangkan Hightouch dijadwalkan bergerak exp_fb_click_idssetiap hari pada jam 8 pagi melalui UI. Fivetran dan dbt tidak memiliki visibilitas ke ketergantungan itu, juga tidak berkontribusi pada basis kode di hulu Hightouch.

Sebagai gantinya, gunakan alat orkestrasi (Dagster/Prefect/Airflow) sebagai bidang kontrol tunggal. Gabungkan ketergantungan antara alat dan buat DAG holistik yang berjalan berdasarkan keberhasilan langkah sebelumnya, bukan berharap tugas hulu berhasil pada waktu tertentu dalam sehari. Paket ulang .

Buat pemetaan satu-ke-satu dari ekspor tim data ke kasus penggunaan hilir

Tim data harus terbiasa dengan cara dbt menyarankan untuk menyusun proyek . Biasanya, lapisan pementasan diatur dan diberi nama dengan cara yang membuat hubungan satu-ke-satu ke input sumber menjadi sangat jelas. Gunakan pola serupa untuk keluaran. Pada tingkat yang sama harus jelas bahwa objek Peluang dan Akun Salesforce mewakili tabel dbt dalam pementasan, harus jelas bahwa ekspor data digunakan untuk satu dan hanya satu kasus penggunaan.

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.opportunity
;

select * -- Extremely clear this comes from one and only one place
from raw.salesforce.account
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_retailer_app
;

select * -- Extremely clear this goes to one and only one place
from ml_outputs.model_results.exp_top_items_salesfrce
;

Alih-alih meringkas layerinitis, saya akan mengarahkan Anda lagi ke utas dan definisi Jean-Michel Lemieux yang luar biasa. Nasihat umum adalah miliknya, dengan beberapa data spesifik yang berhasil untuk saya.

Definisi teknis untuk layerinitis adalah tim meletakkan kode di tempat yang paling nyaman bagi mereka sambil mengoptimalkan kecepatan vs meletakkan kode di tempatnya ketika mempertimbangkan perspektif jangka panjang pada keseluruhan sistem perangkat lunak.

Kurangi area di mana logika bisnis dapat disuntikkan dalam mil terakhir:

Hightouch dan Sensus memungkinkan transformasi SQL. Fivetran digunakan untuk . Sebagian besar konsumen aktivasi data (Sales/CX CRMs, CDP) memungkinkan lapisan logika bisnis SQL atau rendah/tanpa kode. Jika memungkinkan, jangan menulis logika bisnis di alat ini. Jika Anda mengikuti pemetaan satu-ke-satu ekspor tim data ke kasus penggunaan hilir, Reverse ETL Anda selalu dapat:

select * from exp_table_for_single_use_case;

Perubahan dalam logika bisnis harus diterapkan pada model dbt tersebut, bukan pada mil terakhir.

Buat kebijakan "Time To Live" pada last mile transform:

Tim data tidak dapat menyingkirkan transformasi mil terakhir sepenuhnya. Anda tidak ingin pemangku kepentingan merasa diblokir oleh tim data. Akan selalu ada kebutuhan untuk memperkenalkan hot fix atau mengulang logika bisnis yang lebih cepat daripada dbt PR + penyegaran Snowflake.

Secara lebih umum, pemangku kepentingan bisnis Anda memiliki konteks yang tidak Anda miliki. Anda ingin melihat bagaimana mereka mengubah data Anda. Pikirkan kembali SKU musiman, volume, logika kategorisasi toko yang dilewatkan oleh insinyur analitik. Ciptakan dunia tempat pemangku kepentingan bisnis Anda dapat meningkatkan pekerjaan Anda!

Kebijakan "Waktu Untuk Hidup" adalah tarikan gravitasi ke arah sentralisasi. Izinkan transformasi mil terakhir, tetapi tinjau, dan tarik logika bisnis kembali ke lapisan dbt/ilmu data pusat dengan irama yang berfungsi untuk tim data dan pemangku kepentingan bisnis Anda

Membangun budaya standarisasi + merayakan akses ke basis kode lintas fungsi

Orang-orang secara default menulis logika bisnis di alat yang paling nyaman bagi mereka. Untuk rekanan CRM, itu mungkin Hubspot / Iterable / Braze. Cara terbaik bagi tim data untuk mencegah logika bisnis yang meluas tidak hanya dengan membatasi transformasi last mile di alat lain , tetapi juga mengundang orang lain ke alat mereka .

Ini mungkin pengambilan ️️️. Ada banyak alasan untuk khawatir tentang anggota tim non-data yang menulis logika di SQL dan membuat PR dbt. Yang bisa saya jamin — logika ini akan ditulis, dan jika tim data menjaga gerbang, itu akan ditulis di luar visibilitas mereka. Jika tim data dapat mendidik dan mendorong kontribusi ke basis kode mereka, mereka mengundang kode untuk ditulis di tempatnya.

Mendarat pesawat:

Ini saat yang tepat untuk menjadi pemimpin data. Dekade terakhir pengembangan ekosistem data telah mengomoditaskan pergerakan dan manipulasi data di seluruh alat pihak pertama dan ketiga. Seorang profesional analitik berbakat dengan mimpi dan kartu kredit dapat memberdayakan pelaporan internal, alat internal, otomasi pemasaran, dan aplikasi produksi. Ini adalah berita luar biasa yang obyektif untuk perusahaan dan profesional data.

• Tumpukan data modern memungkinkan tim data menghasilkan apa pun, terlepas dari apakah seharusnya, dan tanpa izin atau visibilitas teknik produksi.
• Tumpukan data modern memungkinkan pemangku kepentingan bisnis menambahkan logika bisnis jarak jauh untuk mendukung alur kerja produksi, terlepas dari apakah seharusnya, dan tanpa izin atau visibilitas tim data.

Pada titik tertentu, produk data Anda akan merusak aplikasi produksi. Email pemasaran akan dikirim yang seharusnya tidak. Tim CRM akan menyalahkan tim data, tim data akan menyalahkan tim prod engineering. Salah satu pelajaran terpenting yang saya pelajari, tetapi masih harus saya perjuangkan setiap hari: Kemampuan untuk masuk ke ruangan yang tegang/Zoom dan mengingatkan semua orang bahwa kita semua berada di tim yang sama adalah kekuatan super. Itu adalah ringkasan sebenarnya tentang cara memasukkan sistem data ke dalam produksi.

Jika Anda dapat membuat budaya di mana:

• Insinyur produksi membuat knalpot data dengan niat dan kegembiraan tentang bagaimana data akan digunakan
• Anggota tim data mencari kasus penggunaan, meminta umpan balik, dan bertanya kepada pemangku kepentingan mereka, "Hei, apa yang sebenarnya Anda lakukan dengan data yang saya kirimkan kepada Anda?"
• SWE dapat membimbing dan meningkatkan praktik dan standar terbaik tim data untuk meningkatkan aliran data ad-hoc ke tingkat produksi
• Anggota tim data dapat membimbing dan meningkatkan pemangku kepentingan bisnis tentang cara menambahkan logika bisnis, kerangka kerja yang sesuai dengan logika
• Setiap tim mengundang orang lain ke dalam basis kode mereka, dan mendorong perspektif jangka panjang pada keseluruhan arsitektur perusahaan

Ian Macomber adalah Head of Data Science and Analytics Engineering di Ramp, kartu korporat pertama dan satu-satunya yang membantu perusahaan membelanjakan lebih sedikit. Sebelumnya, dia adalah VP of Analytics and Data Engineering di Drizly.

Ada tren keempat juga! Nantikan Sistem Data Cenderung Menuju Perhitungan , yang terlalu banyak untuk dimasukkan ke dalam satu artikel.