Kiến trúc phần mềm: Đánh thức sự sáng tạo từ 'buồng vang' và nâng cao sự phối hợp

Kiến trúc phần mềm: Đánh thức sự sáng tạo từ 'buồng vang' và nâng cao sự phối hợp

Trong cuộc đối thoại tại QCon London 2025, các chuyên gia kiến trúc phần mềm đã chia sẻ kinh nghiệm thực tế về việc truyền tải "nợ kỹ thuật" cho các bên liên quan, áp dụng các ghi chú quyết định kiến trúc (ADR) để phân tán quyền ra quyết định, và cách phá vỡ rào cản giữa đội ngũ phát triển di động và backend để xây dựng hệ thống toàn diện.

Giao tiếp kiến trúc: Từ "lời chửi bới" kỹ thuật đến sự thấu hiểu của doanh nghiệp

Andrew Harmel-Law và các diễn giả nhấn mạnh tầm quan trọng của việc "lấy kiến trúc ra khỏi buồng vang". Thay vì chỉ nói chuyện với nhau trong cộng đồng kiến trúc sư, họ cần truyền tải thông điệp cho các bên liên quan bằng ngôn ngữ dễ hiểu.

• Loại bỏ ngôn ngữ "geek": Vanessa Formicola và Peter Hunter đề xuất sử dụng hình ảnh trực quan, sơ đồ (sketches) và các công cụ như Excalidraw để minh họa các quyết định. Điều này giúp những người không chuyên về kỹ thuật dễ dàng hình dung tầm quan trọng của kiến trúc.
• Dịch thuật ngôn ngữ: Diana Montalion khuyên rằng kiến trúc sư cần thiết kế các tài liệu thông minh, tạo ra các phiên bản khác nhau phù hợp với đối tượng tiếp nhận (người kinh doanh, quản lý, kỹ thuật viên) để thuyết phục họ.
• Kết nối mục tiêu kinh doanh: Shana Dacres-Lawrence và Cat Morris nhấn mạnh việc liên kết kiến trúc với các mục tiêu kinh doanh cốt lõi. Khi bạn có thể đưa ra con số về chi phí rủi ro hoặc lợi ích, việc thuyết phục sẽ trở nên dễ dàng hơn gấp nhiều lần.

Quyết định kiến trúc phân tán (ADR) và trách nhiệm

Một trong những chủ đề nóng nhất là sự chuyển dịch từ mô hình kiến trúc tập trung sang mô hình phân tán quyền ra quyết định.

• Áp dụng ADR: Elena Stojmilova chia sẻ về kinh nghiệm áp dụng Ghi chú Quyết định Kiến trúc (Architecture Decision Records - ADR). Các đội nhóm có thể tự chủ ra quyết định trong phạm vi quyền hạn của mình, miễn là tuân thủ các nguyên tắc kiến trúc chung.
• Quy trình phản hồi: Để đảm bảo không có quyết định nào đi sai hướng, nhóm đã thiết lập một "thời hạn bảo hành" là 7 ngày. Trong thời gian này, bất kỳ ai cũng có thể phản hồi hoặc đưa ra ý kiến. Nếu không có phản hồi gì quan trọng, quyết định sẽ được chấp nhận.
• Thay đổi hành vi: Peter Hunter thừa nhận rằng việc áp dụng quy trình này đòi hỏi thay đổi hành vi lớn. Đội ngũ cần được hướng dẫn và nhắc nhở để thói quen làm việc thay đổi từ "làm xong rồi nói" sang "tài liệu hóa và thảo luận trước".

Phá vỡ rào cản giữa Mobile và Backend

Một "con hổ ngầm" trong ngành công nghệ hiện nay là sự tách biệt giữa đội ngũ phát triển ứng dụng di động (Mobile) và backend web.

• Đội ngũ đa chức năng: Vanessa Formicola đề xuất không bao giờ để đội ngũ Mobile thiết kế một mình. Họ cần thiết kế cùng với backend trong cùng một không gian để giải quyết các vấn đề đồng bộ.
• Backend for Frontend (BFF): Việc sử dụng BFF là một giải pháp hữu ích để tạo ra một lớp trung gian, giúp giải quyết các vấn đề giao diện và logic riêng biệt cho từng nền tảng mà vẫn giữ được sự nhất quán.
• Tránh sự tách biệt: Cat Morris chỉ trích việc có các Product Manager riêng biệt cho từng nền tảng (iOS, Android, Web). Thay vào đó, nên có một người chịu trách nhiệm duy nhất cho trải nghiệm người dùng, đảm bảo sự nhất quán trên mọi kênh.

Hành nghề kiến trúc sư trong kỷ nguyên số

Cuộc đối thoại cũng mở ra câu hỏi về định hướng nghề nghiệp cho các kiến trúc sư trong tương lai.

• Kỹ năng đa dạng: Diana Montalion và Shana Dacres-Lawrence cho rằng kiến trúc sư hiện đại không cần phải là những người viết code giỏi nhất, nhưng họ cần khả năng ảnh hưởng (influence) và hiểu biết sâu rộng về nhiều lĩnh vực khác nhau.
• Hành trình nghề nghiệp không tuyến tính: Họ nhấn mạnh rằng con đường trở thành kiến trúc sư không còn là một tháp thang lối mòn. Nó là một con đường "con rắn" (squiggly line), cho phép các kỹ sư từ nhiều nền tảng khác nhau có cơ hội thăng tiến vào vai trò này.
• Tư duy học hỏi: Andrew Harmel-Law và các diễn giả đều đồng ý rằng kiến trúc sư cần chấp nhận việc đưa ra những quyết định sai lầm. Việc chấp nhận "nhanh và sai" tốt hơn "chậm và đúng" giúp doanh nghiệp tiến bộ nhanh hơn.

"Fast and wrong is better than slow and correct" – Andrew Harmel-Law

Quyết định sai lầm là điều không thể tránh khỏi, nhưng quan trọng là khả năng học hỏi từ chúng để cải thiện hệ thống trong tương lai.