Tôi đã trở thành Solution Architect như thế nào? (Phần 2): T-Shaped – Bộ kỹ năng chữ T của một Solution Architect

Ở Phần 1, tôi đã giới thiệu về Systems 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ó 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

1. Hiểu yêu cầu kinh doanh → Dịch thành yêu cầu kỹ thuật.
2. 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
3. Lựa chọn công nghệ phù hợp (framework, platform, tool).
4. Làm việc với các bên liên quan: PM, developer, DevOps, security team, khách hàng.
5. Tạo tài liệu kỹ thuật: High-Level Design (HLD), Low-Level Design (LLD), roadmap triển khai.

II. T-Shaped 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

T-Shape 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 T-Shape để 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Ế:

Ví dụ – Xây hệ thống Mobile Banking cho ngân hàng X

1. 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ệ, …

2. Khảo sát dự án

Dùng Horizontal: Business + PM

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?

3. Thiết kế giải pháp

Dùng Vertical thiết kế hệ thống, bảo mật

4. Cost & budget

Dùng Horizontal: Cost + PM

5. Phát triển

Dùng Vertical + Horizontal: DevOps + PM

Dev team tự triển khai 80% – mình chỉ review.
T-shape giúp mình nói được ngôn ngữ của Developer.

6. Pen Test, Security Test, Compliance

Dùng Vertical: Security

7. Go-live

Dùng Horizontal: PM + Business

8. Bài học rút ra

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.

T-shaped khác gì I-shaped và chuyên gia đa năng?

I-shaped là người rất sâu ở một chuyên môn nhưng ít hiểu các lĩnh vực xung quanh. Họ giỏi giải bài toán được giao, nhưng khó kết nối với nghiệp vụ và các nhóm khác.

Chuyên gia đa năng (generalist) biết rộng nhiều lĩnh vực nhưng không đủ sâu ở mảng nào để ra quyết định kỹ thuật khó.

T-shaped kết hợp cả hai: thanh dọc là chuyên môn sâu, thanh ngang là hiểu biết rộng và kỹ năng làm việc với con người. Theo chia sẻ trong bài, khái niệm T-shaped được McKinsey giới thiệu từ những năm 1980 và được Tim Brown (IDEO) phổ biến sau đó.

Với vai trò kiến trúc sư giải pháp, mô hình T-shaped gắn liền với các khung kiến trúc doanh nghiệp như TOGAF của The Open Group, nơi người kiến trúc sư phải vừa hiểu sâu công nghệ, vừa hiểu rộng mục tiêu kinh doanh.

Lộ trình phát triển kỹ năng T-shaped cho người làm kỹ thuật

Kỹ năng T-shaped không hình thành trong một khoá học. Nó được bồi đắp qua từng dự án, như cách anh Kha kể lại hành trình đi qua 7 giai đoạn của một dự án thực tế. Gợi ý dưới đây giúp bạn chủ động hơn trên lộ trình đó.

Bước 1 – Chọn thanh dọc. Xác định 1–2 mảng công nghệ muốn đi sâu, như thiết kế hệ thống, dữ liệu hay bảo mật, và đầu tư thời gian học bài bản.

Bước 2 – Mở rộng thanh ngang qua dự án. Xin tham gia khảo sát yêu cầu, ước lượng chi phí, làm việc với khách hàng – những việc giúp bạn hiểu nghiệp vụ.

Bước 3 – Rèn kỹ năng giao tiếp. Tập trình bày giải pháp cho người không làm kỹ thuật; đây là phần thanh ngang khó nhất với nhiều kỹ sư.

Bước 4 – Nhìn lại sau mỗi dự án. Ghi lại bài học ở cả hai chiều chuyên sâu và hiểu rộng, như phần “Bài học rút ra” trong bài, để lộ trình T-shaped của mình rõ ràng hơn.

Sai lầm thường gặp khi phát triển kỹ năng T-shaped

