title: "Kiến trúc sư trong môi trường Agile: Làm sao để kiến trúc không trở thành "vua chúa" nhưng vẫn giữ được định hướng"
series: "Software Architecture Masterclass"
part: "Phần 1 — Nguyên lý & Triết lý Kiến trúc"
order: 7
audience: "Solutions Architect & Technical Lead"
reading_time: "13 phút"
tags: ["agile-architecture", "emergent-design", "technical-leadership", "governance", "sprint-planning", "architectural-runway"]

Kiến trúc sư trong môi trường Agile: Làm sao để kiến trúc không trở thành "vua chúa" nhưng vẫn giữ được định hướng

Một kiến trúc sư ngồi vẽ sequence diagram, ERD, và class diagram cho toàn bộ hệ thống trong sáu tuần trước khi đội dev viết dòng code đầu tiên. Ba tháng sau, sản phẩm ra thị trường trễ, và tệ hơn — một nửa thiết kế đã lỗi thời vì yêu cầu nghiệp vụ thay đổi ngay ở sprint thứ ba. Đội dev âm thầm bỏ qua bản thiết kế, tự chế ra giải pháp riêng để kịp deadline. Kiến trúc sư trở thành người vẽ tranh trong tháp ngà, còn hệ thống thật thì sống một cuộc đời khác.

Ở thái cực ngược lại: một startup tuyên bố "chúng tôi Agile, không cần kiến trúc sư, cứ ship trước rồi refactor sau". Sáu tháng đầu tốc độ ra tính năng ấn tượng. Đến tháng thứ bảy, mỗi service gọi thẳng vào database của service khác, không ai còn nhớ luồng dữ liệu đi qua bao nhiêu tầng, và một thay đổi nhỏ ở module thanh toán làm sập luôn module thông báo vì chúng chia sẻ chung một bảng chưa từng được thiết kế để chia sẻ. "Ship trước đã" đã biến thành "dọn dẹp sau" — và "sau" không bao giờ tới vì backlog tính năng luôn ưu tiên hơn.

Cả hai câu chuyện đều là thất bại của cùng một vấn đề: xác định sai vai trò của kiến trúc trong một tổ chức vận hành theo Agile/Scrum. Bài này không nói Agile "đúng" hay Big Design Up Front (BDUF — thiết kế toàn diện trước khi code) "sai". Nó nói về việc kiến trúc sư phải tồn tại ở đâu trên một dải phổ, và cái giá phải trả ở mỗi điểm trên dải phổ đó.

The Problem

Agile ra đời để giải quyết vấn đề của Waterfall: đặc tả yêu cầu cứng nhắc, phản hồi chậm, và rủi ro "big bang" khi cả hệ thống chỉ được kiểm chứng ở cuối dự án. Nguyên lý cốt lõi — iterative, incremental, đáp ứng thay đổi hơn là bám cứng kế hoạch — hoạt động cực tốt ở cấp độ tính năng (feature) và sprint.

Nhưng kiến trúc không sống ở cấp độ sprint. Một quyết định như "dùng message queue hay gọi đồng bộ giữa hai service", "chia sẻ database hay mỗi service một database riêng", "đặt boundary giữa domain Order và domain Inventory ở đâu" — có ảnh hưởng kéo dài hàng năm, xuyên qua hàng chục sprint, và rất tốn kém để đảo ngược. Nếu áp dụng tư duy "cứ code đi, refactor sau" cho những quyết định này, tổ chức đang đặt cược rằng chi phí sửa sai sau này sẽ thấp — một cược thường thua, vì kiến trúc càng "đông cứng" (calcify) theo thời gian khi càng nhiều code phụ thuộc vào nó.

