Dengarkan Kata Bendanya

🌐 Juga tersedia dalam 28 bahasa

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris

Modul 1 dari 6 dalam bab Memodelkan Data Berdasarkan Makna, bab 2 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: ikhtisar bab · Berikutnya: Gambarkan Hubungannya

Pertanyaan yang dijawab modul ini: Bagaimana saya menemukan cikal bakal sebuah model data dalam percakapan bisnis?

Salah satu hal yang saya lakukan dalam panggilan pertama dengan klien adalah mendengarkan kata bendanya.

Saya tidak sedang membicarakan sesi desain pertama. Saya membicarakan percakapan awal ketika saya masih berusaha memahami bisnisnya dan apa yang ingin mereka capai.

Mereka berbicara. Saya mendengarkan.

Dan saya mendengarkan kata-kata seperti:

Mitra Ritel. Penerima. Pusat Distribusi. Manifes. Pengiriman. Rute. Kru. Truk.

Kata-kata benda itu langsung menarik perhatian saya, karena di suatu tempat dalam percakapan itu ada cikal bakal model data saya.

Saya tidak menunggu sampai merasa sudah memahami masalahnya sepenuhnya. Saya mulai melihat datanya sambil masih mendengarkan: saya mendengar kata bendanya, saya mulai membuat sketsa hubungannya, dan sketsa itu membantu saya membingkai percakapan berikutnya. Kadang, di akhir pertemuan pertama dengan klien, saya sudah punya model data versi saya sendiri.

Bagi saya, semuanya dimulai dari kata benda.

Lupakan Salesforce Sejenak

Di sinilah saya ingin Anda menahan sebuah naluri yang sangat kuat, terutama jika Anda sudah cukup lama menjadi admin Salesforce.

Klien bilang pelanggan, dan Anda berpikir:

Akun.

Mereka bilang orang, dan Anda berpikir:

Kontak.

Mereka bilang pusat distribusi, dan Anda sudah bertanya-tanya apakah Anda butuh objek kustom.

Jangan dulu.

Pada tahap ini, saya tidak peduli apakah pelanggan nantinya menjadi Akun, Akun Pribadi, objek kustom, atau yang lain. Pertama-tama saya ingin memahami bisnisnya.

Itulah bedanya memodelkan bisnis dengan mengonfigurasi Salesforce. Jika saya mulai dari objek Salesforce, saya sudah membatasi pemikiran saya pada satu implementasi. Saya mungkin berakhir persis di tempat yang saya duga, tetapi saya ingin sampai di sana karena bisnislah yang membawa saya ke sana, bukan karena Akun dan Kontak adalah dua objek pertama yang saya kenal.

Jadi selama beberapa menit, lupakan Salesforce. Dengarkan bagaimana orang-orang yang benar-benar menjalankan bisnis menggambarkan dunia mereka.

Duduk, Diam, Modelkan

Sebelum kita mendengarkan sebuah bisnis, mari dengarkan sesuatu yang sudah dipahami semua orang. Saat mengajar ini secara langsung, saya mulai dengan anjing.

Ini seekor anjing: Marcus memiliki Bella. Maple Ridge Kennels yang membiakkannya. Ia seekor Labrador, dan ia menguasai trik Duduk, Diam, dan Salaman.

Dengarkan kata bendanya: Marcus, Bella, Maple Ridge Kennels, Labrador, Duduk. Tetapi itu nama: hal-hal yang spesifik. Yang saya inginkan adalah jenis hal tempat setiap nama itu termasuk. Bella adalah seekor Anjing. Marcus adalah seorang Pemilik. Maple Ridge Kennels adalah seorang Peternak. Labrador adalah sebuah Ras. Duduk adalah sebuah Trik. Lima kata benda, lima kandidat kotak.

Click to enlarge

