Kiến trúc sư dữ liệu trong thời đại AI

🌐 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 7 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: Hiểu công cụ của bạn: Chín câu hỏi · Tiếp theo: chương tiếp theo: Mô hình hóa dữ liệu vì ý nghĩa

Câu hỏi mô-đun này trả lời: AI thay đổi điều gì với kiến trúc sư dữ liệu, và không thay đổi điều gì?

AI thay đổi kiến trúc, nhưng có lẽ không theo cách người ta nghĩ đầu tiên.

Hãy nhớ chương này bắt đầu từ đâu: tôi đã dành phần lớn sự nghiệp là một người xây dựng. Phần lớn thời gian đó, xây dựng phần mềm rất tốn kém. Bạn cần những người có kỹ năng chuyên biệt, và việc viết mã, xây tích hợp, tạo ứng dụng và kiểm thử đều mất thời gian; ngay cả thử nghiệm một ý tưởng cũng là một khoản đầu tư đáng kể. AI đang thay đổi phương trình đó. Hôm nay tôi có thể mô tả điều mình muốn và để AI sinh ra một mô hình dữ liệu, Apex, một Flow, một thành phần Lightning, một tích hợp, bài kiểm thử hay tài liệu nhanh đến kinh ngạc, và ngày mai nó sẽ làm được còn nhiều hơn.

Vì vậy hỏi thế này là hợp lý: nếu AI làm được phần lớn việc xây dựng, điều gì xảy ra với kiến trúc sư? Tôi nghĩ câu trả lời là kiến trúc trở nên quan trọng hơn, chứ không kém đi.

AI là tên lửa đẩy

Tôi đã dùng phép so sánh này trong các bài nói của mình:

AI là tên lửa đẩy. Kiến trúc là hệ thống dẫn đường.

AI cho chúng ta một gia tốc phi thường. Chúng ta có thể sinh ra ứng dụng, mô hình dữ liệu, tích hợp, bài kiểm thử và tài liệu nhanh hơn bao giờ hết. Nhưng tên lửa đẩy không quyết định tên lửa bay đi đâu. Nó cung cấp lực đẩy. Hệ thống dẫn đường xác định hướng bay và điều chỉnh trên đường đi.

Không có dẫn đường vững chắc, thêm lực đẩy chẳng giúp được gì. Nó chỉ đưa bạn đến sai đích nhanh hơn. Việc của kiến trúc sư không phải là làm chậm mọi thứ; mà là đảm bảo chúng ta đang tăng tốc đúng hướng.

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

Hãy tưởng tượng một công cụ AI xây một ứng dụng nhanh gấp mười lần so với trước đây. Thật tuyệt nếu đó là ứng dụng đúng. Nhưng nếu mô hình dữ liệu sai, hay chúng ta chọn sai đối tượng chuẩn, hiểu sai nơi dữ liệu chủ thuộc về, hay thiết kế chạy được với khối lượng hôm nay nhưng sụp đổ khi thêm một chữ số 0 thì sao? AI không loại bỏ sai lầm. Nó giúp chúng ta xây sai lầm nhanh hơn, và xây thêm rất nhiều thứ lên trên trước khi có ai nhận ra.

Triển khai rẻ đi làm giá trị dịch chuyển

Khi triển khai tốn kém, sự chú ý tự nhiên đổ dồn vào triển khai: ai xây được, mất bao lâu, có làm cho nó chạy được không. Khi triển khai rẻ đi, một câu hỏi khác trở nên quan trọng hơn: chúng ta nên xây gì? Đó là một câu hỏi kiến trúc.

AI có thể sinh ra hai mươi đối tượng; kiến trúc sư dữ liệu quyết định liệu chúng ta có nên chỉ có năm. AI có thể sinh ra một tích hợp; kiến trúc sư quyết định liệu dữ liệu có nên được sao chép hay không. AI có thể tạo một trường trong vài giây; kiến trúc sư hỏi liệu nó có ý nghĩa rõ ràng, có chủ sở hữu và có lý do để tồn tại không. AI xây những gì chúng ta yêu cầu, nên chất lượng của điều chúng ta yêu cầu quan trọng hơn bao giờ hết.

Sinh ra không phải là phán đoán

AI rất giỏi sinh ra các phương án, và điều đó cực kỳ hữu ích. Tôi nhờ nó đưa ra ba cách mô hình hóa một thứ, nêu các đánh đổi, chất vấn một kiến trúc, cho tôi biết điều gì xảy ra ở mức 100 triệu bản ghi hay một thiết kế có thể hỏng ở đâu, hoặc đưa ra một phương án mà Salesforce không phải là hệ thống gốc. Tôi muốn các kiến trúc sư làm như vậy.