Ngược lại, nếu kiến trúc sư cố kiểm soát mọi quyết định thiết kế trước khi sprint đầu tiên bắt đầu — theo kiểu BDUF — họ đang giả định rằng họ biết đủ thông tin ngay từ đầu. Trong thực tế, phần lớn tri thức về domain, về ràng buộc kỹ thuật thật, về hành vi người dùng thật chỉ xuất hiện trong khi xây dựng, không phải trước đó. Renovate lại thiết kế khi thông tin mới xuất hiện là bản chất của việc học, không phải thất bại — nhưng BDUF coi nó là thất bại, nên chống lại nó bằng cách "khóa cứng" thiết kế càng sớm càng tốt.

Vấn đề thật sự là: kiến trúc và Agile vận hành ở hai nhịp độ (cadence) khác nhau, nhưng phải cùng tồn tại trong cùng một tổ chức, cùng một backlog, cùng một đội ngũ. Câu hỏi không phải "chọn bên nào" mà là "thiết kế cơ chế nào để hai nhịp độ đó phối hợp mà không triệt tiêu nhau".

The Theory

Câu trả lời đã được đúc kết trong khái niệm emergent architecture (kiến trúc nổi lên / kiến trúc trồi dần) kết hợp với architectural runway (đường băng kiến trúc — khái niệm phổ biến trong SAFe) và tinh thần "Freedom within a Framework" (Tự do trong khuôn khổ).

Ý tưởng cốt lõi: kiến trúc sư không thiết kế toàn bộ hệ thống trước, và cũng không rút lui hoàn toàn để mặc đội tự xử. Thay vào đó, kiến trúc sư làm hai việc:

Thiết lập một bộ khung ràng buộc (constraints) tối thiểu nhưng không thể vi phạm — những "lan can" (guardrails) định hình không gian quyết định mà đội được phép di chuyển tự do bên trong. Ví dụ: "mọi giao tiếp giữa các bounded context phải qua API hoặc message broker, không service nào được truy cập trực tiếp database của service khác", hoặc "mọi endpoint public phải qua API Gateway để áp dụng auth/rate-limit thống nhất".
Chuẩn bị đường băng (runway) đi trước một khoảng ngắn, vừa đủ — không phải toàn bộ hệ thống, mà chỉ nền tảng kỹ thuật cần thiết để 2-3 sprint tới có thể chạy mà không bị chặn. Ví dụ: dựng sẵn khung CI/CD, schema database cốt lõi cho epic sắp tới, hợp đồng API (contract) giữa hai team sẽ tích hợp trong sprint kế tiếp. Runway được xây "just enough, just in time" — không xây trước cho toàn bộ roadmap một năm.

Bên trong khung ràng buộc đó, đội dev có toàn quyền tự chủ về cách triển khai: chọn thư viện, cấu trúc class, thuật toán, chi tiết implementation. Kiến trúc sư không duyệt từng pull request về mặt thiết kế chi tiết — họ chỉ can thiệp khi một quyết định đe dọa phá vỡ ranh giới đã thiết lập hoặc tạo ra hệ quả vượt phạm vi một team.

Đây chính là "Freedom within a Framework": framework (khung) tạo ra tính nhất quán và ngăn hỗn loạn ở tầm hệ thống; freedom (tự do) bên trong nó tạo ra tốc độ và quyền sở hữu (ownership) ở tầm đội nhóm. Kiến trúc trong mô hình này không phải là một tài liệu ban hành một lần rồi đóng băng — nó là một tập ràng buộc sống, được review và điều chỉnh liên tục qua các nghi thức Agile sẵn có: backlog refinement, sprint review, retro, và một nhịp riêng thường được gọi là "Architecture Sync" hoặc "Architecture Review Board nhẹ" (không phải ARB kiểu waterfall họp hàng tháng ký duyệt giấy tờ).

Vai trò kiến trúc sư trong mô hình này gần với một người gác biên (boundary keeper) kiêm người điều phối thông tin (information broker) hơn là người ra lệnh chi tiết. Họ không cần biết trước mọi câu trả lời — họ cần biết trước câu hỏi nào bắt buộc phải được trả lời trước khi bắt đầu, và câu hỏi nào có thể để đội tự khám phá dần.

