Kiến trúc là nghệ thuật đánh đổi

🌐 Cũng có bằng 28 ngôn ngữ khác

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

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 4 trong 7 của chương Tư duy như một kiến trúc sư dữ liệu, chương đầu tiên của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Phép thử khả năng đảo ngược · Tiếp theo: Xây cho hôm nay. Lên kế hoạch cho ngày mai. Lên kế hoạch cho thất bại.

Câu hỏi mô-đun này trả lời: Khi có nhiều giải pháp có thể hiệu quả, kiến trúc sư chọn thế nào và giải thích lựa chọn ra sao?

Nếu kiến trúc chỉ đơn giản là tìm ra đáp án đúng, mọi thứ sẽ dễ hơn nhiều. Học nền tảng, học các mẫu, học các giới hạn, chọn cái đúng, xong.

Kiến trúc thực tế không vận hành như vậy. Những quyết định khó thường không nằm giữa một giải pháp rõ ràng là tốt và một giải pháp rõ ràng là tệ. Chúng nằm giữa nhiều giải pháp đều có thể hiệu quả, mỗi giải pháp có ưu và nhược điểm, mỗi giải pháp đẩy kiến trúc đi theo một hướng hơi khác nhau. Đó là nơi kiến trúc sư chứng minh vị trí của mình bên bàn họp.

Nhiều cách để giải quyết vấn đề

Tôi đã dùng một biến thể của ví dụ này nhiều lần khi dạy kiến trúc sư.

Có thể có nhiều cách để giải một vấn đề trong Salesforce. Đôi khi tôi gán cho nó một con số, chẳng hạn mười, nhưng đó là một phép ẩn dụ, không phải con số đếm được. Nhiều phương án có vấn đề ngay từ đầu: chúng vướng một ràng buộc của nền tảng, bỏ sót một yêu cầu then chốt, hoặc tạo ra vấn đề bảo mật hay hiệu năng mà chúng ta không thể chấp nhận. Chúng ta có thể gạt những phương án đó sang một bên khá nhanh. Một số khác chạy được hôm nay nhưng sẽ có vấn đề khi dữ liệu tăng lên. Về mặt kỹ thuật chúng vẫn hoạt động, nhưng sẽ không trụ được trước mức tăng trưởng mà chúng ta đã biết trước là sẽ đến.

Những gì còn lại là một số ít phương án có thể đáp ứng nhu cầu của bạn về sau, và lúc này mới thú vị. Mỗi phương án đều có thể chạy, mở rộng và đáp ứng các yêu cầu. Vậy cái nào đúng? Có thể tất cả. Công việc của kiến trúc sư là hiểu sự khác biệt.

Ngay cả thứ đơn giản như một danh sách chọn cũng chạy được hôm nay và có thể gặp vấn đề khi dữ liệu tăng lên. Danh sách chọn dễ dùng với người dùng. Nhưng hãy hỏi các giá trị đến từ đâu, và có thể có bao nhiêu giá trị. Danh sách chọn hoạt động tốt nhất với khoảng dưới 20 giá trị. Thỉnh thoảng chúng ta lên đến 50, như các bang của Mỹ, và hiếm khi vượt quá 100, như danh sách quốc gia, và chúng trở nên cồng kềnh. Vì vậy với mỗi danh sách chọn, hãy biết giới hạn trên. Và thay đổi giá trị của danh sách chọn là thay đổi siêu dữ liệu, không phải thay đổi dữ liệu.

Nếu dùng quan hệ tra cứu thay vào đó, giao diện người dùng phức tạp hơn một chút. Nhưng danh sách có thể tiếp tục tăng mà không có giới hạn trên, và giá trị mới có thể đến từ một tích hợp. Đó là một đánh đổi với tính dễ dùng. Đó là sự cân bằng.

Click to enlarge

Tối ưu không có nghĩa là hoàn hảo

Tôi dùng từ tối ưu một cách cẩn thận. Một kiến trúc tối ưu không phải là kiến trúc mà mọi quyết định riêng lẻ đều hoàn hảo; kiến trúc như vậy có lẽ không tồn tại. Đó là kiến trúc mà giải pháp tổng thể được cân bằng.

Giả sử Giải pháp A cho hiệu năng tốt nhất nhưng đắt và khó bảo trì. Giải pháp B rẻ hơn, dễ vận hành hơn nhưng hy sinh một phần hiệu năng. Giải pháp C linh hoạt hơn cho tương lai nhưng thêm độ phức tạp ngay hôm nay. Cái nào tối ưu? Chỉ từ những dữ kiện đó, tôi không trả lời được. Tôi cần biết việc kinh doanh, các yêu cầu và các ưu tiên, và ràng buộc nào là thật, ràng buộc nào chỉ là sở thích. Kiến trúc phụ thuộc vào bối cảnh. Đó là lý do một mẫu đúng cho khách hàng này có thể hoàn toàn sai cho khách hàng tiếp theo.

