Phân tích kiến trúc phần mềm và ATAM

1. Tổng quan

A. Định nghĩa và bối cảnh ra đời của phân tích kiến trúc phần mềm

Phân tích kiến trúc phần mềm (Software Architecture Analysis) là hoạt động đánh giá trước khi hiện thực hóa xem cấu trúc (kiến trúc) của hệ thống có thỏa mãn các thuộc tính chất lượng được yêu cầu (hiệu năng, bảo mật, tính sẵn sàng, khả năng sửa đổi, v.v.) hay không, đồng thời xác định rủi ro, điểm đánh đổi và điểm cải tiến. Kỹ thuật đánh giá tiêu biểu là ATAM (Architecture Trade-off Analysis Method) do SEI (Viện Kỹ thuật Phần mềm thuộc Đại học Carnegie Mellon) xây dựng.

Lý do căn bản cần phân tích kiến trúc nằm ở chỗ 'khiếm khuyết kiến trúc là thứ tốn kém nhất khi sửa về sau'. Kiến trúc là bộ khung của hệ thống; một khi đã xác định, mọi thiết kế chi tiết và hiện thực hóa sau đó đều được xây trên nó. Vì vậy, các quyết định sai ở giai đoạn kiến trúc (ví dụ cấu trúc monolithic đơn khối không tính tới khả năng mở rộng, liên kết giữa các dịch vụ chỉ bằng lời gọi đồng bộ) càng khó sửa khi phát triển tiến triển, và sau khi hoàn thành sẽ kéo theo chi phí khổng lồ là thiết kế lại toàn bộ. Việc chi phí sửa lỗi phần mềm tăng theo cấp số nhân khi giai đoạn phát triển càng về sau là quy luật kinh nghiệm đã được quan sát từ lâu, và các báo cáo liên tục chỉ ra rằng vấn đề có thể bắt được ở giai đoạn yêu cầu, thiết kế nếu đến giai đoạn vận hành mới bắt thì tốn chi phí gấp hàng chục lần. Khiếm khuyết kiến trúc là đối tượng cần được bắt ở phía ngoài cùng bên trái của đường cong này, tức điểm có thể sửa rẻ nhất.

Ngoài ra, kiến trúc là điểm xung đột của nhiều thuộc tính chất lượng. Đưa cache, phi chuẩn hóa vào để tăng hiệu năng thì tính nhất quán dữ liệu và chi phí kiểm chứng bảo mật xấu đi; tăng tầng trừu tượng để tăng tính linh hoạt thì hiệu năng và mức dễ hiểu giảm — các đánh đổi (trade-off) như vậy tiềm ẩn khắp nơi. Xung đột này không lộ ra ở một dòng mã mà phát sinh từ tương tác của toàn bộ cấu trúc, nên dù viết từng thành phần tốt đến đâu, nếu cấu trúc sai thì chất lượng hệ thống vẫn sụp đổ. Phân tích kiến trúc phần mềm chính là đánh giá những quyết định mang tính cấu trúc này trước khi hiện thực hóa. Nó làm rõ các thuộc tính chất lượng mà bên liên quan yêu cầu, và xem xét có hệ thống liệu kiến trúc có đáp ứng chúng không, ẩn chứa những đánh đổi và rủi ro nào. Nhờ đó ngăn ngừa việc làm lại tốn kém ở giai đoạn sau, và đưa ra quyết định kiến trúc có căn cứ thay vì dựa trên cảm tính.

Bối cảnh khiến phân tích kiến trúc được phương pháp luận hóa một cách chính thức là kinh nghiệm thất bại của các hệ thống lớn vào cuối thập niên 1990. Khi ngày càng nhiều hệ thống dù hiện thực đủ chức năng nhưng bị loại bỏ vì không đáp ứng yêu cầu phi chức năng (thuộc tính chất lượng) như hiệu năng, khả năng mở rộng, khả năng bảo trì, nhận thức rằng phải kiểm chứng trước "xây dựng với chất lượng nào (cấu trúc)" ngang với "xây dựng cái gì (chức năng)" ngày càng lớn. Nhóm kỹ thuật đánh giá dựa trên kịch bản như ATAM, SAAM, CBAM xuất hiện trong thời kỳ này.

B. Phân tích xuôi và phân tích ngược

