[Series][Chap 2] Tôi đã trở thành Solution Architect như thế nào? -
Ở Chap 1. Tôi đã giới thiệu về System Thinking. Phương pháp để không bị lạc lối trong biển kiến thức khổng lồ của công nghệ.
Vậy làm sao để có thể biết được cần xây dựng những bộ kĩ năng gì và theo hướng nào để có thể có thể có kế hoạch phù hợp để trở thành một SA. Nhưng trước tiên hãy tìm hiểu Solution Architect là ai?
Solution Architect (Kiến trúc sư giải pháp) là một vai trò chuyên môn cao trong lĩnh vực
công nghệ thông tin (CNTT), chịu trách nhiệm thiết kế toàn bộ giải pháp công nghệ để đáp ứng
nhu cầu kinh doanh của khách hàng hoặc tổ chức.
I. Nhiệm vụ chính
- Hiểu yêu cầu kinh doanh → Dịch thành yêu cầu kỹ thuật.
- Thiết kế kiến trúc hệ thống (on-premise, cloud, hybrid) bao gồm:
- Các thành phần phần cứng/phần mềm
- Tích hợp hệ thống (integration)
- Dữ liệu (data flow, database)
- Bảo mật, hiệu năng, khả năng mở rộng
Lựa chọn công nghệ phù hợp (framework, platform, tool).
Làm việc với các bên liên quan: PM, developer, DevOps, security team, khách hàng.
Tạo tài liệu kỹ thuật: High-Level Design (HLD), Low-Level Design (LLD), roadmap triển khai.
II. TShaped là gì? Ứng dụng như thế nào?
1. Định nghĩa
Khái niệm này được McKinsey & Company giới thiệu từ những năm 1980 và phổ biến bởi Tim Brown (CEO IDEO) vào năm 1991. Cơ bản chia làm 2 chiều: ngang và dọc.
- Kỹ năng rộng (Horizontal Bar): Tạo mối quan hệ giữa các phòng ban nghiệp vụ, giao tiếp, thuyết trình, làm việc nhóm, kiến thức cơ bản đa ngành,…
- Chuyên môn sâu (Vertical Bar): Kiến thức chuyên sâu về công nghệ: Lập trình hướng đối tượng, cơ sở dữ liệu, xu hướng công nghệ, bảo mật, thiết kế hệ thống,…
Solution Architect (SA) là “điển hình T-shaped” – họ phải chuyên sâu 1–2 mảng công nghệ (Vertical Bar) nhưng đồng thời hiểu rộng toàn bộ hệ sinh thái dự án (Horizontal Bar) để thiết kế giải pháp end-to-end, khả thi, tối ưu chi phí & thời gian.
Để thiết kế một giải pháp phù hợp với yêu cầu kinh doanh. Một SA phải có kiến thức đủ rộng về mặt công nghệ và rộng về những kiến thức lĩnh vực liên quan. Với kinh nghiệm cá nhân. Điều đó có nghĩa, con đường để trở thành Solution Architect không thể một sớm một chiều mà cần qua quá trình tôi luyện từ một developer bình thường đến một Technical Architect hoặc Application Architect để phát triển về chiều sâu trước.
2. Ứng dụng
TShape với mình có thể ứng dụng được ở nhiều cấp độ khác nhau. Để xây dựng cho bản thân có thể dùng TShape để tích luỹ kiến thức, dùng nó để thấy được bản thân cần học những kĩ năng, kiến thức gì. Và cũng có thể ứng dụng vào ngay công việc hàng ngày.
Để cho dễ hiểu. Mình lấy ví dụ về một DỰ ÁN THỰC TẾ:
Xây hệ thống Mobile Banking cho ngân hàng X
| Nội dung | Kết quả |
| ------------- |:-------------
| Thông tin | Ngân hàng X (500k user) |
| Yêu cầu | App Mobile Banking + Core Banking Integration + 99.99% uptime |
| Thời gian | 6 tháng |
| Đội ngũ | 15 người (Dev, QA, DevOps, Security) |
- Phân tích các yếu tố Vertical Bar & Horizontal Bar
- Horizontal Bar: Bối cảnh tổ chức, yêu cầu nghiệp vụ, mối quan hệ giữa các phòng ban, chi phí, quản lý dự án,…
- Vertical Bar: Hạ tầng công nghệ, các microservices, công nghệ, …
- Khảo sát dự án
Dùng Horizontal: Business + PM
| Nội dung | Kết quả |
|---|---|
| Phỏng vấn, lấy yêu cầu, làm rõ yêu cầu nghiệp vụ | Hiểu rõ hành trình vay như thế nào? KYC, Fraud check, điền thông tin, các yêu cầu realtime, phục vụ số lượng bao nhiêu… |
| Vẽ customer journey | Xác định các user case |
Dùng Horizontal: Không chỉ hỏi kỹ thuật → hỏi doanh thu, rủi ro, quy định NHNN như thế nào?
- Thiết kế giải pháp
Dùng Vertical thiết kế hệ thống, bảo mật
| Thành phần | Thiết kế |
|---|---|
| Frontend | React Native + CDN (CloudFront) |
| Backend | Microservices (Spring Boot) |
| Message Queue | Kafka (MSK) + SQS |
| Database | Aurora PostgreSQL (Multi-AZ) |
| Auth | Azure AD |
- Cost & budget
Dùng Horizontal: Cost + PM
| Hạng mục | Chi phí |
|---|---|
| AWS | 2.1 tỷ |
| License | 300 triệu |
| Dev | 1.8 tỷ |
| Tổng | Tổng4.2 |
- Phát triển
Dùng Vertical + Horizontal: DevOps + PM
| Hành động | Công cụ |
|---|---|
| Viết Terraform modules | IaC |
| Tạo CI/CD pipeline | Gitlab Runner |
| Hướng dẫn Dev team | Workshop 2 buổi |
| Tổng | Tổng4.2 |
Dev team tự triển khai 80% – Mình chỉ review*
T-shape giúp Minh nói được ngôn ngữ của Developer_
- Pen Test, Sercurity Test, Compliance
Dùng Vertical: Security
| Hạng mục | PIC |
|---|---|
| Checklist | Tự làm |
| Penetration Test | Thuê bên thứ 3 |
| Data Encryption | KMS + S3 SSE |
- Golive
Dùng Horizontal: PM + Business
| Hành động | Kết quả |
|---|---|
| Change Management | Đào tạo 200 nhân viên ngân hàng |
| Monitoring | CloudWatch + Grafana |
| Post-go-live | review99.99% uptime, 50k user đồng thời |
- Bài học rút ra
| Giai đoạn | Dùng Vertical | Dùng Horizontal |
|---------------|:----------------------------------------|:--------------------------------------------------|:
| Discovery | — | Hiểu nghiệp vụ, nói chuyện với C-level |
| Design | Vẽ kiến trúc chuẩn | Đảm bảo bảo mật, chi phí, khả thi |
| Estimation| Tính tech stack chính xác | Thuyết phục CFO, PM |
| Implement | Viết IaC, hướng dẫn dev | Giảm communication gap |
| Go-live | — | Quản lý rủi ro, đào tạo, support |
Trên đây là một dự án mình đã áp dụng và bài học rút ra từ dự án muốn chia sẻ lại cho mọi người. Cảm ơn mọi người đã đọc hết bài.