Phân tích yêu cầu và Tương lai của Kiến trúc phần mềm: Cuộc trò chuyện với Sonya Natanzon

Trong một tập podcast gần đây trên InfoQ, Michael Stiefel đã có cuộc trò chuyện sâu sắc với Sonya Natanzon — một kỹ sư trưởng và kiến trúc sư phần mềm giàu kinh nghiệm. Cuộc thảo luận tập trung vào giao điểm giữa các khía cạnh kỹ thuật và xã hội của kiến trúc phần mềm, mang đến những góc nhìn thực tế về việc xây dựng hệ thống hiệu quả.

Bài viết này tóm tắt những điểm chính từ cuộc trò chuyện, bao gồm tầm quan trọng của việc hiểu biết kinh doanh, nghệ thuật phân tích yêu cầu, và tác động của AI đến tương lai của nghề lập trình.

Hiểu kinh doanh quan trọng hơn công nghệ

Một trong những nhận định đầu tiên và quan trọng nhất của Sonya Natanzon là: công nghệ thực sự không quan trọng như những người làm kỹ thuật vẫn nghĩ.

Nếu bạn tạo ra một sản phẩm mà người dùng hài lòng, dù bên trong có những "con chuột chạy trong bánh xe" để vận hành nó, người dùng cũng không quan tâm. Điều duy nhất họ cần là kết quả. Do đó, kiến trúc sư và nhà phát triển cần tập trung vào kết quả kinh doanh (business outcomes) và cách thức vận hành của công ty hơn là lo lắng quá mức về việc chọn công nghệ nào.

Sonya nhận thấy rằng, trong khi giới kinh doanh hiếm khi muốn hiểu cách phần mềm được xây dựng, thì các kỹ sư phần mềm bắt buộc phải hiểu sâu sắc về kinh doanh. Mối quan hệ này không phải là con đường hai chiều, nhưng nếu đánh giá thấp việc hiểu doanh nghiệp kiếm tiền từ đâu, làm thế nào để thu hút và giữ chân người dùng, các kiến trúc sư sẽ thất bại trong việc định hướng hệ thống.

Phân tích yêu cầu: Tuyên bố vấn đề hay Giải pháp?

Một thách thức lớn trong phát triển phần mềm là làm thế nào để khách hàng nói ra những gì họ thực sự muốn. Sonya chia sẻ rằng việc thu thập yêu cầu là một quá trình liên tục, không chỉ là một cuộc họp duy nhất.

Cô đưa ra một định nghĩa rất hay về tuyên bố vấn đề (problem statement): Nó nên chứa một trong hai điều — hoặc là một kết quả tốt đang không xảy ra, hoặc là một kết quả xấu đang xảy ra.

"Nếu tuyên bố vấn đề của bạn bắt đầu bằng cụm từ 'Chúng tôi cần (We need)', thì đó là tuyên bố giải pháp, không còn là vấn đề nữa."

Rất nhiều yêu cầu thực chất là các giải pháp ngụy trang. Ví dụ, khách hàng có thể nói "Chúng tôi cần AI" hoặc "Chúng tôi cần microservices". Sonya khuyên rằng thay vì chấp nhận ngay lập tức, hãy hỏi lại: "Kết quả hữu ích mà bạn đang cố gắng đạt được là gì?". Câu hỏi này giúp mọi người tập trung vào mục đích thực sự, mở ra không gian để xem xét các phương án tiếp cận khác nhau thay vì bị neo vào một giải pháp cụ thể từ đầu.

Giá trị của các ràng buộc (Constraints)

Nhiều người sợ ràng buộc, nhưng Sonya lại coi đó là một yếu tố tích cực. Một sân chơi hoàn toàn mở với không giới hạn sẽ rất khó làm việc vì có quá nhiều lựa chọn, dẫn đến tình trạng "bế tắc phân tích".

Ràng buộc giúp thu hẹp các lựa chọn có sẵn, từ đó làm cho việc thiết kế kiến trúc hệ thống trở nên dễ dàng hơn rất nhiều. Ví dụ, một yêu cầu về quy định rằng các thuật toán nhất định phải được cô lập hoàn toàn không được ảnh hưởng lẫn nhau là một ràng buộc. Nó giúp kiến trúc sư loại bỏ ngay các thiết kế không phù hợp và định hình con đường đi nhanh chóng.

Áp dụng DDD và Event Storming mà không cần "giáo điều"

Sonya Natanzon là người ủng hộ các phương pháp luận như Domain-Driven Design (DDD) và Event Storming. Tuy nhiên, cô nhận thấy rằng việc áp dụng chúng một cách trang trọng, cứng nhắc thường gặp phải sự kháng cự từ đội ngũ hoặc quản lý.

Thay vì bắt buộc mọi người phải đọc sách dày cộm và học thuật ngữ, cô thường áp dụng các kỹ thuật một cách tinh vi. Ví dụ, cô tổ chức các buổi workshop thực chất là Event Storming nhưng không hề nhắc đến tên gọi này. Cô chỉ đơn giản hướng dẫn: "Đây là những gì chúng ta sẽ làm và đây là cách chúng ta sẽ làm".

Kết quả là mọi người tham gia vào quá trình tư duy và thiết kế mà không cảm thấy bị áp lực bởi một "phương pháp luận mới". Điều này giúp tăng hiệu quả mà không gặp phải sự kháng cự không đáng có.

Agentic AI và tương lai của kiến trúc

AI tác nhân và Tương lai của Kiến trúc phần mềm

Khi bàn về xu hướng Agentic AI (AI tác nhân), Sonya cho rằng kiến trúc phần mềm sẽ vẫn giữ nguyên cấu trúc cơ bản trong thời gian tới, miễn là code vẫn được viết cho con người đọc và kiểm soát. Chúng ta vẫn cần định nghĩa các khái niệm, thiết lập ranh giới (boundaries) và module hóa hệ thống.

Tuy nhiên, câu hỏi lớn hơn được đặt ra là: Làm thế nào để đào tạo các lập trình viên junior (nhập môn) khi các công cụ AI đã làm hết những công việc cơ bản đó?

Sonya thừa nhận nguy cơ "mất kỹ năng" (deskilling), nhưng cô tin rằng trực giác của lập trình viên chỉ thực sự được hình thành khi mọi thứ không hoạt động đúng. Khi AI đưa ra giải pháp sai hoặc không tối ưu, lập trình viên trẻ sẽ buộc phải tìm hiểu sâu hơn để sửa chữa. Kỹ năng quan trọng trong tương lai không phải là gõ phím, mà là khả năng giải thích tại sao code được viết như vậy, và khả năng sửa chữa hệ thống khi nó bị hỏng.

Công cụ sẽ thay đổi, từ bấm thẻ đục lỗ (punch cards) sang IDE hiện đại và giờ là AI, nhưng nhu cầu về tư duy thiết kế, trực giác hệ thống và khả năng giải quyết vấn đề sẽ không bao giờ biến mất.

Kết luận

Cuộc trò chuyện với Sonya Natanzon nhắc nhở chúng ta rằng kiến trúc phần mềm không chỉ là kỹ thuật, mà còn là nghệ thuật hiểu con người và bối cảnh kinh doanh. Bằng cách chuyển trọng tâm từ giải pháp sang vấn đề, chấp nhận ràng buộc như một công cụ thiết kế, và thích nghi với các công cụ AI mới, các kiến trúc sư có thể xây dựng những hệ thống thực sự mang lại giá trị.