Tư duy như một kiến trúc sư

🌐 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 1 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: tổng quan chương · Tiếp theo: Mô hình dữ liệu là bộ xương

Câu hỏi mô-đun này trả lời: Xây dựng và thiết kế kiến trúc khác nhau thế nào, và một kiến trúc sư thực sự làm gì?

Phần lớn sự nghiệp của tôi, tôi là một người xây dựng.

Tôi khởi đầu là một lập trình viên. Tôi làm việc với Java và .NET trước khi chuyển sang Salesforce, và tôi đã dành nhiều năm thiết kế hệ thống, viết mã, tích hợp các nền tảng, dạy kiến trúc sư và đánh giá kiến trúc.

Nhưng một trong những bài học quan trọng nhất tôi học được trên đường đi là trở thành một người xây dựng giỏi và trở thành một kiến trúc sư giỏi không phải lúc nào cũng là một.

Người xây dựng hỏi:

Làm sao để xây cái này?

Kiến trúc sư phải đặt ra một loạt câu hỏi khác:

Có nên xây cái này không?

Tại sao chúng ta xây theo cách này?

Có những phương án nào khác?

Điều gì xảy ra khi nó lớn hơn?

Điều gì xảy ra khi nó thất bại?

Và quyết định nào hôm nay mà ba năm nữa chúng ta sẽ ước gì mình đã suy nghĩ kỹ hơn?

Tôi nhớ có lần làm dự án cho một doanh nghiệp bán lẻ có lịch hẹn. Tôi hỏi: mỗi cửa hàng có bao nhiêu lịch hẹn một ngày? Rồi: các bạn có bao nhiêu cửa hàng? Và mở cửa mấy ngày một tuần? Rất nhanh, tôi nhận ra chỉ riêng năm đầu tiên chúng tôi sẽ có hàng triệu lịch hẹn. Đó là những câu hỏi một kiến trúc sư đặt ra khi bắt đầu dự án.

Sự thay đổi trong tư duy đó mới là điều khóa học này thực sự hướng tới.

Click to enlarge

Người cầm bản thiết kế

Tôi đã dùng phép so sánh này nhiều lần khi dạy kiến trúc sư.

Hãy tưởng tượng một công trường. Có người đổ bê tông, người đi dây điện, người lắp đường ống, người dựng khung tường và hàng chục công việc chuyên môn khác. Họ cần rất giỏi việc của mình.

Nhưng cũng cần có ai đó cầm bản thiết kế.

Người đó cần hiểu tất cả các phần ấy khớp với nhau thế nào. Họ cần nhận ra khi một việc xảy ra ở một phần của dự án tạo ra vấn đề ở chỗ khác.

Đó là kiến trúc.

Trong công nghệ, đôi khi chúng ta lầm tưởng kiến trúc sư đơn giản là người biết nhiều nhất. Thực ra không phải vậy. Hiểu nền tảng là quan trọng. Bạn cần chiều sâu kỹ thuật. Nhưng kiến trúc không phải là một cuộc thi đố vui.

Công việc của kiến trúc sư là đưa ra quyết định tốt, đôi khi với thông tin chưa đầy đủ và những yêu cầu mâu thuẫn nhau, và hiểu hệ quả của những quyết định đó.

Đó là một kỹ năng rất khác.

Đừng chỉ nhận yêu cầu

Một trong những thói quen đầu tiên tôi muốn kiến trúc sư rèn luyện rất đơn giản:

Hãy hỏi tại sao.

Ai đó nói với bạn:

Chúng tôi cần thêm một đối tượng.

Tại sao?

Chúng tôi cần sao chép trường này sang Tài khoản.

Tại sao?

Chúng tôi cần lưu tất cả dữ liệu này trong Salesforce.

Tại sao?

Điều đó không có nghĩa là gây khó dễ. Nó có nghĩa là hiểu yêu cầu nghiệp vụ thực sự thay vì triển khai ngay giải pháp được đề xuất.