Lalu pertanyaan yang saya ajukan untuk setiap kata benda: apakah ini orang yang menjalankan suatu pekerjaan, atau sepotong data? Marcus adalah orang. Tetapi memiliki Bella bukanlah pekerjaan; itu fakta tentang Bella, dan cepat atau lambat seseorang akan bertanya, “Siapa pemilik anjing ini?” Jadi Pemilik masuk ke dalam model. Pelatih yang mengajari Bella bersalaman adalah orang yang menjalankan suatu pekerjaan, dan mungkin tidak pernah butuh kotak, kecuali bisnis mulai bertanya siapa yang mengajarkan trik yang mana.

Dan perhatikan kata kandidat. Apakah Ras benar-benar kotak tersendiri, atau hanya kata yang ditulis pada anjingnya? Simpan pertanyaan itu; kita akan menjawabnya saat melakukan normalisasi di modul 4.

Itulah seluruh tekniknya, pada sesuatu yang kecil. Sekarang mari kita dengarkan sebuah bisnis sungguhan.

Kata Benda Memberi Anda Kandidat Entitas

Mari dengarkan Steve Trucking, perusahaan keluarga yang akan kita pakai di sepanjang kursus ini. Perusahaan ini mengirim barang-barang besar (kulkas, mesin cuci, televisi) dari pusat distribusi para peritel besar ke rumah-rumah, dan memasang sebagian di antaranya.

Dalam percakapan pertama kita mendengar:

• Mitra Ritel
• Penerima
• Pusat Distribusi
• Manifes
• Pengiriman
• Rute
• Kru
• Truk

Itu sudah berguna. Saya bisa mulai menaruh kotak-kotak di papan tulis.

Jadi masukkan kata-kata benda itu ke dalam persegi panjang. Pada tahap ini memang hanya itu wujudnya: kotak. Tanpa garis, tanpa warna, tanpa apa pun yang menyebut Salesforce. Nanti dalam kursus ini, bentuk dan warna akan mulai punya arti. Untuk sekarang, sebuah persegi panjang hanyalah sesuatu yang dibicarakan oleh bisnis.

Lalu mulailah menata posisinya. Saat menempatkan setiap kotak, pikirkan dua hal: bagaimana kotak-kotak itu saling berhubungan, dan jenis data apa mereka. Sebagian adalah data pelanggan: bisnis dan orang-orang yang bekerja sama dengan kita. Sebagian adalah data transaksional, seperti pesanan dan item pesanan: hal-hal yang terjadi, berulang kali. Dan sebagian adalah data referensi, seperti produk atau layanan yang ditawarkan bisnis: hal-hal yang menjadi tumpuan pekerjaan.

Di Steve Trucking, Mitra Ritel dan Penerima adalah data pelanggan. Manifes, Pengiriman, dan Rute adalah transaksi. Pusat Distribusi, Kru, dan Truk adalah tumpuan pekerjaannya.

Click to enlarge

Tetapi ada satu kata penting di sini: kandidat.

Kata benda adalah petunjuk. Ia tidak otomatis menjadi entitas, dan jelas tidak otomatis menjadi objek Salesforce.

Dalam sesi discovery, saya mencatat setiap kata benda. Untuk setiap kata benda yang mereka ucapkan, saya bertanya pada diri sendiri satu pertanyaan: apakah itu orang yang menjalankan suatu pekerjaan, atau sepotong data? Seorang business development manager adalah orang yang menjalankan pekerjaan. Itu pengguna, peran, mungkin set izin. Pesanan, faktur, item baris: itu potongan data. Keduanya penting, tetapi keduanya berakhir di tempat yang sangat berbeda dalam desain, dan memilahnya sejak awal menyelamatkan saya dari menggambar kotak untuk setiap jabatan di bagan organisasi.

Nah, sebagian kata benda itu adalah orang. Di Steve Trucking, itu adalah Penerima yang menunggu kulkasnya, orang-orang di Mitra Ritel yang mengirim manifes, dan Kru: para sopir dan pembantunya di truk. Ini adalah peran, dan peran mungkin tidak terlihat seperti data. Tetapi ketika orang bertindak atas data, atau terkait dengannya, mereka perlu direpresentasikan dalam data itu sendiri. Siapa yang mengantarkan ini? Siapa yang menandatanganinya? Siapa yang mengirim manifes? Jadi banyak peran, kadang semuanya, ikut masuk ke dalam model.

