Lộ trình chi tiết trở thành Solution Architect cho lập trình viên trong kỷ nguyên AI

Rất nhiều lập trình viên lầm tưởng rằng Solution Architect (Kiến trúc sư giải pháp) chỉ là một chức danh tiếp theo khi bạn đã làm Senior Developer đủ lâu. Thực tế, đây là một định hướng sự nghiệp hoàn toàn khác. Nếu Developer luôn trăn trở "làm thế nào để xây hệ thống", thì một Architect phải trả lời được câu hỏi "nên xây như thế nào, dựa vào điều kiện gì và sẽ ra sao nếu xây sai".

Vậy làm thế nào để bứt phá giới hạn và vạch ra lộ trình chi tiết trở thành Solution Architect (SA) cho lập trình viên? Bài viết này sẽ cung cấp cho bạn một bức tranh toàn cảnh, từ tư duy, kỹ năng cốt lõi cho đến cách thích ứng với làn sóng AI đang thay đổi ngành IT.

5 Tư duy cốt lõi tạo nên một Architect xuất sắc

Trước khi bàn về kỹ thuật (technical), một Solution Architect cần "lột xác" về mặt tư duy. Dưới đây là 5 mindset bắt buộc phải có:

• Chấp nhận đánh đổi (Trade-offs): Sẽ không có giải pháp nào là hoàn hảo tuyệt đối. Architect phải chọn giải pháp phù hợp nhất dựa trên ngữ cảnh, chi phí, yêu cầu kinh doanh và năng lực của đội ngũ. Giải pháp tốt nhất thường là giải pháp đơn giản nhất giải quyết được vấn đề.

• Nhìn bức tranh tổng thể (Big Picture): Architect không suy nghĩ cục bộ (local) mà phải nhìn bao quát toàn bộ giải pháp để tránh việc giải quyết được chỗ này nhưng lại gây lỗi ở chỗ khác.

• Thiết kế sẵn sàng mở rộng (Grow over time): Trong giai đoạn đầu thiếu thông tin, đừng cố thiết kế một hệ thống hoàn hảo. Hãy thiết kế đơn giản, chừa sẵn các "giao diện" (adapter) để hệ thống có thể mở rộng và đáp ứng những thay đổi trong tương lai.

• Trao quyền cho đội ngũ (Empowerment): Architect không cần phải tự tay viết toàn bộ code. Vai trò của bạn là tạo ra bản thiết kế rõ ràng, thuyết phục và hướng dẫn để các Developer, PM và Business cùng nhau xây dựng.

• Tầm nhìn dài hạn (Maintainability): Một bản thiết kế xuất sắc là bản thiết kế giúp hệ thống có thể được bảo trì và nâng cấp trong nhiều năm tới, kể cả khi bạn không còn ở trong dự án.

Lộ trình chi tiết để trở thành Solution Architect

Lộ trình nâng cấp từ lập trình viên lên SA đòi hỏi bạn phải chuyển dịch từ mô hình năng lực chữ T (T-shape) sang chữ P hoặc chữ M.

• Chữ T (Software Architect): Am hiểu rộng về quy trình nhưng có chuyên môn cực kỳ sâu ở một mảng duy nhất (ví dụ: Backend).
• Chữ P hoặc M (Solution Architect): Bắt buộc phải có chuyên môn sâu ở 2 hoặc 3 mảng trở lên, chẳng hạn như vừa giỏi Backend, vừa am hiểu Cloud và Data Architecture.

Để làm được điều này, bạn cần chinh phục các cột mốc sau:

• Nền tảng Code (Foundation): Phải code thật giỏi trước khi làm thiết kế. Bạn cần nắm vững Clean Code, nguyên lý SOLID và các Design Patterns.

• Kiến trúc hệ thống (Architecture Styles): Nâng cấp kiến thức về Tier, Layer, Microservices, Event-driven, CQRS.

• Cơ sở hạ tầng & Đám mây (Cloud): Am hiểu các kiến trúc đám mây (AWS, Azure), nguyên tắc thiết kế tính khả dụng cao (resiliency, circuit breaker), và Container/Kubernetes.

• Kiến trúc Dữ liệu (Data Architecture): Khác với Software Architect, Solution Architect cần am hiểu sâu về Data Warehouse, cơ sở dữ liệu SQL/NoSQL, và các luồng xử lý dữ liệu ETL (Extract - Transform - Load) để giải quyết các bài toán lớn.