Một yêu cầu thường đến dưới vỏ bọc của một thiết kế.

“Chúng tôi cần một đối tượng tùy chỉnh mới” chưa chắc đã là một yêu cầu. Yêu cầu thực sự có thể là “chúng tôi cần theo dõi thông tin này riêng biệt”. Hai điều đó không giống nhau.

Khi đã hiểu yêu cầu thực sự, bạn có thể bắt đầu khám phá các phương án. Có thể một đối tượng mới chính là câu trả lời đúng. Có thể thông tin đó thuộc về một nơi đã có sẵn. Có thể Salesforce hoàn toàn không nên sở hữu dữ liệu đó.

Kiến trúc sư phải tách điều nghiệp vụ cần khỏi một cách được đề xuất để đáp ứng nó.

Chúng tôi từng làm một ứng dụng bán hàng, và khách hàng có nhiều cấp phê duyệt, mỗi cấp có một người phê duyệt và một ngày. Yêu cầu đầu tiên của họ là thêm Approver 2 và Approver 3, mỗi người kèm một ngày, làm các trường trên Cơ hội. Khi đào sâu hơn, chúng tôi nhận ra có thể có nhiều hơn hai hay ba lần phê duyệt. Vì vậy chúng tôi chuyển các lần phê duyệt sang một đối tượng con. Lời đề nghị là thêm trường; yêu cầu thực sự là theo dõi mọi lần phê duyệt, dù cuối cùng có bao nhiêu lần đi nữa.

Nghĩ vượt ra ngoài yêu cầu

Hai thói quen nảy sinh từ việc hỏi tại sao, và mỗi thói quen có một mô-đun riêng ở phần sau của chương này.

Thường có nhiều hơn một câu trả lời. Salesforce cho chúng ta rất nhiều cách để giải một vấn đề, và một số cách sai gần như ngay lập tức. Chọn giữa những cách hiệu quả là nghệ thuật đánh đổi (mô-đun 4).

Và những yêu cầu bạn nhận được chưa phải là tất cả yêu cầu bạn có. Không ai nói “hãy đảm bảo cái này vẫn chạy khi lần tải dữ liệu ban đêm chỉ thành công một nửa”, nhưng đó vẫn là một yêu cầu. Tôi nhìn mọi thiết kế qua ba lăng kính: 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 (mô-đun 5).

Hãy nghĩ về một người thuê kiến trúc sư thiết kế một tòa nhà. Họ không đòi chuông báo cháy hay hệ thống phun nước, cũng không đòi tòa nhà phải đứng vững khi động đất. Họ mặc định đó là một phần công việc, không cần nói ra. Thế giới của chúng ta cũng vậy. Không ai đòi xử lý lỗi một cách êm ái, đòi nhật ký, hay đòi cách phục hồi khi có sự cố. Kiến trúc sư phải biết hệ thống nào trong số đó thuộc về thiết kế và đưa chúng vào.

Click to enlarge

Làm cho lập luận của bạn trở nên rõ ràng

Kiến trúc sư không nên chỉ bước vào phòng và tuyên bố: “Chúng ta sẽ làm thế này.”

Công việc của bạn còn là giải thích tại sao. Tôi muốn các bên liên quan hiểu những phương án chúng ta đã cân nhắc và những đánh đổi đi kèm. Điều đó không có nghĩa là đưa cho một lãnh đạo tài liệu thiết kế 40 trang. Nó có nghĩa là có thể giải thích cùng một kiến trúc cho một lập trình viên, cho phía nghiệp vụ và cho một lãnh đạo: những cuộc trò chuyện khác nhau về cùng một quyết định.

Và cách để làm điều đó là bằng những bản thiết kế và hướng dẫn rõ ràng, như người cầm bản thiết kế trên công trường. Với một Data Architect, một trong những bản thiết kế quan trọng nhất là mô hình dữ liệu.

