Câu hỏi mô-đun này trả lời: Làm thế nào để vẽ một bản đồ hệ thống cho thấy dữ liệu đi đâu?
Đưa tôi một tình huống mới và một tấm bảng trắng, và một trong những thứ đầu tiên tôi vẽ là bản đồ hệ thống. Không đẹp đẽ, không mọi API, chưa phải mô hình dữ liệu. Tôi muốn thấy doanh nghiệp: người dùng là ai, những hệ thống nào tham gia, Salesforce nằm ở đâu, cái gì bao quanh nó, dữ liệu đến từ đâu và đi đâu. Rồi tôi muốn đi qua các mũi tên. Một bản đồ hệ thống tốt không phải là một bức tranh các chiếc hộp. Nó là một cách để phơi bày các quyết định kiến trúc.
Tôi bắt các ứng viên CTA luyện tập điều này. Đọc tình huống, rồi bắt đầu vẽ. Đừng đợi đến khi bạn đã giải xong hết trong đầu; việc vẽ giúp bạn giải. Đó là lý do bài tập về nhà sau ngày đầu là bắt đầu vẽ bản đồ trước khi thử phác mô hình dữ liệu. Vẽ mô hình dữ liệu trước và bạn đã giả định cái gì thuộc về Salesforce. Vẽ bản đồ trước và bạn thấy được các hệ thống nên định hình quyết định đó.
Bắt đầu ở mức cao, rồi đi sâu xuống: toàn bộ doanh nghiệp trước, rồi đến chi tiết ở những chỗ quan trọng.
Có rất nhiều cách vẽ một bản đồ hệ thống. Đây chỉ là cách của tôi, cách tôi đã mài giũa qua nhiều năm, và tôi chia sẻ nó để bạn thấy cách dựng một bản đồ nhanh chóng. Tôi dùng nó cho mọi bản đồ Salesforce, và nó đọc như một câu: con người bên trái tiếp cận Salesforce ở giữa, được tin cậy qua các hệ thống phía trên nó, được phục vụ qua các kênh phía dưới nó, và được nối với bộ phận hậu cần bên phải.
Con người bên trái, từ trên xuống dưới: người dùng nội bộ, đối tác, khách hàng. Chưa cần mọi chân dung người dùng; đủ để trả lời ai đang cố tiếp cận kiến trúc này? Mỗi nhóm trỏ đến nơi họ đi vào: người dùng nội bộ đến Salesforce, đối tác đến cộng đồng đối tác, khách hàng đến cộng đồng khách hàng. Hệ thống không tự tồn tại. Có ai đó, hoặc cái gì đó, đang cố sử dụng chúng.
Salesforce ở giữa. Một chiếc hộp đơn giản. Không phải vì Salesforce là trung tâm của doanh nghiệp (chúng ta vừa dành ba mô-đun để nói rằng không phải) mà vì đó là hệ thống tôi đang thiết kế xoay quanh. Nó là điểm neo.
Các cộng đồng ngay bên dưới nó, chạm vào nó. Cộng đồng đối tác và cộng đồng khách hàng là những điểm truy cập riêng, nên mỗi cái có hộp riêng. Nhưng chúng nằm sát Salesforce, vì không cần tích hợp gì để đến được chúng: chúng chạy trong cùng một org.
Bước 3/6: Salesforce ở giữa, các cộng đồng ngay bên dưới nó.
Danh tính ở trên. Các nhà cung cấp danh tính nằm ở trên cùng, những thứ lập trình viên hay quên: một cho người dùng nội bộ, có thể thêm một cho đối tác. Các gói AppExchange cũng nằm trên đó, lệch sang phải, vì đó là những năng lực được đưa vào org chứ không phải các hệ thống hậu cần trao đổi dữ liệu với nó. Các website công khai nằm ở góc trên bên trái.
Bước 4/6: danh tính ở trên, chiếc hộp lập trình viên hay quên.
Tích hợp, rồi bộ phận hậu cần, ở bên phải. Tầng tích hợp, một ESB hay iPaaS (hoặc MuleSoft, khi được nêu tên), là một thanh cao ngay bên phải Salesforce. Các hệ thống nội bộ nằm phía sau nó: các ERP, tài chính, quản lý đơn hàng, các hệ thống cũ, kho dữ liệu. Giờ trang giấy đọc từ trái sang phải: con người, Salesforce, tích hợp, hậu cần.
Các kênh ở dưới. Bất cứ thứ gì có đường dây trực tiếp đến khách hàng: email-to-case, web-to-lead, điện thoại, nhắn tin.
Dữ liệu vào và ra, góc dưới bên phải. Các nguồn dữ liệu bên ngoài, kho lưu trữ, các đợt nạp dữ liệu.
Data 360 ở bên phải, bên dưới tầng tích hợp. Người dùng không bao giờ kết nối với nó, và tenant của nó kết nối với nhiều hệ thống phía sau, nên nó nằm cùng hệ thống đường ống, nơi những đường nối đó giữ được ngắn: cạnh các hệ thống nội bộ, kho dữ liệu và phần dữ liệu ở góc dưới bên phải. Đội dữ liệu có mở các màn hình của nó, nhưng những màn hình đó nằm trong org: Data 360 là gần lõi (near-core), quản lý trên lõi và lưu trữ ngoài lõi (mô-đun 1). Một đường nối quay về Salesforce cho thấy ai quản lý nó. Nơi bạn đặt chiếc hộp nên kể câu chuyện về việc nó làm.
Không có gì trong hình học này là bất khả xâm phạm. Giá trị của một quy ước là tôi không phải phát minh lại ngôn ngữ hình ảnh mỗi lần, và bất kỳ ai đã xem một sơ đồ của tôi đều đọc sơ đồ tiếp theo nhanh hơn.
Hãy giữ ký hiệu đơn giản. Mỗi hệ thống là một thẻ: tên, vai trò, và một biểu tượng nhỏ cho biết nó là loại gì: một ERP, một cơ sở dữ liệu, một nhà cung cấp danh tính, một nhóm người. Các khu vực tôi vừa mô tả được vẽ thành những vùng mờ có nhãn, để chính cách bố trí hiện ra. Một chú giải ở dưới cùng cho biết mỗi biểu tượng và mỗi đường kẻ nghĩa là gì.
Đừng nhồi quá nhiều vào một chiếc hộp. Chỉ trên một bản đồ rất phức tạp tôi mới mở Salesforce ra thành các phần (Sales Cloud và Service Cloud bên trong org, với mũi tên giữa chúng). Và đừng nghĩ ra mười lăm hình dạng trừ khi mỗi hình nói cho người đọc điều gì đó. Tôi muốn ai đó nhìn bản đồ hệ thống trong ba mươi giây và bắt đầu hiểu kiến trúc. Cầu kỳ không giúp ích. Rõ ràng mới giúp.
Đừng đợi đến thiết kế chi tiết mới nghĩ về khối lượng. Một mũi tên chở 500 sản phẩm mỗi đêm và một mũi tên chở 200.000 lần đọc GPS mỗi ngày có thể trông y hệt nhau trên bản đồ hệ thống. Chúng không phải cùng một bài toán. Vì vậy trước khi vẽ một mũi tên nào, hãy đếm những gì di chuyển. Bắt đầu bảng kiểm kê phía sau bức tranh bằng các con số: mỗi dòng cho một tập dữ liệu quan trọng, kèm khối lượng của nó. Các chữ số 0 có thể không bao giờ xuất hiện trên mũi tên, nhưng bạn cần biết khi nào mình bước sang những con số lớn: hàng nghìn hay hàng triệu trong một giờ, hàng trăm nghìn giao dịch, thậm chí hàng chục đến hàng trăm giao dịch mỗi giây.
Những con số đó quyết định cơ chế. Vài trăm bản ghi mỗi đêm là một lô. Một lệnh gọi mà ai đó phải chờ có thể là đồng bộ, nếu khối lượng cho phép. Hàng chục đến hàng trăm mỗi giây có thể cần sự kiện, chẳng hạn platform event, thay vì một lệnh gọi cho mỗi bản ghi. Mũi tên trông vẫn vậy; khối lượng quyết định thứ gì chở nó, nên hãy ghi nó vào bảng kiểm kê, nơi cơ chế được chọn.
Cơ chế thậm chí có thể đổi hướng mũi tên. Gửi vài bản ghi mỗi phút, và Salesforce có thể đơn giản gọi ra ngoài: mũi tên bắt đầu ở Salesforce. Gửi nhiều hơn hẳn, và Salesforce có thể phát sự kiện lên event bus thay vào đó; hệ thống bên ngoài đăng ký và gọi vào để lấy chúng, nên giờ mũi tên bắt đầu ở đầu bên kia. Lớn hơn nữa, chẳng hạn đồng bộ hằng đêm hàng triệu bản ghi, thì đó là một quy trình theo lô. Vì vậy hãy biết các con số của bạn từ sớm, khi bạn bắt đầu thiết kế các cơ chế, vì các con số có thể vẽ lại mũi tên.
Khối lượng quan trọng ở hai chỗ, vì hai lý do. Trên một mô hình dữ liệu, tôi cần nó để để mắt đến khối lượng dữ liệu lớn và lên kế hoạch lưu trữ; Phần 2 đi sâu vào việc đó. Trên một bản đồ hệ thống, những con số lớn trong bảng kiểm kê quyết định việc chọn mẫu tích hợp và cơ chế. Mô-đun 6 đặt các chữ số 0 thật lên bản đồ hệ thống và bảng kiểm kê của Steve Trucking. Có các con số trong tay rồi, hãy vẽ các mũi tên.
Khi các hệ thống đã vào chỗ, hãy nối chúng lại, và bản đồ hệ thống trở thành kiến trúc. Một chiếc hộp là một hệ thống; mũi tên cho thấy ai khởi tạo kết nối. Nó bắt đầu ở hệ thống mở kết nối và trỏ đến hệ thống mà nó gọi: từ client đến server. Nhãn cho biết cái gì di chuyển, và theo chiều nào.
Quy tắc đó dành cho bản đồ hệ thống, nơi các hệ thống nói chuyện với nhau. Trên sơ đồ luồng dữ liệu, mũi tên đi theo dữ liệu, đúng như bạn nghĩ. Đừng mang quy tắc của bản đồ hệ thống sang các sơ đồ khác; nó chỉ thêm rối.
Các mũi tên được thả vào. Mọi chiếc hộp vẫn ở nguyên chỗ; mỗi mũi tên bắt đầu ở hệ thống mở kết nối, và nhãn của nó cho biết cái gì di chuyển và theo chiều nào.
Vậy nếu tầng tích hợp đẩy sản phẩm vào Salesforce, mũi tên chạy từ tầng tích hợp đến Salesforce, ghi nhãn sản phẩm vào. Nếu Salesforce gọi ra để lấy chúng, mũi tên bắt đầu ở Salesforce, vẫn ghi nhãn sản phẩm vào. Cùng dữ liệu, khác cuộc trò chuyện, và sự khác biệt đó cho tôi biết ai cần thông tin xác thực và ai phải xử lý khi thất bại. Salesforce gửi đơn hàng qua tầng tích hợp: đơn hàng ra. Kết quả thực hiện đơn của ERP quay về: trạng thái đơn hàng vào. Giờ tôi có thể thấy ai bắt đầu mỗi cuộc trò chuyện, dữ liệu vào Salesforce ở đâu và rời đi ở đâu, luồng nào vượt ranh giới, quyền sở hữu có lẽ nằm ở đâu, và tôi cần hỏi thêm ở đâu.
Và hãy nhớ mô-đun 1: bất cứ khi nào chỉ thấy một luồng, tôi bắt đầu lo ngại. Ở mức tổng quan, một mũi tên đơn hàng ra phụ thuộc vào các luồng ngược: khách hàng vào, sản phẩm vào, giá. Nhìn sâu thêm nữa thì có chiều về: chấp nhận, từ chối, trạng thái, số hóa đơn, hủy bỏ. Các mũi tên cho tôi một thứ cụ thể để chất vấn.
Đây là chỗ bản đồ hệ thống thôi là tranh vẽ PowerPoint. Tại hội đồng đánh giá, bất kỳ mũi tên nào cũng có thể kéo theo ba câu hỏi, và tôi muốn bạn có câu trả lời:
Nó xác thực thế nào? OAuth, chứng chỉ, named credential, hay thứ khác?
Nó đồng bộ hay bất đồng bộ? Salesforce có chờ ERP không, hay phát đi rồi làm tiếp? Nghiệp vụ cần kết quả nhanh đến đâu?
Cơ chế là gì? Một lệnh gọi REST, một sự kiện, một tệp, một hàng đợi thông điệp, qua MuleSoft hay trực tiếp?
Và rồi: chuyện gì xảy ra khi phía bên kia ngừng hoạt động? Mỗi mũi tên cần một cơ chế. Nếu bạn không giải thích được, đường kẻ đó chỉ là trang trí.
Và “bắn rồi quên” không phải là câu trả lời. Nó thường có nghĩa là “tôi chưa thiết kế những gì xảy ra sau khi bắn”. Nó đã đến chưa? Có được chấp nhận không? Có thất bại không? Có thử lại không? Ai biết nó bị kẹt? Nếu cùng một thông điệp đến hai lần thì sao? Không điều nào trong số đó được đưa lên bản đồ hệ thống, vì nó sẽ trở nên không đọc được. Nhưng mũi tên nên khiến bạn biết những câu hỏi đó tồn tại.
Phóng to bất kỳ mũi tên nào và bạn sẽ thấy một client và một server, mỗi bên lo một nửa của mình. Client mở kết nối: nó cần endpoint và cổng, lấy token từ máy chủ xác thực trước, gọi theo giao thức và hợp đồng mà server định nghĩa, và chọn có chờ hay không. Chỉ client thấy toàn bộ vòng đi về, nên chỉ client mới thử lại được. Server lắng nghe, định nghĩa giao thức, hợp đồng và gói dữ liệu (payload), xác thực những gì đi vào, và chỉ thấy phần của riêng nó. Khi tôi vẽ một mũi tên, tôi đã biết đầu nào là đầu nào, và điều đó cho tôi biết ai sở hữu từng câu hỏi này.
Một mũi tên, phóng to: client xử lý, server định nghĩa. Không điều nào trong số này được đưa lên bản đồ hệ thống, nhưng mũi tên nào cũng có.
Giờ hãy quay ngược mũi tên. Khi ERP gọi Salesforce, Salesforce là server: nó định nghĩa các API, chạy máy chủ ủy quyền của riêng nó, và quyết định qua một Ứng dụng khách bên ngoài và một người dùng tích hợp những gì phía gọi được phép làm. Cùng những câu hỏi, phía bên kia.
Đây là chỗ các kiến trúc sư làm hỏng một sơ đồ tốt: họ bắt một sản phẩm trả lời mọi thứ. Bản đồ hệ thống bị nhồi tên API, gói dữ liệu, cơ chế thử lại, hàng đợi lỗi, các phép chuyển đổi, mọi lệnh gọi ngược, và chẳng mấy chốc không ai đọc được nó. Đừng làm vậy. Bản đồ hệ thống là bức tranh lớn: các hệ thống và các luồng quan trọng giữa chúng.
Khi cần giải thích một tương tác, tôi vẽ một sơ đồ thứ hai, nhưng không phải cho mọi tích hợp. Nếu hệ thống A gửi gì đó đến B, hay thậm chí hỏi và nhận câu trả lời, mũi tên có ghi nhãn là đủ. Tôi muốn một làn bơi (swim lane) khi quy trình trở thành một cuộc trò chuyện: A gọi B, B kiểm tra với C, C trả lời, B tạo ra thứ gì đó và gọi lại A, một người phê duyệt, một hệ thống khác làm tiếp. Nguyên tắc kinh nghiệm của tôi: hơn một hai lần trao đổi qua lại, và trình tự đó có làn bơi riêng. Mũi tên trên bản đồ; cuộc trò chuyện trong làn bơi.
Và hãy để ý rằng ở đó một mũi tên mang nghĩa khác. Trên bản đồ hệ thống, mũi tên là một kết nối: ai mở nó, và cái gì di chuyển. Trong làn bơi, mỗi mũi tên là một thông điệp trong cuộc trò chuyện, đọc theo thứ tự: một yêu cầu đi một chiều, một phản hồi quay về chiều kia, và bước tiếp theo nối tiếp.
Ba mũi tên trên bản đồ hệ thống; sáu bước trong làn bơi. Trên bản đồ hệ thống, một mũi tên là một kết nối; trong làn bơi, mỗi mũi tên là một thông điệp, theo thứ tự.
Khi bản đồ hệ thống trông gần xong, hãy đi qua nó, từng mũi tên một. ERP đến Salesforce: cái gì đang di chuyển, ai sở hữu nó, nó xác thực thế nào, cơ chế là gì, đồng bộ hay bất đồng bộ, nó phải cập nhật đến đâu? Rồi mũi tên tiếp theo, và tiếp theo nữa. Đây là nơi các lỗ hổng xuất hiện. “Ồ, chúng ta chưa bao giờ tìm hiểu đối tác thực sự gửi cái đó thế nào.” “Chúng ta gửi đơn hàng đến ERP, nhưng chưa thiết kế cách các đơn bị từ chối quay về.” Tốt. Bạn đã tìm ra nó trên bảng trắng thay vì trên môi trường thật.
Bức tranh phải luôn đọc được, nên các chi tiết đi vào bảng kiểm kê phía sau nó. Bạn đã bắt đầu nó bằng các con số; giờ hãy hoàn thiện nó, mỗi dòng cho một tập dữ liệu hay luồng quan trọng:
Cột
Điều tôi muốn biết
Tập dữ liệu
Khách hàng, sản phẩm, đơn hàng, giao hàng, hóa đơn
Loại
Dữ liệu chủ, tham chiếu, giao dịch, phân tích, phi cấu trúc
Chủ sở hữu
Ai sở hữu ý nghĩa và vòng đời của nó?
Hệ thống gốc
Phiên bản có thẩm quyền nằm ở đâu?
Khối lượng công việc
Vận hành, phân tích, luồng
Khối lượng dữ liệu
Số chữ số 0
Org
Org Salesforce nào, nếu có nhiều org?
Xác thực
Kết nối thiết lập sự tin cậy thế nào?
Cơ chế và thời điểm
API, sự kiện, tệp, liên kết dữ liệu; đồng bộ, bất đồng bộ, theo lô
Cách tiếp cận
Sao chép, tham chiếu, hay liên kết (federate)?
Giờ có hai sản phẩm: bản đồ hệ thống cho tôi nhìn thấy kiến trúc, và bảng kiểm kê cho tôi chất vấn nó.
Đó là lý do tôi thích sản phẩm này: nó giúp tôi suy nghĩ. “Chúng ta sẽ báo cáo trên cả Salesforce và ERP thế nào?” Đó là câu hỏi từ mô-đun 3: sơ đồ nào của tôi giải quyết điều này một cách đẹp đẽ? Bản đồ hệ thống. Nếu mọi thứ đều trên lõi, báo cáo chuẩn. Nếu dữ liệu nằm trong ERP và kho dữ liệu, bạn thấy ngay. “Thuộc tính khách hàng này nên được quản lý chủ ở đâu?” Hãy xem những hệ thống nào dùng nó và hệ thống nào đã sở hữu khách hàng. “Salesforce có cần mọi lần đọc GPS không?” Ai tạo ra nó, ai tiêu thụ nó, khối lượng công việc là gì? Có thể Salesforce cần vị trí hiện tại và một nền tảng khác giữ lịch sử. Bản đồ hệ thống không trao bạn câu trả lời. Nó cho bạn đúng góc nhìn về bài toán.
Thêm một kỷ luật nữa. Trong một doanh nghiệp đang tồn tại, hãy vẽ những gì đang có, không phải những gì bạn ước có. Bảng tính gửi email mỗi thứ Sáu: vẽ nó. Tệp CSV của đối tác trên một máy chủ SFTP: vẽ nó. Tích hợp đi vòng qua ESB vì lý do lịch sử: vẽ nó. Người ta nhập lại dữ liệu giữa hai hệ thống: thể hiện nó. Đừng dọn dẹp thực tế trong khi bạn đang ghi chép nó. Bạn cần bản đồ hiện tại trước khi thiết kế bản đồ mục tiêu, và đó là điều chúng ta làm cho Steve Trucking ở mô-đun 6.
Ngoài kỳ thi: AI thay đổi điều gì. Bản đồ hệ thống đang trở thành bản đồ tác tử. Nếu một tác tử trả lời “hàng của tôi đâu rồi?”, bản đồ hệ thống phải cho biết câu trả lời đến từ Salesforce, một hệ thống đối tác, hệ thống định vị xe, ERP, hay kết hợp. Tác tử không xóa bỏ ranh giới hệ thống; chúng làm cho việc biết hệ thống nào có thẩm quyền, và cách tiếp cận nó an toàn, càng quan trọng hơn.
Những hệ thống và nhóm người dùng nào thuộc về bản đồ hệ thống, và vị trí của chúng thể hiện vai trò thế nào.
Những luồng nào vượt ranh giới hệ thống, theo hướng nào, và cái gì quay trở lại.
Mỗi kết nối xác thực thế nào, cơ chế nào mang nó, và nó đồng bộ, bất đồng bộ, theo lô hay liên kết dữ liệu.
Khi nào một mũi tên có ghi nhãn là đủ và khi nào một tương tác cần làn bơi riêng.
Bản kiểm kê phía sau bức tranh ghi lại những gì: chủ sở hữu, khối lượng công việc, khối lượng dữ liệu, org, thời điểm, xác thực, và sao chép, tham chiếu hay liên kết.
Bản đồ hệ thống không phải là thứ tôi vẽ sau khi kiến trúc đã xong. Đó là cách tôi tìm ra kiến trúc. Và khi bạn nghĩ nó đã hoàn tất, đừng ngắm nghía nó. Hãy đi qua nó. Mỗi mũi tên bạn chưa giải thích được cho bạn thấy công việc nằm ở đâu.