The Trade-off

Đây là phần không thể mơ hồ: đặt bao nhiêu thiết kế trước, bao nhiêu để nổi lên, đều có giá cụ thể.

Nghiêng về BDUF (thiết kế trước nhiều):

Được: giảm rủi ro tích hợp bất ngờ, đội có bản đồ rõ ràng ngay từ đầu, dễ ước lượng effort/budget vì phạm vi đã định hình, dễ trình bày cho stakeholder không kỹ thuật.
Mất: tốc độ ra sản phẩm chậm hẳn ở giai đoạn đầu (nhiều tuần/tháng không có gì chạy được để demo); thiết kế dựa trên giả định thời điểm T0, khi requirement thay đổi ở T0+2 tháng thì phần lớn thiết kế phải vẽ lại — chi phí rework này thường bị đánh giá thấp; đội dev dễ có tâm lý "chỉ code theo bản vẽ", giảm ownership và khả năng phát hiện vấn đề sớm vì họ không tham gia ra quyết định.

Nghiêng về Emergent hoàn toàn (không ràng buộc gì):

Được: tốc độ ban đầu rất nhanh, đội tự do tối đa, phản ứng với thay đổi requirement gần như tức thời ở cấp module.
Mất: không có gì đảm bảo tính nhất quán giữa các phần hệ thống do các đội khác nhau xây — dễ sinh ra N cách gọi API khác nhau, N chiến lược xử lý lỗi khác nhau, N cách quản lý transaction khác nhau; chi phí tích hợp và onboarding tăng theo cấp số nhân theo số lượng service/module; nợ kỹ thuật tích lũy âm thầm vì không ai chịu trách nhiệm nhìn toàn cục cho đến khi nó gây sự cố production.

Nghiêng về mô hình "Freedom within a Framework" (khuyến nghị của bài này):

Được: cân bằng giữa tốc độ và nhất quán; nợ kỹ thuật ở tầm hệ thống được kiểm soát chủ động thay vì phát hiện sau; đội vẫn giữ ownership vì tự quyết chi tiết implementation.
Mất: đây là phần thường bị bỏ qua — mô hình này đòi hỏi kiến trúc sư phải tham gia liên tục, không phải một lần. Nó tốn effort giám sát dai dẳng: tham dự sprint review, refinement, đọc code review ở các điểm chạm ranh giới, liên tục thương lượng lại ranh giới khi nghiệp vụ thay đổi. Nếu tổ chức không cấp đủ thời gian cho kiến trúc sư làm việc này (một lỗi rất phổ biến — kiến trúc sư bị kéo đi làm feature như một dev bình thường), khung ràng buộc sẽ mục nát dần mà không ai nhận ra cho đến khi đã quá muộn. Nói cách khác: mô hình cân bằng không rẻ hơn hai thái cực — nó chỉ chuyển chi phí từ "thiết kế trả trước" hoặc "rework trả sau" sang "giám sát trả liên tục". Tổ chức phải chọn trả giá ở đâu, không phải chọn cách không trả giá.

The Architecture Diagram

graph LR
    subgraph BDUF["Big Design Up Front"]
        A1["Thiết kế 100% trước khi code<br/>Waterfall thuần"]
    end

    subgraph GUARDRAIL["Vùng Lan Can — Freedom within a Framework"]
        direction TB
        B1["Kiến trúc sư định nghĩa:<br/>ranh giới bounded context,<br/>giao thức giao tiếp,<br/>nguyên tắc bảo mật/dữ liệu"]
        B2["Đội dev tự chủ:<br/>class design, thư viện,<br/>thuật toán, chi tiết code"]
        B1 -.->|"ràng buộc cứng, không thương lượng"| B2
        B2 -.->|"phản hồi requirement mới,<br/>đề xuất điều chỉnh ranh giới"| B1
    end

    subgraph EMERGENT["Emergent hoàn toàn"]
        C1["Không ràng buộc trước<br/>Ship trước, dọn sau"]
    end

    A1 -->|"chậm, cứng, khó đổi"| GUARDRAIL
    EMERGENT -->|"hỗn loạn, thiếu nhất quán"| GUARDRAIL

    style BDUF fill:#3a1f1f,stroke:#b33,color:#eee
    style EMERGENT fill:#3a1f1f,stroke:#b33,color:#eee
    style GUARDRAIL fill:#1f3a24,stroke:#3b8,color:#eee

