Pertanyaan yang dijawab modul ini: Bagaimana saya menggambar lanskap yang menunjukkan ke mana data pergi?
Beri saya skenario baru dan papan tulis kosong, dan salah satu hal pertama yang akan saya gambar adalah lanskap sistemnya. Tidak indah, tidak setiap API, belum model datanya. Saya ingin melihat perusahaannya: siapa penggunanya, sistem apa yang terlibat, di mana Salesforce berada, apa yang mengelilinginya, dari mana data datang dan ke mana ia pergi. Lalu saya ingin menyusuri panah-panahnya. Lanskap yang baik bukanlah gambar kotak-kotak. Lanskap adalah cara untuk menyingkap keputusan arsitektur.
Saya membuat kandidat CTA melatih hal ini. Baca skenarionya, lalu mulailah menggambar. Jangan menunggu sampai Anda menyelesaikan semuanya di kepala; gambar itulah yang membantu Anda menyelesaikannya. Itulah sebabnya pekerjaan rumah setelah hari pertama adalah memulai lanskap sebelum mencoba membuat model data. Gambar model data lebih dulu dan Anda sudah berasumsi apa yang seharusnya ada di Salesforce. Gambar lanskap lebih dulu dan Anda bisa melihat sistem-sistem yang seharusnya membentuk keputusan itu.
Mulailah dari tingkat atas, lalu masuk lebih dalam: seluruh perusahaan lebih dulu, lalu detailnya di bagian yang penting.
Ada banyak cara menggambar lanskap sistem. Ini hanyalah cara saya, yang saya sempurnakan selama bertahun-tahun, dan saya membagikannya agar Anda bisa melihat cara menyusunnya dengan cepat. Saya memakainya untuk setiap lanskap Salesforce, dan tata letak itu terbaca seperti sebuah kalimat: orang di sebelah kiri menjangkau Salesforce di tengah, dipercaya melalui sistem-sistem di atasnya, dilayani melalui kanal-kanal di bawahnya, dan terhubung ke back office di sebelah kanan.
Orang di sebelah kiri, dari atas ke bawah: pengguna internal, mitra, pelanggan. Belum setiap persona; cukup untuk menjawab siapa yang mencoba menjangkau arsitektur ini? Setiap kelompok menunjuk ke tempat ia masuk: pengguna internal ke Salesforce, mitra ke komunitas mitra, pelanggan ke komunitas pelanggan. Sistem tidak ada dengan sendirinya. Seseorang, atau sesuatu, sedang mencoba memakainya.
Langkah 2 dari 6: siapa yang mencoba menjangkau arsitektur ini?
Salesforce di tengah. Satu kotak polos. Bukan karena Salesforce adalah pusat perusahaan (kita baru saja menghabiskan tiga modul untuk mengatakan bahwa bukan) melainkan karena itulah sistem yang sedang saya rancang. Ia adalah jangkarnya.
Komunitas tepat di bawahnya, menempel. Komunitas mitra dan komunitas pelanggan adalah endpoint yang terpisah, jadi masing-masing mendapat kotaknya sendiri. Tetapi keduanya menempel pada Salesforce, karena tidak ada yang perlu diintegrasikan untuk menjangkaunya: keduanya berjalan di org yang sama.
Langkah 3 dari 6: Salesforce di tengah, komunitas tepat di bawahnya.
Identitas di atas. Penyedia identitas ditaruh di bagian atas, yang sering dilupakan developer: satu untuk pengguna internal, mungkin satu lagi untuk mitra. Paket AppExchange juga ditaruh di atas, digeser ke kanan, karena semua itu adalah kemampuan yang dibawa masuk ke dalam org, bukan sistem back office yang bertukar data dengannya. Situs web publik berada di kiri atas.
Langkah 4 dari 6: identitas di atas, kotak yang dilupakan developer.
Integrasi, lalu back office, di sebelah kanan. Lapisan integrasi, berupa ESB atau iPaaS (atau MuleSoft, jika namanya disebut), adalah batang tinggi tepat di kanan Salesforce. Sistem-sistem internal berada di belakangnya: ERP, keuangan, manajemen pesanan, sistem lama, data warehouse. Sekarang halamannya terbaca dari kiri ke kanan: orang, Salesforce, integrasi, back office.
Kanal di bawah. Apa pun yang punya jalur langsung ke pelanggan: email-to-case, web-to-lead, telepon, perpesanan.
Data masuk dan keluar, di kanan bawah. Sumber data eksternal, arsip, pemuatan data.
Data 360 di sebelah kanan, di bawah lapisan integrasi. Pengguna tidak pernah terhubung ke sana, dan tenant-nya terhubung ke banyak sistem back-end, jadi ia ditaruh bersama saluran data, tempat garis-garis itu tetap pendek: di samping sistem-sistem internal, data warehouse, dan data di kanan bawah. Tim data memang membuka layar-layarnya, tetapi layar itu ada di dalam org: Data 360 adalah near-core, dikelola di core dan di-hosting di luar core (modul 1). Satu garis kembali ke Salesforce menunjukkan siapa yang mengelolanya. Di mana Anda menaruh kotaknya harus menceritakan apa yang dikerjakannya.
Tidak ada geometri yang sakral di sini. Nilai sebuah konvensi adalah saya tidak perlu menciptakan ulang bahasa visual setiap kali, dan siapa pun yang pernah melihat salah satu diagram saya bisa membaca diagram berikutnya lebih cepat.
Jaga notasinya tetap sederhana. Setiap sistem adalah sebuah kartu: namanya, perannya, dan ikon kecil yang menunjukkan jenisnya: ERP, database, penyedia identitas, sekelompok orang. Wilayah-wilayah yang baru saya jelaskan digambar sebagai zona samar berlabel, sehingga tata letaknya sendiri terlihat. Sebuah legenda di bagian bawah menjelaskan arti setiap ikon dan garis.
Jangan menaruh terlalu banyak hal di dalam kotak. Hanya pada lanskap yang sangat rumit saya membuka Salesforce menjadi bagian-bagiannya (Sales Cloud dan Service Cloud di dalam org, dengan panah di antaranya). Dan jangan menciptakan lima belas bentuk kecuali masing-masing memberi tahu pembaca sesuatu. Saya ingin seseorang melihat lanskap selama tiga puluh detik dan mulai memahami arsitekturnya. Yang mewah tidak membantu. Yang jelas membantu.
Jangan menunggu desain detail untuk memikirkan volume. Panah yang membawa 500 produk per malam dan panah yang membawa 200.000 pembacaan GPS per hari bisa terlihat persis sama di lanskap. Keduanya bukan masalah yang sama. Jadi sebelum menggambar satu panah pun, hitung apa yang berpindah. Mulailah inventaris di balik gambar dengan hitungannya: satu baris per kumpulan data penting, beserta volumenya. Jumlah nolnya mungkin tidak pernah muncul di panah, tetapi Anda perlu tahu kapan Anda melewati angka-angka besar: ribuan atau jutaan dalam satu jam, ratusan ribu transaksi, bahkan puluhan sampai ratusan transaksi per detik.
Angka-angka itu menentukan mekanismenya. Beberapa ratus rekaman per malam adalah batch. Panggilan yang ditunggu seseorang bisa sinkron, jika volumenya memungkinkan. Puluhan sampai ratusan per detik mungkin membutuhkan event, seperti platform event, alih-alih satu panggilan per rekaman. Panahnya akan terlihat sama; volumenya yang memutuskan apa yang membawanya, jadi catat di inventaris, tempat mekanismenya dipilih.
Mekanismenya bahkan bisa mengubah arah panah. Kirim beberapa rekaman per menit, dan Salesforce cukup melakukan panggilan keluar: panahnya dimulai dari Salesforce. Kirim jauh lebih banyak, dan Salesforce mungkin menerbitkan event di event bus; sistem eksternal berlangganan dan memanggil masuk untuk mengambilnya, jadi sekarang panahnya dimulai dari ujung yang lain. Lebih besar lagi, misalnya sinkronisasi jutaan rekaman setiap malam, dan itu menjadi proses batch. Jadi ketahui hitungan Anda sejak awal, saat Anda mulai merancang mekanismenya, karena hitungan itu bisa menggambar ulang panahnya.
Volume penting di dua tempat, karena dua alasan. Di model data, saya membutuhkannya untuk mewaspadai volume data besar dan merencanakan pengarsipan; Bagian 2 membahasnya secara mendalam. Di lanskap sistem, angka-angka besar di inventaris menentukan pilihan pola integrasi dan mekanismenya. Modul 6 menaruh jumlah nol yang nyata di lanskap Steve Trucking dan inventarisnya. Dengan hitungan di tangan, gambarkan panahnya.
Dengan sistem-sistem sudah di tempatnya, hubungkan semuanya, dan lanskap menjadi arsitektur. Kotak adalah sistem; panah menunjukkan siapa yang memulai koneksi. Panah dimulai dari sistem yang membuka koneksi dan menunjuk ke sistem yang dipanggilnya: dari klien ke server. Label-nya menyebutkan apa yang berpindah, dan ke arah mana.
Aturan itu berlaku untuk lanskap sistem, tempat sistem berbicara dengan sistem. Di diagram aliran data, panah mengikuti datanya, seperti yang Anda duga. Jangan bawa aturan lanskap ke diagram lain; itu hanya menambah kebingungan.
Panah-panahnya ditambahkan. Setiap kotak tetap di tempatnya; setiap panah dimulai dari sistem yang membuka koneksi, dan labelnya menyebutkan apa yang berpindah dan ke arah mana.
Jadi jika lapisan integrasi mendorong produk ke Salesforce, panahnya berjalan dari lapisan integrasi ke Salesforce, berlabel produk masuk. Jika Salesforce memanggil keluar untuk mengambilnya, panahnya dimulai dari Salesforce, tetap berlabel produk masuk. Data yang sama, percakapan yang berbeda, dan perbedaan itu memberi tahu saya siapa yang membutuhkan kredensial dan siapa yang harus menangani kegagalan. Salesforce mengirim pesanan melalui lapisan integrasi: pesanan keluar. Pemenuhan dari ERP kembali: status pesanan masuk. Sekarang saya bisa melihat siapa yang memulai setiap percakapan, di mana data masuk ke Salesforce dan di mana ia keluar, aliran mana yang melintasi batas, di mana kepemilikan kemungkinan berada, dan di mana saya perlu bertanya lebih lanjut.
Dan ingat modul 1: setiap kali saya hanya melihat satu aliran, saya mulai khawatir. Di tingkat atas, panah pesanan keluar bergantung pada aliran balik: pelanggan masuk, produk masuk, harga. Lihat lebih dalam lagi dan ada perjalanan pulangnya: penerimaan, penolakan, status, nomor faktur, pembatalan. Panah-panah itu memberi saya sesuatu yang konkret untuk ditantang.
Di sinilah lanskap berhenti menjadi sekadar seni PowerPoint. Di dewan peninjau, setiap panah bisa memancing tiga pertanyaan, dan saya ingin Anda punya jawabannya:
Bagaimana ia diautentikasi? OAuth, sertifikat, kredensial bernama, atau yang lain?
Apakah sinkron atau asinkron? Apakah Salesforce menunggu ERP, atau menerbitkan lalu melanjutkan? Seberapa cepat bisnis butuh hasilnya?
Apa mekanismenya? Panggilan REST, event, file, antrean pesan, melalui MuleSoft atau langsung?
Lalu: apa yang terjadi ketika sisi lain mati? Setiap panah butuh mekanisme. Jika Anda tidak bisa menjelaskannya, garis itu hanya hiasan.
Dan “fire and forget” bukanlah jawaban. Biasanya itu berarti “saya belum merancang apa yang terjadi setelah ‘fire’-nya.” Apakah sampai? Apakah diterima? Apakah gagal? Apakah akan dicoba lagi? Siapa yang tahu kalau ia macet? Bagaimana jika pesan yang sama tiba dua kali? Tidak satu pun dari itu masuk ke lanskap, karena lanskapnya akan menjadi tidak terbaca. Tetapi panah itu seharusnya membuat Anda tahu bahwa pertanyaan-pertanyaan itu ada.
Perbesar satu panah mana pun dan ada klien dan server, dan masing-masing memiliki separuh bagiannya. Klien membuka koneksi: ia membutuhkan endpoint dan port, mendapatkan token dari server autentikasi lebih dulu, memanggil protokol dan kontrak yang didefinisikan server, dan memilih apakah akan menunggu. Hanya klien yang melihat seluruh perjalanan pulang-pergi, jadi hanya klien yang bisa mencoba ulang. Server mendengarkan, mendefinisikan protokol, kontrak, dan payload, memvalidasi apa yang masuk, dan hanya melihat bagiannya sendiri. Ketika saya menggambar sebuah panah, saya sudah tahu ujung mana yang mana, dan itu memberi tahu saya siapa pemilik setiap pertanyaan ini.
Satu panah, diperbesar: klien menangani, server mendefinisikan. Semua ini tidak masuk ke lanskap, tetapi setiap panah memilikinya.
Sekarang balikkan panahnya. Ketika ERP memanggil Salesforce, Salesforce adalah server: ia mendefinisikan API-nya, menjalankan server otorisasinya sendiri, dan memutuskan melalui External Client App dan pengguna integrasi apa yang boleh dilakukan pemanggil. Pertanyaan yang sama, sisi yang lain.
Di sinilah arsitek merusak diagram yang bagus: mereka membuat satu artefak menjawab segalanya. Lanskapnya diisi nama API, payload, percobaan ulang, antrean error, transformasi, setiap callback, dan tak lama kemudian tidak ada yang bisa membacanya. Jangan. Lanskap adalah gambaran besarnya: sistem dan aliran penting di antaranya.
Ketika saya perlu menjelaskan sebuah interaksi, saya menggambar diagram kedua, tetapi tidak untuk setiap integrasi. Jika sistem A mengirim sesuatu ke B, atau bahkan bertanya dan mendapat jawaban, panah berlabel sudah cukup. Saya ingin swim lane ketika prosesnya menjadi percakapan: A memanggil B, B mengecek ke C, C menjawab, B membuat sesuatu lalu memanggil balik A, seseorang menyetujui, sistem lain melanjutkan. Patokan saya: lebih dari satu atau dua pertukaran bolak-balik, dan urutannya mendapat swim lane sendiri. Panah di lanskap; percakapan di swim lane.
Dan perhatikan bahwa sebuah panah bermakna lain di sana. Di lanskap, panah adalah koneksi: siapa yang membukanya, dan apa yang berpindah. Di swim lane, setiap panah adalah satu pesan dalam sebuah percakapan, dibaca berurutan: permintaan pergi ke satu arah, balasan kembali ke arah lain, dan langkah berikutnya menyusul.
Ketika lanskap terlihat hampir selesai, susurilah, panah demi panah. ERP ke Salesforce: apa yang berpindah, siapa pemiliknya, bagaimana autentikasinya, apa mekanismenya, sinkron atau asinkron, seberapa terkini datanya harus? Lalu panah berikutnya, dan berikutnya. Di sinilah celah-celah muncul. “Oh, kami belum pernah memastikan bagaimana mitra sebenarnya mengirim itu.” “Kami mengirim pesanan ke ERP, tetapi kami belum merancang bagaimana pesanan yang ditolak kembali.” Bagus. Anda menemukannya di papan tulis, bukan di production.
Gambarnya harus tetap mudah dibaca, jadi detailnya masuk ke inventaris di baliknya. Anda sudah memulainya dengan hitungan; sekarang selesaikan, satu baris per kumpulan data atau aliran yang penting:
Kolom
Yang ingin saya ketahui
Kumpulan data
Pelanggan, produk, pesanan, pengiriman, faktur
Jenis
Master, referensi, transaksional, analitis, tidak terstruktur
Itulah sebabnya saya suka artefak ini: ia membantu saya berpikir. “Bagaimana kita membuat laporan lintas Salesforce dan ERP?” Itu pertanyaan dari modul 3: diagram saya yang mana yang menyelesaikan ini dengan indah? Lanskap. Jika semuanya ada di core, laporan standar. Jika datanya ada di ERP dan data warehouse, Anda bisa langsung melihatnya. “Di mana atribut pelanggan ini seharusnya dikelola sebagai master?” Lihat sistem mana yang memakainya dan mana yang sudah memiliki pelanggan. “Apakah Salesforce butuh setiap pembacaan GPS?” Siapa yang menghasilkannya, siapa yang mengonsumsinya, apa beban kerjanya? Mungkin Salesforce butuh posisi saat ini dan platform lain menyimpan riwayatnya. Lanskap tidak memberikan jawabannya kepada Anda. Lanskap memberi Anda sudut pandang yang tepat atas masalahnya.
Satu disiplin lagi. Di perusahaan yang sudah ada, gambarkan apa yang ada, bukan apa yang Anda harapkan ada. Spreadsheet yang dikirim lewat email setiap Jumat: gambarkan. CSV milik mitra di server SFTP: gambarkan. Integrasi yang melewati ESB karena alasan historis: gambarkan. Orang yang mengetik ulang data di antara dua sistem: tunjukkan. Jangan merapikan kenyataan saat Anda sedang mendokumentasikannya. Anda butuh lanskap saat ini sebelum merancang lanskap target, dan itulah yang kita lakukan untuk Steve Trucking di modul 6.
Di luar ujian: apa yang diubah AI. Lanskap sedang menjadi peta agen. Jika sebuah agen menjawab “kiriman saya di mana?”, lanskap harus menyatakan apakah jawabannya datang dari Salesforce, sistem mitra, telematika, ERP, atau gabungan. Agen tidak menghapus batas-batas sistem; agen justru membuat pengetahuan tentang sistem mana yang otoritatif, dan cara menjangkaunya dengan aman, menjadi makin penting.
Sistem dan kelompok pengguna mana yang masuk ke lanskap, dan bagaimana penempatannya menunjukkan perannya.
Aliran mana yang melintasi batas sistem, ke arah mana, dan apa yang kembali.
Bagaimana setiap koneksi diautentikasi, mekanisme apa yang membawanya, dan apakah ia sinkron, asinkron, batch, atau terfederasi.
Kapan panah berlabel sudah cukup dan kapan sebuah interaksi butuh swim lane sendiri.
Apa yang dicatat inventaris di balik gambar: pemilik, beban kerja, volume, org, waktu, autentikasi, dan apakah disalin, dirujuk, atau difederasikan.
Lanskap bukan sesuatu yang saya gambar setelah arsitekturnya selesai. Lanskap adalah cara saya menemukan arsitekturnya. Dan ketika Anda merasa sudah selesai, jangan mengaguminya. Susurilah. Setiap panah yang belum bisa Anda jelaskan menunjukkan di mana pekerjaannya berada.
