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 trong những mục tiêu chính 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 Cases).

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ăng đố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 đã được đưa ra và các sự đánh đổi - trường hợp thay đổi kiến trúc tập trung vào việc đánh giá cách các quyết định đó có thể phát triển trong tương lai.

Mục tiêu của nó không phải là định nghĩa giải pháp thay thế, mà là làm rõ khả năng xảy ra thay đổi và phác thảo các phương án thay thế. Cách tiếp cận này hỗ trợ lập kế hoạch dự phòng và khuyến khích sự linh hoạt trong thiết kế để giảm thiểu tác động của sự thay đổi.

Một trường hợp thay đổi kiến trúc thường bao gồm các thông tin sau:

• Một thay đổi tiềm năng trong yêu cầu thuộc tính chất lượng (QAR) hoặc trong tình huống kinh doanh.
• Khả năng xảy ra thay đổi (xác suất).
• 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, được ước tính theo thứ tự độ lớn (ví dụ: kích thước áo thun S, M, L, XL).

Bảng thông tin tóm tắt các trường hợp thay đổi kiến trúc

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

Nhiều quyết định kiến trúc phần mềm trong thực tế 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 những người bảo trì nó, và quan trọng nhất là trong bối cảnh kinh doanh mà hệ thống hoạt động.

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ề công ty 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 một công ty con để cạnh tranh bằng cách cung cấp các sản phẩm đổi mới. Họ muốn ban đầu 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 hoặc 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 bảo hiểm, kế toán và khiếu nại từ công ty mẹ sẽ giảm chi phí và thời gian đưa ra thị trường. Họ chọn sử dụng một 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 của MVP. Số lượng người dùng thực tế có thể cao hơn 50% so với ước tính cao nhất, 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 để xử lý khối lượng lớn hơn.

Ngoài ra, nếu các bên liên quan kinh doanh muốn mở rộng đối tượng khách hàng sang người thuê xe RV (xe giải trí) hoặc thuyền, hệ thống bảo hiểm của công ty mẹ có thể không đủ khả năng xử lý các lớp rủi ro này. Những trường hợp thay đổi này buộc đội ngũ phải xem xét lại việc tái sử dụng hệ thống cũ.

Các lớp trường hợp thay đổi kiến trúc

Mặc dù ví dụ trên tập trung chủ yếu vào các thay đổi chức năng, nhưng có các lớp trường hợp thay đổi kiến trúc khác mà các đội ngũ cần xem xét:

• Thay đổi giao diện hệ thống bên ngoài yêu cầu hệ thống của bạn phải thay đổi đồng thời.
• Thay thế một hệ thống con lớn do nhu cầu thay đổi, sự hợp nhất nhà cung cấp hoặc dự án mã nguồn mở bị hủy bỏ.
• Thay đổi cơ sở hạ tầng, bao gồm việc chuyển tài nguyên tính toán sang trung tâm dữ liệu khác hoặc lên đám mây.
• Thay đổi đáng kể trong mô hình kinh doanh, bao gồm việc MVP không thành công hoặc thay đổi thị trường làm vô hiệu hóa các giả định kinh doanh.
• Thay đổi trong lỗ hổng bảo mật của hệ thống do các yếu tố bên ngoài.

Tác động của AI và các tác nhân lập trình

Với sự quan tâm ngày càng tăng trong việc sử dụng các 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.

Minh họa tư duy về kiến trúc và thay đổi

Để 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 các 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 đó, dữ liệu, thông số kỹ thuật giao diện, đoạn mã và bài kiểm tra chấp nhận. Kho lưu trữ này có thể được duy trì bằng các công cụ hiện có như GitHub.

Các đội ngũ làm việc với Trợ lý lập trình AI nên cân nhắc định nghĩa các trường hợp thay đổi dự đoán:

• Thay thế một phần của hệ thống hiện có bằng mã do tác nhân AI tạo ra.
• Tạo một MVP mới với một AI khác hoặc phiên bản mới hơn của AI đã chọn.
• Thay đổi trong một hệ thống bên ngoài mà mã do AI tạo ra cần giao tiếp.

Đánh giá thực nghiệm thay vì phỏng đoán

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 (tức là chi phí) của vấn đề. Sử dụng các thí nghiệm giúp cung cấp dữ liệu cho các ước tính mà không cần phải xây dựng toàn bộ giải pháp thay thế.

Các hàm fitness (fitness functions) có thể được sử dụng để đánh giá hiệu quả của sự thay đổi. Chúng 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 trong việc cung cấp các cải tiến mong đợi hay không mà không ảnh hưởng tiêu cực đến các phần còn lại của hệ thố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, một khi đã xác định thì nó sẽ không thay đổi theo thời gian. Nếu thứ đó tồn tại, chúng ta 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ọ, nơi mà chúng đại diện cho sự thay đổi.

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.