Sơ đồ trên biểu diễn một phổ (spectrum), không phải hai lựa chọn nhị phân. Vùng giữa — "lan can" — không phải điểm trung bình cộng an toàn mà là một thiết kế chủ động: kiến trúc sư chọn có chủ đích cái gì thuộc về ràng buộc cứng (bên trái mũi tên B1→B2) và cái gì để ngỏ cho đội tự quyết (bên trong B2), rồi liên tục điều chỉnh ranh giới đó qua vòng phản hồi B2→B1 khi có thông tin mới.

Implementation Guardrails

Định nghĩa ràng buộc bằng "không được làm gì", không phải "phải làm như thế nào". Nguyên tắc tốt: "Không service nào được truy cập trực tiếp database của service khác — mọi truy cập dữ liệu chéo domain phải qua API hoặc event." Nguyên tắc tồi (vi phạm tinh thần tự chủ): "Mọi service phải dùng Repository pattern với interface IRepository<T> và inject qua constructor theo cách X." Cái đầu là ranh giới kiến trúc thật sự (ảnh hưởng đến khả năng tách/scale hệ thống). Cái sau là chi tiết implementation nên để đội tự quyết.
Ràng buộc phải được thực thi bằng cơ chế kỹ thuật, không phải bằng lời hứa trong tài liệu. Một nguyên tắc không có gì enforce (linter rule, kiểm tra kiến trúc tự động kiểu ArchUnit/dependency-cruiser, network policy chặn truy cập chéo service ở tầng hạ tầng, CI gate) sẽ bị bỏ qua dưới áp lực deadline trong vòng hai sprint. "Lan can" phải là vật lý, không phải văn bản.
Runway chỉ đi trước 1-2 epic, không đi trước cả roadmap. Nếu kiến trúc sư thấy mình đang thiết kế chi tiết cho tính năng sẽ làm sau 6 tháng, đó là dấu hiệu BDUF đang len lỏi trở lại. Chỉ chuẩn bị nền tảng đủ để sprint kế tiếp không bị chặn — không hơn.
Mọi thay đổi ranh giới phải đi qua một nghi thức có thể quan sát được (visible), không phải quyết định âm thầm của một người. Dù là "Architecture Sync" hàng tuần hay một mục cố định trong sprint review, thay đổi lan can phải được ghi lại (liên hệ ADR — Architecture Decision Record, xem thêm ở bài trước) và cả đội biết lý do thay đổi, tránh tình trạng ranh giới trôi dạt (drift) không kiểm soát.

Architect's Verdict

Kiến trúc trong Agile không phải là một văn bản ban hành một lần rồi treo tường — nó là một cuộc đối thoại liên tục giữa "cái gì không được đổi" và "cái gì có thể học thêm rồi điều chỉnh". Nếu bạn thấy mình đang vẽ diagram cho một tính năng sẽ code sau ba sprint, dừng lại — bạn đang trả giá BDUF. Nếu bạn thấy hai team tự dựng hai cách gọi API khác nhau cho cùng một loại tích hợp mà không ai biết, bạn đang trả giá của hỗn loạn. Việc của kiến trúc sư không phải là né hai cái giá đó — là chọn có ý thức trả giá nào, ở đâu, và giám sát liên tục để giá đó không âm thầm đội lên.

🔗 Bài viết liên quan: Documentation là một phần của kiến trúc · Đo lường kiến trúc

Bài trước: Documentation là một phần của kiến trúc · Bài tiếp theo: Đo lường kiến trúc