Nếu không ai hiểu tại sao một quyết định được đưa ra, rất có khả năng cuối cùng sẽ có người hoàn tác nó. Và họ có thể có lý do hoàn toàn hợp lý để làm vậy, vì chưa ai từng giải thích quyết định ban đầu.

Kiến trúc sư không cần tự tay xây mọi thứ

Có một bước chuyển khác cũng có thể khó khăn, đặc biệt với những người đến với kiến trúc từ con đường lập trình.

Bạn không phải tự tay xây mọi thứ.

Tôi vẫn thích hiểu mọi thứ vận hành thế nào ở mức rất kỹ thuật, và nền tảng đó quan trọng. Nhưng là kiến trúc sư, trách nhiệm của bạn lớn hơn phần việc bạn tự triển khai. Bạn không phải tự xây mọi thứ; bạn cần biết cách đưa cho những người xây đúng định hướng và đúng các tham số. Nghĩa là hiểu đủ để dẫn dắt công việc của họ, để nhận ra khi một cách triển khai được đề xuất gây ra vấn đề kiến trúc, và để di chuyển qua lại giữa chi tiết và bức tranh lớn.

Đôi khi điều đó có nghĩa là đi sâu vào một truy vấn, một API hay một mô hình dữ liệu.

Đôi khi nó có nghĩa là lùi lại và hỏi liệu ngay từ đầu chúng ta có nên làm bất kỳ điều gì trong đó không.

Và ngày càng nhiều, thứ đang xây không chỉ là con người. Với AI, kiến trúc sư có thể làm việc trực tiếp với công cụ tạo ra các đối tượng, mã và màn hình. Khi đó định hướng, các tham số và các nguyên tắc được đưa cho AI, và việc đưa chúng cho tốt ngày càng trở thành trách nhiệm của kiến trúc sư. Chúng ta sẽ quay lại chuyện này ở mô-đun 7.

Đó là một phần của hành trình từ người xây dựng đến kiến trúc sư.

Công việc của bạn là đưa ra quyết định

Rốt cuộc, kiến trúc là về các quyết định.

Một số quyết định dễ thay đổi. Một số khác thì không.

Bố cục trang có thể thay đổi. Một nhãn có thể đổi tên.

Nhưng nếu chọn sai mô hình dữ liệu nền tảng, công bố những mã định danh mà hàng chục hệ thống bắt đầu phụ thuộc vào, hay đặt bản gốc của dữ liệu quan trọng sai chỗ, thì việc đổi ý sẽ tốn kém hơn rất nhiều.

Đó là những quyết định kiến trúc. Và đó chính là loại quyết định khóa học này tập trung vào.

Là một Data Architect, bạn sẽ quyết định thông tin được cấu trúc thế nào, nằm ở đâu, tăng trưởng ra sao, di chuyển thế nào, ai có thể truy cập nó và phần còn lại của doanh nghiệp hiểu nó thế nào.

Công nghệ có quan trọng.

Nhưng biết mọi tính năng của Salesforce không phải là mục tiêu.

Mục tiêu là phát triển óc phán đoán để biết dùng công cụ nào, dùng khi nào, bạn đang đánh đổi điều gì, và điều gì xảy ra tiếp theo.

Đó là tư duy như một kiến trúc sư.

Và giờ chúng ta có thể bắt đầu tư duy như một Data Architect.

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

• Một đề nghị là yêu cầu thực sự, hay chỉ là một thiết kế được đề xuất cho yêu cầu đó.
• Cần hỏi những câu nào trước khi xây bất cứ thứ gì: có nên không, tại sao theo cách này, còn làm được gì khác, điều gì xảy ra khi nó lớn lên hoặc thất bại.
• Quyết định nào thuộc về kiến trúc sư, quyết định nào thuộc về những người xây dựng; và cần đưa định hướng, tham số gì cho những người xây, dù là con người hay AI.
• Cách giải thích một quyết định để một lập trình viên, phía nghiệp vụ và một lãnh đạo đều hiểu.