Chỉ đào sâu, quên mở rộng. Nhiều kỹ sư giỏi dành toàn bộ thời gian cho công nghệ mới mà bỏ qua giao tiếp và nghiệp vụ. Kết quả là giải pháp tốt về kỹ thuật nhưng khó được khách hàng chấp nhận.

Mở rộng quá sớm. Ngược lại, có người muốn biết mọi thứ khi thanh dọc chưa vững. Thiếu một chuyên môn đủ sâu, họ khó đưa ra quyết định kiến trúc có trọng lượng – điều mà mô hình T-shaped đòi hỏi.

Coi thanh ngang là “kỹ năng mềm phụ”. Trong các giai đoạn như khảo sát dự án, ước lượng chi phí hay go-live, chính khả năng làm việc với nhiều bên mới quyết định dự án thành công.

Không có người dẫn đường. Phát triển T-shaped nhanh hơn nhiều khi có người đi trước chia sẻ kinh nghiệm thực tế, phản biện cách mình suy nghĩ và chỉ ra những khoảng trống mình chưa thấy.

Ví dụ thanh dọc và thanh ngang của một Solution Architect

Thanh dọc (chuyên môn sâu): thiết kế hệ thống, lập trình hướng đối tượng, cơ sở dữ liệu, bảo mật, xu hướng công nghệ – những mảng mà người kiến trúc sư phải đủ sâu để chịu trách nhiệm quyết định kỹ thuật.

Thanh ngang (hiểu biết rộng): tạo mối quan hệ với 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 đa ngành, hiểu chi phí và ngân sách. Đây là phần giúp hồ sơ T-shaped trở nên khác biệt khi ứng tuyển các vị trí kiến trúc và lãnh đạo công nghệ.

Câu hỏi thường gặp về mô hình T-shaped

T-shaped là gì?

T-shaped là mô hình kỹ năng hình chữ T: thanh dọc là chuyên môn sâu ở một vài lĩnh vực, thanh ngang là hiểu biết rộng và kỹ năng phối hợp với các bộ phận khác.

Vì sao Solution Architect được xem là điển hình T-shaped?

Vì Solution Architect phải chuyên sâu 1–2 mảng công nghệ để ra quyết định kiến trúc, đồng thời hiểu rộng nghiệp vụ, chi phí, bảo mật và vận hành để giải pháp khả thi trong thực tế.

Lập trình viên có nên phát triển theo mô hình T-shaped?

Nên, đặc biệt nếu muốn lên vai trò kiến trúc sư hay trưởng nhóm. Kỹ năng T-shaped giúp lập trình viên hiểu vì sao mình làm, không chỉ làm thế nào.

Làm sao biết mình đã đủ T-shaped?

Khi bạn vừa có thể tự tin ra quyết định kỹ thuật trong chuyên môn của mình, vừa có thể giải thích giải pháp cho khối nghiệp vụ và cân nhắc chi phí, rủi ro cùng họ.

T-shaped liên quan gì đến systems thinking?

Systems thinking, chủ đề của Phần 1 trong series, là nền tảng của thanh ngang: nhìn hệ thống như một tổng thể. Kết hợp hai điều này giúp kỹ năng T-shaped của Solution Architect phát huy trọn vẹn.

Doanh nghiệp nên xây dựng đội ngũ T-shaped thế nào?

Kết hợp đào sâu chuyên môn với luân chuyển vai trò trong dự án, để mỗi người có cơ hội mở rộng thanh ngang mà không mất đi thế mạnh chuyên sâu của mình.

Học T-shaped ở đâu hiệu quả nhất?

Hiệu quả nhất là học trên chính dự án thật, có người đi trước đồng hành. Thanh dọc có thể tự học qua tài liệu, nhưng thanh ngang của mô hình T-shaped chỉ thật sự vững khi bạn được đặt vào tình huống phải làm việc với khách hàng, nghiệp vụ, ngân sách và rủi ro, rồi được phản biện thẳng thắn sau mỗi lần ra quyết định.

Nguồn: Digital Leaders Publishing Club — bài gốc (tác giả: Phạm Quang Anh Kha — @khapqa trên forum). Bản quyền thuộc tác giả gốc.