Phân tích kiến trúc được chia thành xuôi và ngược tùy theo 'tiếp cận cấu trúc từ hướng nào'. Phân tích xuôi là phương thức rút ra và đánh giá kiến trúc từ yêu cầu và thiết kế khi chưa có mã (hoặc chưa được xác định), dùng ở giai đoạn thiết kế hệ thống mới. Phân tích ngược là phương thức trích xuất, khôi phục kiến trúc thực tế từ hệ thống kế thừa (legacy) đang chạy nhưng không có tài liệu hoặc đã lỗi thời để tìm điểm cải tiến.

Phân tích xuôi tập trung xem kiến trúc của hệ thống mới có phản ánh tốt yêu cầu không, còn phân tích ngược tập trung rút ra kiến trúc thực sự được hiện thực từ hệ thống sẵn có để tìm độ vênh so với ý đồ thiết kế (xói mòn kiến trúc, architectural erosion). Trong thực tế, hai loại này tuần hoàn. Phân tích ngược legacy để nắm cấu trúc hiện tại, trên đó thiết kế lại kiến trúc mục tiêu theo chiều xuôi, rồi lại kiểm chứng kết quả di chuyển bằng phân tích ngược. Ví dụ, trong dự án chuyển monolithic sang microservice, trước hết dùng phân tích ngược để vẽ ra phụ thuộc thực tế giữa các miền, rồi dựa trên ranh giới đó thiết kế việc tách dịch vụ (xuôi).

2. ATAM (Architecture Trade-off Analysis Method)

ATAM là phương pháp dựa trên kịch bản phân tích đánh đổi giữa nhiều thuộc tính chất lượng để đánh giá cùng với các bên liên quan mức độ kiến trúc thỏa mãn yêu cầu chất lượng và có những rủi ro nào. Điểm cốt lõi là xem xét đồng thời ảnh hưởng qua lại giữa nhiều chất lượng chứ không chỉ một chất lượng cụ thể.

ATAM nhìn chung tiến hành theo luồng 'chuẩn bị → đánh giá → tổng hợp': xác nhận động lực kinh doanh, nhận trình bày kiến trúc, cấu trúc hóa yêu cầu chất lượng thành cây tiện ích, rồi thử nghiệm kiến trúc bằng các kịch bản cụ thể để rút ra rủi ro và đánh đổi. Dưới đây là sơ đồ khái niệm thể hiện toàn bộ luồng đó.

flowchart LR
  B["Động lực kinh doanh·<br/>trình bày kiến trúc"] --> U["Cây tiện ích<br/>thuộc tính chất lượng"] --> S["Phân tích<br/>kịch bản"] --> R["Rút ra rủi ro·<br/>đánh đổi"]
  R --> P["Cải tiến·đánh giá lại<br/>(lặp lại)"]
  style R fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

A. Cây tiện ích — cấu trúc hóa yêu cầu chất lượng

Điểm xuất phát của ATAM là biến yêu cầu mơ hồ "hiệu năng phải tốt" thành kịch bản chất lượng có thể đo lường. Để làm vậy, xây dựng cây tiện ích (Utility Tree) lấy thuộc tính chất lượng làm gốc và phân nhánh xuống các mối quan tâm con. Ví dụ, dưới gốc 'tiện ích' đặt các nhánh 'hiệu năng·tính sẵn sàng·bảo mật·khả năng sửa đổi', dưới 'hiệu năng' lại đặt các lá 'thời gian phản hồi·thông lượng', và gắn vào mỗi lá kịch bản cụ thể kèm độ ưu tiên (mức quan trọng, độ khó). Dưới đây là sơ đồ khái niệm thể hiện cấu trúc chi tiết đó.

flowchart TD
  U["Tiện ích (Utility)"] --> P["Hiệu năng"]
  U --> A["Tính sẵn sàng"]
  U --> SEC["Bảo mật"]
  U --> M["Khả năng sửa đổi"]
  P --> P1["Thời gian phản hồi: p95 trong 3 giây khi tải gấp 2 (Cao,Cao)"]
  P --> P2["Thông lượng: duy trì 1000 TPS mỗi giây (Cao,Trung bình)"]
  A --> A1["Tính sẵn sàng 99.99% (Cao,Cao)"]
  SEC --> S1["Lưu trữ mã hóa thông tin thanh toán (Cao,Trung bình)"]
  M --> M1["Thêm phương thức thanh toán mới trong 2 tuần (Trung bình,Trung bình)"]
  style U fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Mỗi lá được gắn kịch bản thuộc tính chất lượng cụ thể. Kịch bản gồm tác nhân kích thích (stimulus), môi trường, phản hồi, thước đo phản hồi, chẳng hạn viết như "dù số người dùng đồng thời vào giờ cao điểm tăng gấp 2 lần bình thường (kích thích·môi trường), vẫn duy trì phản hồi truy vấn trong vòng 3 giây theo phân vị 95 (phản hồi·thước đo)". Như vậy yêu cầu chủ quan "nhanh" trở thành mục tiêu có thể kiểm chứng. Tiếp đó, mỗi kịch bản được đánh giá (mức quan trọng kinh doanh, độ khó đạt được về mặt kiến trúc) ở mức cao/trung bình/thấp để xếp ưu tiên. Kịch bản có cả hai đều 'cao', tức vừa quan trọng với kinh doanh vừa khó đạt được về cấu trúc, trở thành đối tượng phân tích tập trung. Nếu không có việc ưu tiên hóa này, đánh giá trở nên tản mạn và trong buổi workshop eo hẹp thời gian sẽ bỏ lỡ chính những kịch bản quan trọng.