Dengarkan cara Steve Trucking berbicara, dan Anda akan memperhatikan sesuatu. Mereka tidak pernah hanya bilang “pelanggan.” Ada dua jenis pelanggan. Mitra Ritel adalah peritel besar yang untuknya Steve Trucking mengirim: ia mengirim manifes dan membayar per pengiriman. Penerima adalah orang yang menerima kiriman kulkas itu. Penerima membelinya dari toko dan mungkin tidak pernah mendengar tentang Steve Trucking.

Seandainya saya menulis satu kotak bernama Pelanggan, saya sudah mencampur dua hal yang sama sekali berbeda.

Mungkin Pusat Distribusi cukup penting untuk punya rekaman, riwayat, hubungan, dan atributnya sendiri.

Mungkin kata benda lain ternyata tidak lebih dari sebuah atribut dari sesuatu yang lain.

Itulah yang ingin kita temukan. Kita belum membuat objek. Kita sedang membangun pemahaman kita tentang bisnis.

Sekarang Dengarkan Hubungannya

Kata benda memberi saya titik awal. Lalu saya mendengarkan bagaimana bisnis menghubungkannya.

Sebuah Mitra Ritel mengoperasikan Pusat Distribusi.

Sebuah Mitra Ritel mengirim Manifes untuk setiap DC dan setiap hari pengiriman.

Sebuah Manifes memuat daftar Pengiriman.

Sebuah Pengiriman ditujukan ke seorang Penerima.

Sebuah Rute adalah perjalanan sehari yang terdiri dari sekitar sepuluh Titik Pemberhentian.

Sebuah Kru berisi dua orang menjalankan sebuah Truk.

Sekarang ada sesuatu yang terjadi. Saya tidak lagi melihat daftar kata benda. Saya mulai melihat sebuah model.

Click to enlarge

Di sinilah pertanyaan-pertanyaan mulai bermunculan.

Bisakah sebuah Mitra Ritel punya lebih dari satu pusat distribusi?

Apakah pengiriman sama dengan titik pemberhentian?

Bisakah satu titik pemberhentian mengantar ke dua Penerima?

Apakah sebuah kru selalu terdiri dari dua orang yang sama?

Apakah kita peduli kru mana yang memegang truk mana bulan lalu, atau hanya truk mana yang mereka kendarai hari ini?

Perhatikan apa yang kita lakukan. Kita belum mengajukan pertanyaan Salesforce. Kita mengajukan pertanyaan bisnis. Dan jawaban-jawaban itulah yang pada akhirnya akan menggerakkan desain Salesforce.

Model Pertama Anda Tidak Harus Sempurna

Saya tidak berharap kotak-kotak pertama yang saya gambar akan bertahan tanpa perubahan. Malah, saya akan curiga jika itu terjadi.

Tujuan model pertama bukan untuk benar. Tujuannya adalah memberi kita sesuatu yang cukup konkret untuk menemukan di mana kita salah.

Taruh Pengiriman, Rute, Kru, dan Truk di papan, dan orang-orang bisa menanggapinya.

“Sebenarnya, satu pengiriman tidak selalu satu barang. Bisa saja mesin cuci, mesin pengering, dan pengangkutan barang lamanya.”

Bagus. Ceritakan lebih banyak.

“Kami tidak menugaskan kru ke sebuah pengiriman. Kami menugaskan kru ke sebuah rute.”

Bagus. Apa saja yang ada di rute itu?

“Dan kalau ada pemasangan, kru tidak bisa menutup titik pemberhentian itu sampai daftar periksa dan fotonya selesai.”

Sekarang kita mempelajari sesuatu yang penting.

Sebuah diagram telah mengubah percakapan yang samar menjadi sesuatu yang bisa kita tantang. Itulah salah satu alasan saya suka memodelkan sejak awal. Saya tidak berusaha membuat ruangan terkesan dengan diagram yang indah. Saya berusaha belajar lebih cepat.