Nhưng sinh ra phương án và đánh giá chúng là hai việc khác nhau. AI có thể cho tôi biết Phương án A và Phương án B mỗi bên mang lại gì. Vẫn phải có ai đó hiểu việc kinh doanh đủ rõ để biết lợi thế nào quan trọng, ràng buộc nào là thật, rủi ro nào chấp nhận được, và khi nào một câu trả lời hợp lý về kỹ thuật nhưng lại sai với tổ chức này. Đó là phán đoán, và đó là kiến trúc.

Đây là cách điều đó thể hiện trong công việc của chính tôi. Trong năm qua, tôi đã thôi tự viết phần lớn mã. Tôi đưa cho AI các chi tiết và nhờ nó sinh ra màn hình và mã phía back-end, và nó làm việc đó giỏi đến kinh ngạc.

Nhưng nó không lùi lại và nhìn một cách phân tích sâu hơn. Nếu có một lỗi trong mô hình dữ liệu hay thiết kế, nó không chất vấn lỗi đó. Nó coi những gì đã có là giả định và xây tiếp lên trên, nhanh và thành thạo. Nó hiếm khi dừng lại để nói: “Trước khi thêm cái này, có lẽ nên thay đổi mô hình bạn đang có.” Nhìn vào những gì đang tồn tại và hỏi liệu nó có đúng không, chứ không chỉ hỏi liệu có xây tiếp thứ tiếp theo lên trên nó được không, vẫn là việc của kiến trúc sư. Nếu bạn muốn AI chất vấn một giả định, bạn phải yêu cầu nó làm vậy.

Phép thử khả năng đảo ngược vẫn còn nguyên giá trị

Hãy quay lại câu hỏi của mô-đun 3: đảo ngược quyết định này sẽ khó đến mức nào? AI thay đổi chi phí sinh ra và thay đổi phần mềm. Nó không thay đổi chi phí thay đổi thực tế. Khi 100 triệu bản ghi đã được tải vào, chúng tồn tại. Khi mười hai hệ thống đã phụ thuộc vào một mã định danh, những sự phụ thuộc đó tồn tại. Khi khách hàng đã dùng một quy trình, hay phân tích đã phụ thuộc vào ý nghĩa của một trường, thay đổi nó sẽ có hệ quả. Và khi dữ liệu đã bị chia sẻ đến nơi lẽ ra không được, không lượng mã mới nào có thể lấy nó lại.

Không thể đảo ngược vẫn là không thể đảo ngược.

Tác tử là một loại bên tiêu thụ dữ liệu mới

Chúng ta từng thiết kế dữ liệu cho hai loại bên tiêu thụ: con người và phần mềm. Một người đọc một bản ghi; một báo cáo, một tích hợp hay một ứng dụng đọc dữ liệu. Giờ có loại thứ ba: tác tử (agent). Một tác tử có thể truy xuất dữ liệu, diễn giải nó, kết hợp nó với thông tin khác, quyết định và hành động, đôi khi không có con người nào ở giữa.

Điều đó nâng cao mức độ rủi ro. Một trường có ý nghĩa gì, ai sở hữu nó, nó mới và đáng tin đến đâu, nó có nhạy cảm không, một tác tử có thể và có nên thấy nó không, điều gì xảy ra khi hai nguồn không khớp: những điều này từng là tài liệu. Giờ chúng là cách một hệ thống thông minh hiểu việc kinh doanh.

Và dữ liệu tệ không trở nên thông minh hơn chỉ vì AI đọc nó. Rác vào thì rác ra vẫn đúng. Khách hàng trùng lặp, quyền sở hữu không rõ ràng, mã định danh thiếu nhất quán và các hệ thống gốc mâu thuẫn không biến mất khi bạn kết nối một tác tử; hệ quả của chúng chỉ lộ rõ hơn. Một người nhìn một trường và biết đã ba năm không ai cập nhật nó. Tác tử không có hiểu biết ngầm đó của tổ chức, và nó có thể tự tin hành động dựa trên dữ liệu mà mọi người khác đều lặng lẽ biết là không nên tin. Kiến trúc dữ liệu trở thành một phần của kiến trúc AI.

Hãy coi chừng lược đồ phình to

AI cũng làm cho việc tạo ra mọi thứ trở nên dễ đến khó tin. Cần thêm một đối tượng, thêm sáu trường, thêm một tự động hóa? Sinh ra là xong. Mỗi quyết định có vẻ rẻ, nhưng hãy nhớ lực hấp dẫn kiến trúc ở mô-đun 3: những đối tượng và trường đó tích tụ các sự phụ thuộc (tự động hóa, tích hợp, báo cáo, tác tử), và chẳng mấy chốc bạn có một mô hình dữ liệu không ai thiết kế. Nó chỉ tự mọc lên.

