Các trường hợp thay đổi kiến trúc: Công cụ thiết thực cho kiến trúc phần mềm tiến hóa

Các trường hợp thay đổi kiến trúc: Công cụ thiết thực cho kiến trúc phần mềm tiến hóa

Một mục tiêu quan trọng của kiến trúc phần mềm là cải thiện khả năng bảo trì của hệ thống trong suốt vòng đời của nó. Tuy nhiên, nỗ lực này thường mang tính suy đoán cao vì nó xem xét các sự kiện vốn dĩ không chắc chắn. Rất dễ để bỏ qua tác động của những thay đổi trong tương lai bằng câu hỏi: "Thay đổi cái này có khó đến mức nào nếu chúng ta cần?", nhưng kinh nghiệm thực tế cho thấy tư duy này thường dẫn đến những hậu quả nghiêm trọng về sau.

Để tập trung hóa sự suy đoán này và giảm thời gian đội ngũ dành cho các cuộc thảo luận "nếu như" vô tận, chúng ta có thể sử dụng một công cụ gọi là Trường hợp thay đổi kiến trúc (Architectural Change Case). Nó giống như một quả cầu thủy tinh giúp bạn lý luận về các kết quả có thể xảy ra từ các quyết định kiến trúc của mình.

Kiến trúc phần mềm

Trường hợp thay đổi kiến trúc là gì?

Một trường hợp thay đổi kiến trúc xác định một thay đổi tiềm ẩn đối với các giả định của giải pháp có thể ảnh hưởng đáng kể đến kiến trúc phần mềm. Khác với Bản ghi quyết định kiến trúc (ADR) - vốn ghi lại các quyết định đã qua và các sự đánh đổi, trường hợp thay đổi kiến trúc không định nghĩa giải pháp thay thế cụ thể; mục đích của nó là làm rõ khả năng thay đổi trong tương lai và phác thảo các phương án thay thế.

Mục tiêu cuối cùng là đánh giá độ bền bền của kiến trúc phần mềm. Một trường hợp thay đổi kiến trúc có thể bao gồm các thông tin sau:

• Một thay đổi tiềm ẩn trong yêu cầu thuộc tính chất lượng (QAR) hoặc trong tình huống kinh doanh.
• Xác suất xảy ra thay đổi.
• Danh sách các quyết định sẽ cần thay đổi vì các giả định của chúng bị vi phạm.
• Các phương án tiềm năng để giải quyết vấn đề.
• Dự báo chi phí thay đổi, tức là chi phí để đảo ngược quyết định (có thể ước lượng theo cấp độ "kích thước áo thun": S, M, L, XL...).

Dự báo sự suy giảm của hệ thống

Trong thực tế, nhiều quyết định kiến trúc phần mềm dường như giả định rằng mọi thứ sẽ không thay đổi hoặc thay đổi có thể bị ngăn chặn. Cả hai giả định này đều không thực tế. Sự thay đổi là không thể tránh khỏi trong công nghệ hệ thống sử dụng, kỹ năng của người bảo trì, và quan trọng nhất là bối cảnh kinh doanh.

Các trường hợp thay đổi kiến trúc giúp các đội ngũ sử dụng các phương pháp như kiến trúc liên tục và kiến trúc tiến hóa để diễn đạt các thay đổi tiềm năng. Điều này có thể bao gồm thay đổi mô hình AI (ví dụ: concept drift), cấu hình môi trường, phiên bản khung làm việc (framework), các mối đe dọa bảo mật, băng thông, v.v.

Áp dụng thực tế: Ví dụ về bảo hiểm

Hãy xem xét trường hợp của một công ty bảo hiểm lớn thành lập công ty con để cạnh tranh bằng cách cung cấp sản phẩm đổi mới. Họ muốn cung cấp bảo hiểm cho người thuê nhà nghỉ theo yêu cầu, một loại bảo hiểm linh hoạt có thể bật/tắt qua ứng dụng di động.

Ban quản lý giả định rằng việc tái sử dụng các ứng dụng định giá bảo hiểm, kế toán và khiếu nại từ công ty mẹ sẽ giảm chi phí. Họ chọn sử dụng tác nhân lập trình AI để nhanh chóng đưa ra Sản phẩm khả dụng tối thiểu (MVP).

Các trường hợp thay đổi tiềm năng của họ bao gồm việc đánh giá thấp mức độ chấp nhận MVP. Số lượng người dùng thực tế có thể cao hơn 50% so với ước tính, dẫn đến các vấn đề về khả năng mở rộng và hiệu suất. Kiến trúc khả dụng tối thiểu (MVA) sẽ cần được cập nhật nhanh chóng.