B. Phân tích kịch bản và bốn sản phẩm đầu ra

Chọn các kịch bản có độ ưu tiên cao, lần lượt xem xét cách tiếp cận kiến trúc (pattern·tactic) mà kiến trúc đã chọn để thỏa mãn kịch bản đó. Làm lộ rõ quyết định và căn cứ như "dùng dự phòng active-standby cho tính sẵn sàng 99.99%", "đặt máy chủ phi trạng thái sau load balancer để mở rộng", rồi xem xét tác động lan tỏa của quyết định đó tới các chất lượng khác. Phân tích này tạo ra bốn sản phẩm sau.

Ở đây, điểm nhạy cảm là điểm đòn bẩy "thay đổi giá trị này thì chất lượng thay đổi lớn", và khi đòn bẩy đó tác động đồng thời lên nhiều chất lượng theo hướng ngược nhau thì trở thành điểm đánh đổi. Điểm đánh đổi chính là điểm cốt lõi cần ra quyết định nên là sản phẩm được ATAM chú ý nhất. Ví dụ, nâng mức dự phòng dữ liệu thì tính sẵn sàng tăng nhưng độ trễ ghi và chi phí cũng tăng — tại điểm này các bên liên quan phải thống nhất tường minh "chấp nhận bao nhiêu ms độ trễ và chi phí để có tính sẵn sàng bao nhiêu %". Rủi ro và phi rủi ro sau đó được gom rủi ro thành chủ đề rủi ro (risk theme), gắn với động lực kinh doanh và chuyển thành nhiệm vụ bổ sung.

C. Các giai đoạn tiến hành ATAM và hai lần tham gia của bên liên quan

ATAM thường được chia thành hai pha (phase). Pha 1 là phiên quy mô nhỏ tập trung vào kiến trúc sư và người ra quyết định chủ chốt: giới thiệu phương pháp ATAM, trình bày động lực kinh doanh và kiến trúc, xác định cách tiếp cận kiến trúc, lập cây tiện ích và phân tích sơ bộ các kịch bản ưu tiên cao. Pha 2 có nhóm bên liên quan rộng hơn tham gia, khai thác và bỏ phiếu kịch bản mới bằng brainstorming, bổ sung cây tiện ích, rồi phân tích lại kiến trúc bằng các kịch bản mở rộng và trình bày tổng hợp kết quả (chủ đề rủi ro, đánh đổi).

Việc chia sự tham gia của bên liên quan thành hai lần có lý do thực tiễn. Nếu ở pha 1 kiến trúc sư dựng sẵn bộ khung của cây tiện ích, thì ở pha 2 khi nhiều bên liên quan tham gia, thảo luận không bị lạc hướng mà hội tụ nhanh trên khung đã cấu trúc hóa. Ngược lại, ở pha 2 nhiều góc nhìn như nghiệp vụ, vận hành, bảo mật tham gia và kéo ra những kịch bản mà kiến trúc sư bỏ sót (ví dụ "khi sự cố trong lúc vận hành không người trực ban đêm có tự động khôi phục không"), lấp điểm mù của việc đánh giá bị giới hạn trong tầm nhìn của số ít người. Tức là thiết kế sắp xếp 'cấu trúc hóa' và 'đa dạng' theo trình tự thời gian để có được cả hai.

Trong phân tích mỗi kịch bản, quy trình vi mô cách tiếp cận kiến trúc → câu hỏi thuộc tính chất lượng → xác định điểm nhạy cảm·đánh đổi·rủi ro được lặp lại. Ví dụ, với cách tiếp cận "máy chủ phi trạng thái + load balancer", đặt câu hỏi "trạng thái phiên đặt ở đâu, khi tăng máy chủ có bảo đảm mở rộng tuyến tính không", và từ câu trả lời rút ra rằng 'kho phiên là điểm nhạy cảm của khả năng mở rộng', xa hơn là đánh đổi 'tập trung hóa kho phiên thì khả năng mở rộng↑·rủi ro điểm lỗi đơn (SPOF)↑'. Quy trình vi mô này tích lũy theo từng kịch bản và được tổng hợp thành chủ đề rủi ro cuối cùng.