Model adalah bagian dari percakapan.

Inilah Model Konseptual Anda

Ada nama formal untuk apa yang mulai kita bangun: model data konseptual.

Pada tingkat ini, saya tertarik pada hal-hal penting yang dipedulikan bisnis dan bagaimana semuanya saling berhubungan. Saya belum memikirkan objek standar versus kustom, nama API bidang, lookup versus master-detail, bidang wajib, indeks, otomatisasi, Apex, atau Flow. Semua itu penting, dan kita akan sampai ke sana. Tetapi jika kita memutuskannya sebelum memahami apa yang kita modelkan, kita menyelesaikan masalah yang salah terlebih dahulu.

Model konseptual harus masuk akal bagi orang-orang di ruangan yang tidak mengenal Salesforce. Itu uji yang berguna. Jika saya harus menjelaskan arti Delivery__c sebelum manajer operasional bisa membaca diagram saya, saya sudah terlalu cepat masuk ke implementasi.

Saya ingin mereka melihat model itu dan berkata:

“Ya, begitulah cara bisnis kami berjalan.”

Atau, lebih baik lagi:

“Tidak, bukan begitu cara kerjanya.”

Karena sekarang saya punya sesuatu untuk diperbaiki.

Teknik yang Sama Berlaku Ketika Tidak Ada yang Berbicara

Ini bukan hanya sesuatu yang saya pakai dalam discovery dengan klien. Teknik ini juga berlaku ketika “kliennya” adalah sebuah dokumen.

Saat mengerjakan dokumen persyaratan, saya melakukan hal yang kurang lebih sama. Apa saja konsep bisnis yang penting? Hubungan apa yang sedang digambarkan? Apa yang muncul berulang kali? Apa yang punya siklus hidupnya sendiri, perlu diidentifikasi secara tersendiri, atau butuh riwayat? Apa yang sedang dibuat, diubah, ditugaskan, dipindahkan, dijadwalkan, atau dipensiunkan?

Ini hal-hal yang sama dengan yang saya dengarkan di pertemuan pertama. Di atas kertas, petunjuk-petunjuk itu mengubah paragraf demi paragraf persyaratan menjadi sebuah model yang bisa saya nalar, dan menjadi pertanyaan yang lebih baik untuk percakapan berikutnya.

Model bukan sekadar sesuatu yang Anda hasilkan setelah menyelesaikan masalah. Model adalah salah satu alat yang Anda pakai untuk menyelesaikan masalah.

Yang Diputuskan Arsitek di Sini

Di akhir putaran pertama ini, saya berusaha memutuskan:

• Kata benda mana yang mewakili kandidat entitas yang bermakna.
• Kata-kata berbeda mana yang mewakili konsep bisnis yang sama, dan satu kata mana yang menyembunyikan dua konsep (seperti “pelanggan”).
• Konsep mana yang butuh rekaman dan siklus hidupnya sendiri.
• Bagaimana konsep-konsep utama saling berhubungan.
• Pertanyaan apa yang perlu dijawab bisnis sebelum saya bisa memodelkannya dengan yakin.

Saya belum memutuskan implementasi Salesforce-nya. Pertama, kita perlu memahami bisnisnya cukup baik untuk menggambarkannya. Dan begitu kata-kata benda sudah ada di papan, hal berikutnya yang ingin saya pahami adalah garis-garis di antaranya.

Di luar ujian: apa yang diubah AI. Berikan dokumen persyaratan kepada alat AI dan dalam hitungan detik ia akan menemukan kata bendanya, mengusulkan entitas, dan membuat sketsa hubungannya. Gunakan untuk mempercepat discovery, tetapi jangan menyerahkan pemahaman kepadanya: ia tidak bisa tahu bahwa “pelanggan” berarti dua hal berbeda di Steve Trucking kecuali bisnis memberi tahu Anda. Tunjukkan model pertamanya kepada orang-orang yang menjalankan bisnis dan tanyakan, “Apakah benar begini cara bisnis Anda berjalan?”