Kiến trúc sư phải sẵn sàng hỏi: “Chúng ta có thực sự cần cái này không?” Đôi khi quyết định giá trị nhất là không tạo ra thứ gì cả. Kiến trúc tốt liên quan đến những gì bạn bỏ ra ngoài nhiều như những gì bạn đưa vào.

Xem xét của con người không phải là nghi thức

Khi tôi nói một kiến trúc sư con người nên xem xét mô hình dữ liệu do AI sinh ra, tôi không có ý “AI tạo ra nó, và Steve nhìn sơ đồ năm phút rồi phê duyệt”. Đó không phải là giám sát. Kiến trúc sư phải hiểu mô hình: tại sao là những đối tượng này, tại sao là những quan hệ này, những phương án nào đã được cân nhắc, khóa và dữ liệu chủ nằm ở đâu, điều gì xảy ra khi khối lượng tăng, hệ quả về truy cập là gì, và những đánh đổi nào đã được thực hiện. Nếu tôi không trả lời được những câu đó, tôi không sở hữu kiến trúc; tôi chỉ đóng dấu cho qua. AI có thể đóng góp vào một kiến trúc, chất vấn nó và ghi tài liệu cho nó, nhưng kiến trúc sư con người phải có khả năng bảo vệ nó.

Với các dữ kiện cũng vậy. Tôi dùng AI liên tục để học và nghiên cứu, và quy tắc của tôi là tin nhưng phải kiểm chứng. Hãy đặt câu hỏi, đòi lời giải thích, các phương án thay thế và một lời phản biện cho chính câu trả lời của nó. Rồi với bất cứ điều gì quan trọng với kiến trúc của bạn, hãy lần theo liên kết, đọc tài liệu, kiểm tra giới hạn, xác nhận giấy phép và kiểm thử hành vi. AI có thể rất thuyết phục khi nó sai, và phân biệt dữ kiện với giả định giờ là một phần còn lớn hơn của công việc.

AI không rút ngắn hành trình

Có một câu tôi hay dùng khi nói về việc trở thành kiến trúc sư:

AI không rút ngắn hành trình. Nó có thể làm cho mỗi bước đi đáng giá hơn.

Bạn vẫn cần hiểu dữ liệu, bảo mật, tích hợp, nền tảng và việc kinh doanh, và bạn vẫn cần kinh nghiệm đưa ra quyết định và sống với hệ quả của nó. AI có thể đẩy nhanh việc học của bạn, cho bạn thấy những tình huống bạn chưa gặp, giải thích mọi thứ, chất vấn bạn, giúp bạn xây dựng và làm đôi mắt thứ hai. Hãy dùng tất cả. Chỉ đừng nhầm một AI biết câu trả lời với việc chính bạn hiểu câu trả lời.

Kiến trúc sư dẫn dắt

Chúng ta bắt đầu chương này với người cầm bản thiết kế. AI cho người đó những công cụ mới phi thường: một trợ lý có thể vẽ từng phần bản thiết kế, nghiên cứu vật liệu, đề xuất phương án, tính toán tải trọng, viết tài liệu và thậm chí phát hiện những vấn đề bạn bỏ sót. Hãy dùng nó. Nhưng vẫn phải có ai đó hiểu toàn bộ tòa nhà, hỏi liệu đó có phải là tòa nhà đúng không, biết điều gì xảy ra khi yêu cầu thay đổi và những quyết định nào sẽ tốn kém để hoàn tác, và chịu trách nhiệm về kết quả.

Đó là lý do cấp độ cuối cùng của khóa học này có tên Direct (dẫn dắt). Bạn có thể không viết từng dòng mã, không tạo từng Flow hay xây từng đối tượng. Vẫn phải có ai đó dẫn dắt giải pháp, và đó là kiến trúc sư. AI không loại bỏ kiến trúc; nó thay đổi nơi kiến trúc sư tạo ra giá trị. Đây là một thời điểm phi thường để trở thành kiến trúc sư.

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

• Nên xây gì, khi việc xây dựng đã trở nên rẻ: những đối tượng, trường và tích hợp nào xứng đáng có chỗ.
• Những phương án do AI sinh ra nào phù hợp với việc kinh doanh này, và những phương án nào nghe hợp lý nhưng lại sai.
• Những quyết định nào AI đang lướt qua mà sẽ tốn kém để đảo ngược.
• Tác tử có thể đọc và hành động dựa trên những gì, và dữ liệu có đủ tốt và được mô tả đủ rõ để chúng làm vậy không.
• Những dữ kiện nào từ AI cần được kiểm chứng trước khi chúng định hình thiết kế.

Đó là tư duy như một kiến trúc sư trong thời đại AI.