3. Quan hệ và so sánh với các kỹ thuật đánh giá khác

ATAM là kỹ thuật tiêu biểu đánh giá tổng hợp nhiều thuộc tính chất lượng nhưng không phải phương pháp duy nhất. Kỹ thuật dựa trên kịch bản thời kỳ đầu SAAM (Software Architecture Analysis Method) là dạng đơn giản chủ yếu đánh giá khả năng sửa đổi bằng kịch bản, còn ATAM mở rộng nó bằng cách bổ sung phân tích đánh đổi giữa nhiều chất lượng. CBAM (Cost-Benefit Analysis Method) bổ sung trục chi phí–lợi ích (tính kinh tế) vào các chiến lược kiến trúc mà ATAM rút ra, giúp xác định ưu tiên đầu tư dựa trên căn cứ "tiện ích kỳ vọng so với chi phí bỏ ra cho cải tiến này là bao nhiêu".

Sự khác biệt giữa ba kỹ thuật không chỉ là liệt kê chức năng mà phát sinh từ việc câu hỏi mà đánh giá muốn trả lời khác nhau. SAAM hỏi "cấu trúc này có dễ thay đổi không", ATAM hỏi "đồng thời thỏa mãn nhiều yêu cầu chất lượng thì phải nhượng bộ điều gì", CBAM hỏi "sự nhượng bộ và cải tiến đó có đáng bỏ tiền không". Trong thực tế, thường liên kết sử dụng: dùng ATAM làm lộ đánh đổi và rủi ro, rồi dùng CBAM đánh giá tính kinh tế của phương án cải tiến. Ví dụ, nếu ở một hệ thống thanh toán ATAM kết luận "đường phê duyệt thanh toán đồng bộ là điểm đánh đổi giữa hiệu năng và tính sẵn sàng", thì CBAM tính "tiện ích tránh tổn thất khi sự cố so với chi phí phát triển, vận hành để chuyển sang dựa trên bất đồng bộ, hàng đợi" để quyết định có đầu tư hay không.

4. Chuyên sâu — Đánh giá kiến trúc gọn nhẹ và áp dụng thực tế trong thời đại Agile·DevOps

ATAM truyền thống lấy tiền đề là workshop nặng nề với hàng chục bên liên quan kéo dài hai ngày. Tuy nhiên, ngày nay khi phát triển lặp và triển khai liên tục đã thành thường nhật, kiến trúc tiến hóa theo từng sprint nên không thể mỗi lần đều mở workshop quy mô lớn. Vì vậy, xu hướng gọn nhẹ hóa ý tưởng cốt lõi của ATAM (rút ra kịch bản, đánh đổi, rủi ro) để áp dụng lặp lại đã được định hình.

Thứ nhất, bố trí workshop thuộc tính chất lượng (QAW) hoặc mini ATAM tại ranh giới sprint để nhanh chóng chỉ đánh giá các kịch bản mới bổ sung. Thứ hai, ghi lại quyết định kiến trúc bằng ADR (Architecture Decision Record), tư liệu hóa ngữ cảnh, phương án thay thế, đánh đổi, hệ quả của từng quyết định. ADR ghi lại "quyết định này được đưa ra vì chất lượng nào, nhượng bộ điều gì", nên nối tiếp tự nhiên với phân tích đánh đổi của ATAM. Thứ ba, tự động kiểm chứng kịch bản chất lượng bằng hàm thích nghi (fitness function). Trong kiến trúc tiến hóa (evolutionary architecture), các mục tiêu chất lượng như "độ kết dính không vượt ngưỡng", "phản hồi p95 trong vòng 300ms" được đo thường xuyên bằng kiểm thử và giám sát, và khi kiến trúc lệch khỏi mục tiêu thì pipeline cảnh báo. Có thể xem đây là việc đưa đánh giá chất lượng vốn chỉ làm bằng workshop của con người vào CI/CD để thường trực hóa.