Và công việc của bạn với tư cách Data Architect là cân bằng những quyết định này. Bạn sẽ tự mình hoặc cùng nhóm đưa ra hàng chục quyết định như vậy. Hãy biết đó là những quyết định nào, và biết khi nào một quyết định có tác động lớn hơn, về chi phí, thời gian hay chức năng, và cần được đưa lên những người ra quyết định chủ chốt.

Một quyết định chưa tối ưu có thể là một phần của một kiến trúc tối ưu

Đây là một trong những ý tưởng quan trọng nhất của chương này. Đôi khi tôi cố ý đưa ra một quyết định chưa tối ưu ở một phần của kiến trúc vì nó làm cho toàn bộ giải pháp tốt hơn.

Có thể tôi sao chép một lượng nhỏ dữ liệu, vì loại bỏ sự trùng lặp đó sẽ tạo ra độ phức tạp tích hợp không cần thiết. Có thể tôi chọn một mô hình dữ liệu đơn giản hơn, vì mô hình gọn gàng hơn về lý thuyết sẽ làm cho báo cáo và việc sử dụng hằng ngày khó hơn nhiều. Có thể tôi chấp nhận tốn một chút hiệu năng, vì phương án kia thêm hạ tầng mà tổ chức chưa sẵn sàng vận hành.

Nhìn riêng lẻ bất kỳ quyết định nào trong số đó, bạn sẽ nói nó chưa tối ưu. Đúng. Nhưng kiến trúc không phải là tối ưu từng thành phần riêng lẻ; mà là tối ưu hệ thống. Một quyết định chưa tối ưu ở cục bộ có thể là một phần của một kiến trúc tối ưu ở tổng thể, miễn là chúng ta hiểu sự đánh đổi mình đang thực hiện. Điều nguy hiểm là thực hiện đánh đổi mà không biết mình đang làm vậy.

Hãy biết mình đang đánh đổi điều gì

Mỗi khi ai đó nói với tôi “đây là giải pháp tốt nhất”, câu hỏi tiếp theo của tôi là “tốt nhất về mặt nào?” Nhanh nhất? Rẻ nhất? Đơn giản nhất? Dễ mở rộng nhất, an toàn nhất, linh hoạt nhất? Dễ vận hành nhất, giao nhanh nhất, ít phụ thuộc vào kỹ năng chuyên biệt nhất? Gần như luôn có một chiều khác mà ở đó câu trả lời không phải là “tốt nhất”. Đó là sự đánh đổi. Tôi muốn biết chúng ta được gì, và tôi cũng muốn biết chúng ta từ bỏ gì.

Hãy lấy hai phương án cho một tập dữ liệu doanh nghiệp lớn. Một phương án sao chép dữ liệu vào Salesforce, giúp dùng các khả năng gốc của Salesforce dễ hơn, nhưng giờ chúng ta chịu trách nhiệm di chuyển nó, lưu trữ nó, đồng bộ nó, bảo mật thêm một bản sao và xử lý độ trễ. Phương án kia để dữ liệu ở nguyên chỗ và truy cập khi cần. Chúng ta đã bỏ được một phần trùng lặp, nhưng giờ tính sẵn sàng, hiệu năng truy vấn, sự phụ thuộc mạng và khả năng của hệ thống từ xa trở nên quan trọng hơn. Không mô tả nào cho chúng ta biết nên chọn cái nào. Chúng cho chúng ta biết cần đặt những câu hỏi nào.

Các yêu cầu không ngang nhau

Đánh đổi cũng buộc chúng ta nhận ra rằng không phải yêu cầu nào cũng có cùng trọng lượng.

Ai đó nói: “Dữ liệu cần có ngay lập tức.” Được thôi, ngay lập tức là bao lâu? Một giây, mười giây, một phút? Và tại sao? Có thể đó là phát hiện gian lận, nơi từng giây đều quan trọng. Có thể chỉ là ai đó không thích chờ lần tải dữ liệu ban đêm. Đó là những yêu cầu rất khác nhau, và kiến trúc sư tiếp tục hỏi cho đến khi biết chúng ta có yêu cầu nào.