Ứng dụng Mô hình thiết kế C4 để trình bày kiến trúc phần mềm

Khi đã có giải pháp, làm sao để trình bày cho người khác hiểu? Phương pháp hiệu quả nhất hiện nay là Mô hình C4 – phân rã hệ thống từ góc nhìn tổng thể xuống chi tiết (top-down) qua 4 cấp độ:

• Context (Ngữ cảnh): Trả lời câu hỏi hệ thống này dành cho ai (vai trò người dùng) và tương tác với các hệ thống bên ngoài nào (ví dụ: hệ thống Corebank, Email).

• Container (Khối ứng dụng): Phóng to hệ thống thành các khối lớn như UI, Backend, Database. Ví dụ: Tách biệt hệ thống quản lý Tenant và hệ thống quản lý Khách hàng.

• Component (Thành phần): Đi sâu vào Backend để chia thành các thành phần nhỏ hơn như Controller, Service Layer, Data Layer.

• Class (Lớp diagram): Mức độ thấp nhất dành cho lập trình viên trực tiếp viết code.

Lưu ý: Khi làm việc với các yêu cầu kinh doanh, SA phải nắm chắc ít nhất 80% bản thiết kế ở mức độ Context và Component trước khi đi sâu xuống các mức độ thấp hơn để tránh sai lệch toàn bộ hệ thống.

Để lập trình viên không bị AI thay thế thì cần làm gì?

Với sự ra đời của Generative AI, nhiều lập trình viên đang lạm dụng AI để sinh code mà bỏ qua kiến thức nền tảng. Điều này dẫn đến rủi ro tạo ra những hệ thống lỗi không thể bảo trì sau 10-20 năm.

Để ứng dụng AI một cách thông minh và bảo vệ định hướng thăng tiến thành Solution Architect, bạn cần:

• Nắm chắc nền tảng: Chỉ khi bạn hiểu SOLID, Design Patterns, bạn mới có thể kiểm tra (review) và phát hiện cái sai của AI.

• Mô hình Pair-programming: Khi làm việc với AI, hãy coi bạn là Navigator (Người chỉ đường, thiết kế cấu trúc) và giao AI làm Driver (Người trực tiếp gõ code). Đừng bao giờ phó mặc hoàn toàn cho AI quyết định kiến trúc.

• Áp dụng Top-down & Bottom-up: Bắt AI thiết kế từ mức độ tổng quan (Top-down) trước, bạn review thấy hợp lý mới cho phép AI đi vào chi tiết. Kết hợp Bottom-up bằng cách yêu cầu AI viết Unit Test để kiểm chứng tính đúng đắn của code.

Nghề lập trình sẽ ra sao trong 10 năm tới?

Dưới sự tác động của AI, thị trường IT trong 10 năm tới sẽ có sự đào thải và gộp chung (overlap) các vai trò lại với nhau. Theo dự đoán từ chuyên gia Đạo Võ:

• Các nghề nghiệp chuyên biệt sẽ thu hẹp: Các vị trí như QA/QC (Kiểm thử) thuần túy hoặc Front-end thuần túy có thể sẽ không còn là một nghề độc lập, mà trở thành một "bộ kỹ năng" (skill) bắt buộc phải có của một lập trình viên Full-stack.

• Sự lên ngôi của Technical Consultant/Product Owner: Thị trường sẽ khát những nhân sự có khả năng "bao sậu". Đó là một người vừa có khả năng lấy yêu cầu từ Business, làm việc trực tiếp với khách hàng, vừa dùng AI để chốt giải pháp và trực tiếp triển khai dự án.

Các câu hỏi thường gặp

Kỹ năng technical leadership giúp ích gì cho một SA?

Kỹ năng technical leadership (lãnh đạo kỹ thuật) đóng vai trò vô cùng quan trọng và là một trong những điểm khác biệt lớn nhất giữa một lập trình viên (Developer) và một Solution Architect (SA). Cụ thể, kỹ năng này giúp ích cho một SA ở những khía cạnh thực tế sau:

• Thuyết phục và quản lý các bên liên quan (Stakeholder Management): Một SA không chỉ ngồi viết code mà phải làm việc với rất nhiều bộ phận khác nhau như Business User, Project Manager (PM), Developer (Dev) và bộ phận Security. Kỹ năng leadership giúp SA giao tiếp mềm mỏng, khéo léo để thuyết phục tất cả các bên cùng đồng thuận đi theo một hướng giải pháp kiến trúc đã đề ra.