Về trường hợp thực tế, các tổ chức vận hành microservice quy mô lớn tiếp nối tinh thần ATAM bằng cách định nghĩa kịch bản chất lượng (SLO tính sẵn sàng, ngân sách độ trễ) cho từng dịch vụ, đo thường xuyên bằng công cụ quan sát, và chỉ mở rà soát kiến trúc tập trung cho những dịch vụ thường xuyên vi phạm SLO. Ngoài ra, trong các miền coi trọng tính an toàn như công và tài chính, vẫn dùng workshop ATAM chính thức để đánh giá chính thức rủi ro kiến trúc trước khi xây dựng hệ thống lớn và làm căn cứ cho kiểm toán giám sát. Tức là lựa chọn, song hành giữa 'ATAM chính thức' và 'đánh giá gọn nhẹ·tự động' tùy mức rủi ro của miền là gần với chuẩn thực tiễn hiện nay.

5. Lưu ý và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

1. Sự tham gia của bên liên quan quyết định thành bại. ATAM không phải công việc riêng của kiến trúc sư mà là nơi nhiều bên liên quan như kinh doanh, vận hành, bảo mật, người dùng cùng thống nhất yêu cầu chất lượng và ưu tiên. Nếu tham gia sơ sài, ưu tiên của cây tiện ích bị méo mó và bỏ lỡ chính những đánh đổi quan trọng. Do đó, ở giai đoạn thiết kế workshop phải đầu tư công sức vào xác định bên liên quan chủ chốt và chuẩn bị trước (tổng hợp động lực kinh doanh).

2. Quản lý tường minh đánh đổi là giá trị cốt lõi. Không thể đồng thời đưa mọi chất lượng lên mức cao nhất. Phải tư liệu hóa kèm căn cứ (ADR) việc ưu tiên chất lượng nào và nhượng bộ điều gì để bảo đảm tính minh bạch và khả năng truy vết của quyết định. Các đánh đổi được ghi lại như vậy trở thành tài sản của tổ chức giải thích "tại sao lại làm như vậy" khi thay người hay thiết kế lại về sau.

3. Áp dụng sớm và lặp lại để tối thiểu hóa chi phí làm lại. Đánh giá càng sớm ở giai đoạn quyết định kiến trúc thì chi phí sửa khiếm khuyết càng thấp. Trong môi trường Agile, cần có hệ thống đánh giá gọn nhẹ, lặp lại kiến trúc đang tiến hóa (mini ATAM, hàm thích nghi) để hiệu chỉnh thường xuyên trước khi xói mòn kiến trúc và nợ kỹ thuật vượt ngưỡng.

4. Thường trực hóa đánh giá bằng đo lường định lượng và tự động hóa. Nếu định nghĩa kịch bản chất lượng bằng SLO, hàm thích nghi và kết nối với khả năng quan sát, CI, thì đánh giá vốn chỉ dựa vào phán đoán của con người có thể được thực hiện thường xuyên dựa trên dữ liệu. Điều này nâng cao tính khách quan, tính lặp lại của đánh giá và cho phép can thiệp nhanh khi phát sinh vi phạm.

5. Kết nối kết quả đánh giá với thực thi là quan trọng. Dù ATAM rút ra rủi ro và đánh đổi, nếu chúng không được chuyển thành backlog, nhiệm vụ cải tiến và thực sự được sửa thì chỉ còn lại trên giấy. Phải kết nối chủ đề rủi ro đã rút ra với lộ trình cải tiến và ngân sách (liên kết CBAM) để bảo đảm tính thực thi thì phân tích kiến trúc mới dẫn tới nâng cao chất lượng của tổ chức.

Tài liệu tham khảo

• SEI Carnegie Mellon, "Architecture Tradeoff Analysis Method (ATAM)": https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
• SEI, "Evaluating Software Architectures: Methods and Case Studies" tổng quan: https://insights.sei.cmu.edu/library/
• Neal Ford et al., Evolutionary Architecture / khái niệm fitness functions: https://www.thoughtworks.com/insights/articles/fitness-function-driven-development
• ADR (Architecture Decision Records) tổng quan: https://adr.github.io/

Tóm tắt một câu: Phân tích kiến trúc phần mềm là hoạt động đánh giá trước khi hiện thực hóa xem cấu trúc có thỏa mãn yêu cầu thuộc tính chất lượng hay không; ATAM cấu trúc hóa kịch bản chất lượng bằng cây tiện ích và dùng phân tích kịch bản để rút ra điểm nhạy cảm, điểm đánh đổi, rủi ro, phi rủi ro nhằm ngăn ngừa việc làm lại tốn kém về sau, trong đó sự tham gia của bên liên quan, quản lý tường minh đánh đổi và áp dụng sớm, lặp lại quyết định thành bại.