Tôi thích những yêu cầu chịu được chất vấn: bao nhiêu, mấy cái, nhanh đến đâu, thường xuyên thế nào, cho ai, và điều gì xảy ra nếu không làm? “Nhanh” không phải là một yêu cầu kiến trúc. “95 phần trăm cập nhật của khách hàng phải đến được với nhân viên dịch vụ trong vòng 30 giây” thì gần với một yêu cầu kiến trúc hơn nhiều. Giờ chúng ta có thể đánh giá các đánh đổi.

Ràng buộc làm thay đổi câu trả lời

Đôi khi kiến trúc hoàn toàn không bị công nghệ ràng buộc. Nó bị ràng buộc bởi tiền bạc, con người, thời gian, giấy phép hay độ trưởng thành của tổ chức.

Một kiến trúc xuất sắc về kỹ thuật nhưng cần một đội vận hành mà công ty không có thì không phải là một kiến trúc tốt. Một khả năng giải quyết vấn đề một cách thanh lịch nhưng cần giấy phép mà khách hàng sẽ không mua thì cũng không phải là giải pháp. Và một cuộc chuyển đổi ba năm hoàn hảo chẳng giúp được gì cho một công ty phải ra mắt trong tám tuần.

Không điều nào trong số đó có nghĩa là chúng ta từ bỏ kiến trúc tốt vì một hạn chót. Nó có nghĩa là chúng ta hiểu mình đang thỏa hiệp điều gì, tại sao, chấp nhận những hệ quả nào, và lý tưởng nhất là chúng ta sẽ đi từ thỏa hiệp hôm nay đến kiến trúc của ngày mai bằng cách nào.

Kiến trúc sư cần một hình ảnh về “tối ưu”

Có một sự căng thẳng thú vị ở đây. Tôi nói với bạn rằng thường không có một đáp án hoàn hảo duy nhất, đồng thời tôi cũng muốn bạn mang trong đầu một hình ảnh về giải pháp tối ưu trông như thế nào. Hai điều đó không mâu thuẫn. Bạn cần một điểm tham chiếu.

Khi nhìn một mô hình dữ liệu, tôi muốn biết mình sẽ xây gì nếu có thể tối ưu cho các yêu cầu mà không có ràng buộc không cần thiết. Rồi khi các ràng buộc thực tế đẩy chúng ta rời xa thiết kế đó (chúng ta làm phẳng một phần mô hình, sao chép một ít dữ liệu, hoãn một tích hợp, chấp nhận một quy trình thủ công tạm thời), tôi không thỏa hiệp một cách ngẫu nhiên. Tôi biết mình đang rời xa tối ưu theo hướng nào, và tại sao. Đó là nghệ thuật của kiến trúc, và trực giác ấy cần luyện tập.

Hãy vẽ nó ra

Một trong những cách tốt nhất để hiểu một đánh đổi là vẽ nó ra. Sơ đồ kiến trúc không phải là đồ trang trí cho một bộ slide; chúng là công cụ tư duy. Nếu đang chọn giữa hai cách làm, hãy vẽ cả hai. Dữ liệu nằm ở đâu, và di chuyển đến đâu? Cái gì sở hữu nó? Ranh giới ở đâu, và bảo mật được thực thi ở đâu? Điều gì xảy ra khi có sự cố, và điều gì thay đổi khi khối lượng tăng?

Một sơ đồ buộc sự mơ hồ lộ ra, và nó cho mọi người cùng một bức tranh để chỉ vào.

Tôi nhận ra điều đó quan trọng đến mức nào trong một dự án với một công ty tiện ích. Hết buổi đánh giá này đến buổi khác, tôi thấy mình giải thích lại cùng những khái niệm và kéo cuộc thảo luận về thiết kế ban đầu. Vì vậy tôi thay đổi cách điều hành các cuộc họp đó: mỗi buổi đánh giá đều bắt đầu bằng mô hình dữ liệu trên màn hình. Không phải mô hình chi tiết với mọi trường. Một mô hình tóm tắt: một tài khoản có các liên hệ, bản ghi này có các bản ghi con, công việc treo ở đây. Phòng họp chủ yếu là lãnh đạo, và việc đó chỉ mất vài phút.

Vì vẫn là những người đó họp hết lần này đến lần khác, sơ đồ trở thành ngôn ngữ chung của chúng tôi. Mọi người bắt đầu dùng các tên gọi trong đó. Những câu hỏi lặp lại thưa dần, và các cuộc họp trở nên dễ dàng hơn nhiều. Tôi gọi đó là neo cuộc họp: một sơ đồ đơn giản, được chiếu mỗi lần, đáng giá hơn rất nhiều so với công sức để làm ra nó.