• Định hướng và tạo niềm tin cho team: Thay vì sử dụng quyền lực để ép buộc người khác làm theo ý mình, một SA có kỹ năng lãnh đạo sẽ đưa ra các nguyên tắc cốt lõi (principles) và giải thích rõ lý do tại sao nên thiết kế theo hướng đó (ví dụ: vì mục tiêu an bảo mật hay cần mở rộng hệ thống). Nhờ vậy, team sẽ hiểu, tin tưởng vào giải pháp và tự nguyện làm theo, tránh tình trạng tranh cãi (debate) không cần thiết làm xào xáo nội bộ.

• Dẫn dắt quá trình ra quyết định: Kỹ năng này giúp SA tổ chức các buổi trao đổi, kêu gọi sự đồng thuận và giúp cả team cùng nhau thống nhất chốt giải pháp (commit), từ đó tạo ra một khối thống nhất để mọi người cùng làm việc.

• Làm chủ kết quả và quản lý rủi ro (Own the outcome): Một nhà lãnh đạo kỹ thuật phải làm gương cho đội ngũ và chịu trách nhiệm với kết quả cuối cùng. SA dùng leadership để quản lý các rủi ro kỹ thuật (technical risks) và nợ kỹ thuật (technical debt), đảm bảo code không bị viết "tầm bậy" làm giảm chất lượng đầu ra của dự án.

Có thể nói, Solution Architect là vị trí dùng kỹ thuật để dẫn dắt con người (Tech people lead people). Vì vậy, việc trang bị kỹ năng mềm và năng lực lãnh đạo là điều kiện bắt buộc và phải được đặt lên hàng đầu để bổ trợ cho kỹ năng chuyên môn

Làm sao để trở thành AI Solution Architect từ Backend?

Thực ra, việc chuyển từ một lập trình viên Backend lên làm AI Solution Architect không hề khó nếu bạn nắm vững các nguyên lý cốt lõi và cách hệ thống AI vận hành dưới nền tảng. Với xuất phát điểm là Backend, bạn đã có một lợi thế rất lớn, và đây là lộ trình chi tiết để bạn phát triển:

1. Mở rộng nền tảng sang Data Architecture (Kiến trúc dữ liệu) Để làm các giải pháp liên quan đến AI, bạn phải làm chủ được luồng dữ liệu. Một kỹ sư Backend khi học thêm về cách thiết kế Data Warehouse và các luồng xử lý dữ liệu (ETL) sẽ thấy việc triển khai các bài toán về Data và AI trở nên khá dễ dàng. Giải pháp AI Solution đòi hỏi bạn phải am hiểu toàn diện cả về luồng Backend truyền thống lẫn cách tổ chức dữ liệu.

2. Làm chủ kiến trúc RAG (Retrieval-Augmented Generation) AI bao gồm rất nhiều mảng, nhưng phổ biến và ứng dụng mạnh mẽ nhất hiện nay là Generative AI kết hợp với RAG. Kiến trúc này đòi hỏi bạn phải nắm vững cách đưa thông tin nội bộ của doanh nghiệp vào cho AI xử lý thông qua các bước cốt lõi:

• Vector hóa dữ liệu (Embedding): Bạn phải biết cách đưa dữ liệu (văn bản) qua các mô hình (embedding model) để cắt nhỏ và biến văn bản thành các vector (các mảng ma trận n chiều).

• Lưu trữ vào Vector Database: Sau khi chuyển văn bản thành vector, hệ thống sẽ lưu trữ chúng xuống các cơ sở dữ liệu chuyên dụng gọi là Vector DB.

• Tìm kiếm bằng Cosine Similarity: Khi có người dùng đặt câu hỏi, hệ thống cũng biến câu hỏi đó thành vector và truy vấn trong Vector DB. Quá trình tìm kiếm này thực chất là thực hiện các phép nhân ma trận (tính khoảng cách Cosine) để lọc ra các danh sách dữ liệu có ý nghĩa gần nhất với câu hỏi.