Hoặc nếu các bên liên quan kinh doanh muốn mở rộng sang khách hàng thuê xe du lịch (RV) và thuyền? Hệ thống định giá của công ty mẹ có thể không xử lý được các lớp rủi ro này.

Bảng thông tin trường hợp thay đổi

Bảng trên tóm tắt thông tin trường hợp thay đổi mà đội ngũ đã thu thập. Các trường hợp này ngụ ý rằng đội ngũ có thể không còn khả năng tái sử dụng hệ thống định giá từ công ty mẹ.

Khi nào nên xác định Trường hợp thay đổi kiến trúc?

Các đội ngũ nên cân nhắc tạo ra các trường hợp thay đổi kiến trúc khi:

• Nhập một phụ thuộc lớn.
• Áp dụng mã do AI tạo ra.
• Mã hóa cứng các quy tắc kinh doanh.
• Tối ưu hóa để giao tiếp MVP nhanh chóng.
• Phụ thuộc vào các nền tảng bên ngoài.
• Chấp nhận các sự đánh đổi về khả năng mở rộng hoặc khả năng bảo trì.

Các trường hợp thay đổi có giá trị nhất khi việc đảo ngược quyết định sau này có thể trở nên tốn kém hoặc rủi ro về mặt vận hành.

Tác động của AI và Trường hợp thay đổi kiến trúc

Với sự quan tâm lớn đến việc sử dụng tác nhân lập trình AI để tạo ra ít nhất một phần của MVP, việc xem xét tác động tiềm năng của nó đối với các thay đổi trong tương lai là rất quan trọng. Hầu hết việc sử dụng tác nhân AI để tạo mã đều mang rủi ro rằng công ty AI có thể phá sản hoặc bị đối thủ mua lại. Một rủi ro khác là mô hình AI có thể thay đổi đáng kể, khiến mã được tạo ra không thể tái tạo trong tương lai.

Để giảm thiểu rủi ro này, một chiến lược hiệu quả là tạo và duy trì một kho lưu trữ các hiện vật (artifacts) được sử dụng để cung cấp ngữ cảnh cho trợ lý AI, bao gồm yêu cầu, thông số kỹ thuật, tài liệu thiết kế, các quyết định kiến trúc trước đây, đoạn mã và bài kiểm tra chấp nhận.

Các đội ngũ làm việc với Trợ lý lập trình AI nên cân nhắc xác định các trường hợp thay đổi dự đoán việc thay thế một phần hệ thống bằng mã do AI tạo ra, hoặc việc tạo MVP mới với một AI khác.

Đánh giá thực nghiệm

Chỉ xác định các trường hợp thay đổi kiến trúc là chưa đủ. Thách thức là thực sự hiểu được độ lớn (chi phí) của vấn đề. Sử dụng các thí nghiệm kiến trúc giúp cung cấp dữ liệu cho các ước tính mà không cần xây dựng toàn bộ giải pháp thay thế.

Các hàm thích nghi (fitness functions) có thể được sử dụng để đánh giá hiệu quả của thay đổi. Hàm thích nghi cung cấp một thiết bị đo lường để thiết lập đường cơ sở cho một QAR bị ảnh hưởng bởi trường hợp thay đổi và kiểm tra xem thí nghiệm có thành công hay không.

Kết luận

Sẽ rất dễ dàng để giả định rằng kiến trúc phần mềm là một thứ tĩnh tại, một khi đã xác định thì nó sẽ không thay đổi theo thời gian. Nếu điều đó tồn tại, chúng tôi chưa bao giờ thấy nó. Tất cả các kiến trúc đều thay đổi. Câu hỏi là liệu sự thay đổi đó là có chủ đích hay ngẫu nhiên. Các trường hợp thay đổi kiến trúc giúp một đội ngũ suy nghĩ kỹ lưỡng hơn về các quyết định kiến trúc của họ.

Kiến trúc của một hệ thống phần mềm thực sự không bao giờ kết thúc vì thế giới xung quanh nó luôn thay đổi. Việc sử dụng các tác nhân lập trình AI làm trầm trọng thêm vấn đề này bằng cách đưa ra những thay đổi thường vô hình. Để chống lại các áp lực thay đổi này, các đội ngũ cần cân nhắc việc tạo ra các kiến trúc liên tục dự đoán và giảm thiểu sự thay đổi.