Mục tiêu không phải là sự hoàn hảo nghệ thuật. Đôi khi đó là một sơ đồ chi tiết cho kỹ sư, đôi khi là năm cái hộp và sáu mũi tên cho một lãnh đạo. Mục tiêu là sự rõ ràng.

Giải thích sự đánh đổi

Một kiến trúc sư giỏi trình bày theo thứ tự: đây là các phương án chúng ta đã cân nhắc, đây là những gì mỗi phương án mang lại, đây là cái giá của mỗi phương án, đây là phương án tôi đề xuất, và đây là lý do.

Hãy để ý rằng đề xuất đến sau các đánh đổi. Tôi không muốn kiến trúc trở thành “tôi đã làm việc này rồi, cứ tin tôi”. Kinh nghiệm cực kỳ quan trọng; nó giúp bạn nhận ra các mẫu nhanh hơn và thấy vấn đề sớm hơn. Nhưng kinh nghiệm của bạn nên cải thiện lập luận của bạn, chứ không thay thế nó. Công việc của chúng ta không chỉ là hiểu kiến trúc. Mà là giúp tổ chức hiểu quyết định, đặc biệt khi những người đưa ra quyết định cuối cùng không phải là kiến trúc sư.

Think Correct. Think Fast.

Không phải lúc nào bạn cũng có ba tuần để phân tích mọi phương án. Đôi khi bạn chỉ có ba phút. Một yêu cầu thay đổi ngay trong cuộc họp, ai đó nêu ra một ràng buộc bạn chưa biết, hoặc một lãnh đạo hỏi: “Nếu năm sau chúng ta cần cái này ở châu Âu thì sao?”

Tôi đã dùng câu Think Correct. Think Fast. (Nghĩ đúng. Nghĩ nhanh.) Tốc độ không đến từ việc bỏ qua suy nghĩ. Nó đến từ việc đã suy nghĩ đủ trước khi khoảnh khắc đó đến: bạn đã học các mẫu, bạn hiểu nền tảng, bạn đã thấy những thất bại, bạn biết cần hỏi câu nào và quyết định nào khó đảo ngược. Đó là lý do chúng ta làm việc với các tình huống xuyên suốt khóa học này. Bạn càng phân tích nhiều quyết định, bạn càng nhận ra hình dạng của quyết định tiếp theo nhanh hơn.

Tôi từng có một khách hàng cần nhập liệu qua biểu mẫu. Nhưng có rất nhiều biểu mẫu, và các câu hỏi có thể thay đổi theo thời gian. Tôi nhanh chóng nhận ra nhu cầu về một mô hình dữ liệu khảo sát, một mẫu chúng ta sẽ quay lại ở phần sau của khóa học. Vì nhận ra mẫu và giải pháp, tôi đã có thể đưa vào một mô hình dữ liệu hoàn chỉnh hơn, một mô hình xử lý được cả những yêu cầu sắp đến, chứ không chỉ những yêu cầu đang ở trước mắt.

Kiến trúc là về sự cân bằng

Khi đi sâu hơn vào kiến trúc dữ liệu, bạn sẽ gặp những lựa chọn mà tôi cố tránh đưa cho bạn một quy tắc đơn giản. Chuẩn hóa hay làm phẳng? Sao chép dữ liệu hay liên kết (federate) nó? Đồng bộ hay bất đồng bộ? Đối tượng chuẩn hay tùy chỉnh? Lưu trữ lâu dài hay giữ trực tuyến?

Có những nguyên tắc, mẫu và giới hạn, và đôi khi có những đáp án rõ ràng là sai. Nhưng thường thì công việc của kiến trúc sư là tìm ra sự cân bằng phù hợp cho hệ thống này, doanh nghiệp này và thời điểm này.

Hãy biết tối ưu trông như thế nào. Hiểu các ràng buộc. Xác định các phương án khả thi. Làm cho các đánh đổi hiện rõ. Rồi đưa ra quyết định.

Đó không phải là thiếu quyết đoán. Đó là kiến trúc.

Kiến trúc sư quyết định gì ở đây

• Phương án nào khả thi, phương án nào sai ngay bây giờ hoặc sẽ hỏng trong một năm.
• Mỗi phương án khả thi được gì và mất gì, đo theo những yêu cầu chịu được chất vấn.
• Ràng buộc nào là thật, ràng buộc nào chỉ là sở thích.
• Đề xuất phương án nào, sau khi đã trình bày các đánh đổi, và giải thích nó ra sao.