• Xếp hạng (Ranking) và Prompt Engineering: Sau khi lấy ra được danh sách các văn bản có độ tương đồng cao nhất, bạn phải biết cách xếp hạng (ranking) chúng theo thứ tự ưu tiên. Cuối cùng, bạn nhúng danh sách dữ liệu này (ví dụ 10 dòng kết quả) vào một câu lệnh (prompt) để yêu cầu mô hình ngôn ngữ lớn sinh ra câu trả lời cho khách hàng dựa trên dữ liệu đó.

3. Phân rã bài toán và thiết kế chi tiết Khi đã thấu hiểu từng ly từng tí bản chất các bước xử lý trên của mô hình AI, mọi thứ sẽ trở nên rất rõ ràng và không có gì phức tạp. Công việc của bạn với tư cách một Architect lúc này là vận dụng kỹ năng System Design để thiết kế luồng (flow) cho hệ thống, kết hợp với Backend app sẵn có. Bạn có thể tự mình vẽ các biểu đồ Component, Database diagram, và biểu đồ tuần tự (Sequence diagram) cho hệ thống. Thậm chí, bạn có thể áp dụng ngay mô hình Pair-programming, yêu cầu AI hướng dẫn hoặc hỗ trợ bạn vẽ các biểu đồ Sequence này một cách chuẩn xác

Làm sao để thực hành tư duy SA khi đang làm Dev?

Để thực hành tư duy Solution Architect (SA) ngay cả khi đang mang chức danh Developer, bạn có thể áp dụng các cách sau:

• Hành động trước khi có chức danh: Đừng đợi đến khi được bổ nhiệm làm Architect mới bắt đầu suy nghĩ như họ. Hãy rèn luyện thói quen suy nghĩ, hành động và giải quyết mọi vấn đề như một Architect ngay từ bây giờ, chức danh sẽ tự động theo sau.

• Chủ động nhận việc (Volunteer) và làm chủ (Autonomy): Hãy tự làm chủ công việc, chủ động nhận việc để giải quyết các bài toán của công ty. Bạn có thể xung phong tham gia phân tích yêu cầu (requirement), tập vẽ và giải thích kiến trúc bằng mô hình C4, viết tài liệu thiết kế (design document), và chủ động đặt câu hỏi phản biện về các quyết định thiết kế (tại sao dùng công nghệ này thay vì công nghệ khác).

• Thực hành qua dự án cá nhân: Không ai cấm bạn tự thiết kế một dự án cá nhân và tự đóng vai trò là Architect cho dự án đó.

• Tận dụng AI và học hỏi người giỏi nhất: Hãy quan sát người giỏi nhất trong team để học hỏi những kiến thức tinh hoa từ họ. Đồng thời, tận dụng AI để nhờ hướng dẫn, phản biện thiết kế hoặc tham gia các khóa học thực chiến để tích lũy kinh nghiệm

Những chứng chỉ nào cần thiết để trở thành Solution Architect?

Theo chia sẻ của anh Đạo Võ, để trở thành Solution Architect, việc có chứng chỉ là được khuyến khích nhưng hoàn toàn không bắt buộc. Bằng cấp từ trường đại học, kết hợp với việc tự học và tự nghiên cứu kiến thức qua sách vở là đã đủ nền tảng cơ bản.

Tuy nhiên, nếu bạn muốn dùng chứng chỉ làm định hướng để học hỏi và củng cố hồ sơ, bạn có thể tham khảo các nhóm chứng chỉ sau:

• Chứng chỉ chuyên môn về thiết kế kiến trúc: Có thể kể đến ISAQB hoặc TOGAF. Tuy nhiên, anh Đạo lưu ý rằng TOGAF khá nặng về Enterprise Architecture (kiến trúc doanh nghiệp) nên anh không khuyến khích học ngay ở thời điểm hiện tại.

• Chứng chỉ về Điện toán đám mây (Cloud) và Hệ thống: Bạn nên cân nhắc tìm hiểu và lấy các chứng chỉ liên quan đến AWS, Azure, Google Cloud hoặc Kubernetes.

Điều quan trọng nhất được nhấn mạnh là bạn có thể tận dụng lộ trình học của các chứng chỉ này để tự nghiên cứu và làm chủ (master) kiến thức, chứ không nhất thiết phải bỏ tiền ra thi để lấy bằng cấp.

----------------

Tìm hiểu thêm: 

Khóa học DevOps Engineer & Cloud Architect

Lộ trình học AI Engineer Từ Con Số 0