Software Architect là gì? Sai lầm nguy hiểm của Software Architect?

Software Architect là người phân tích yêu cầu của khách hàng (bên trong hoặc bên ngoài công ty) rồi đưa ra thiết kế hệ thống và theo dõi sát đội Developer để đảm bảo họ làm theo đúng thiết kế.

Software Architect phải theo sát đội Developer khi xây dựng và vận hành hệ thống, cũng như khi duy trì và mở rộng hệ thống.

Đọc bài phỏng vấn của ITviec với anh Phạm Tuấn Dũng, Technical Project Manager của M_Service (MoMo), người có hơn 3 năm kinh nghiệm làm Software Architect, để biết:

• Software Architect là gì? Công việc cụ thể của họ?
• Sai lầm “nhớ đời” của anh Dũng khi làm Software Architect và bài học rút ra
• Lời khuyên dành cho các bạn trẻ muốn trở thành Software Architect

Xem thêm việc làm Software Architect trên ITviec

Chào anh Dũng! Công việc đầu tiên của anh sau khi ra trường là gì?

Sau khi tốt nghiệp ngành Information System của Đại học Ngoại ngữ – Tin học TP. HCM (HUFLIT) vào năm 2006, anh đầu quân cho GHP Solutions (nay là Swiss Post Solutions), một công ty outsourcing của Thụy Sĩ.

Anh chọn công ty này vì khi đến phỏng vấn, anh thấy môi trường ở đây chuyên nghiệp. Hơn nữa, hai người phỏng vấn anh – chị Project Manager và anh Team Leader nice quá. 🙂

Ban đầu, anh làm công việc QC (Quality Control). Ba tháng sau, khi biết Team Developer thiếu người, anh xin sếp chuyển qua team này, vì công việc của một Developer gần với ngành học của anh hơn.

Tuy nhiên, lúc đó anh chưa có định hướng gì về con đường sự nghiệp của mình cả. May mắn là anh gặp được một chị sếp rất tốt. Đó là Project Manager, sếp trực tiếp của anh. Chị ấy đã giúp anh xây dựng career path rất rõ ràng: sau 3 năm trở thành Senior Developer, làm ở vị trí này 2 năm sẽ tham gia một kỳ thi để trở thành Principal Developer (gần giống như Team Leader).

Chị ấy cũng giao những “tasks” cụ thể để anh học hỏi và rèn luyện các kỹ năng cần thiết trên con đường phát triển sự nghiệp.

Xem thêm Bài học thành công từ một Project Manager

Xem thêm Senior Developer cần kỹ năng gì?

Là những “tasks” gì vậy anh?

Anh vẫn còn nhớ “task” đầu tiên là anh phải vẽ được mô hình xử lý của các màn hình chị ấy giao cho.

Mục tiêu tiếp đó của anh là học về quy trình phát triển phần mềm và nghiên cứu về Unified Modeling Language (UML).

Và “task” cuối cùng anh hoàn thành ở GHP là tự thiết kế và coding một module dùng để tự lọc data từ các bản scan văn bản viết tay.

Một điều thú vị nữa trong thời gian anh làm việc ở GHP là anh gặp một bác Senior Developer người Đức ở công ty đối tác. Bác ấy nói chỉ tập trung vào coding thôi thì chán lắm, rồi khuyên anh nên tìm một môn nghệ thuật nào đó, chẳng hạn như chụp ảnh, để cân bằng cuộc sống và code tốt hơn. Sau đó anh nhận ra là bác ấy nói đúng! 🙂

Những trải nghiệm của anh ở GHP thật đặc biệt. Vậy tại sao anh lại rời công ty này?

Anh muốn học một cái gì đó mới mẻ. Anh muốn thử sức ở lĩnh vực mobile application. Vì vậy, sau 2 năm làm ở GHP, anh chuyển qua BlueClub, một công ty start-up về các giải pháp mobile.

Các công việc của anh sau đó? Hành trình đến vị trí Software Architect của anh như thế nào?

Anh ở BlueClub được 2 năm thì chuyển sang ME Corp, làm Senior Developer cho mảng game mobile của công ty. Một năm sau, anh bắt đầu công việc của một Software Architect: tham gia thiết kế hệ thống game server, thiết kế database, system.

Một thời gian sau thì anh chuyển qua đầu quân cho VNG. Anh gắn bó với VNG 4 năm, làm ở vị trí Team Leader và các công việc giống như Software Architect, ví dụ như tham gia thiết kế các framework và hệ thống game server. Một điều thú vị là kinh nghiệm anh học được trong thời gian làm ở VNG gần như gấp đôi 6 năm trước đó.

Năm 2016, anh gia nhập ngành e-commerce, làm việc tại HOTDEAL với vị trí Technical Advisor. Công việc này cũng gần giống với Software Architect.

Đầu năm 2017, anh chuyển đến M_Service (MoMo) và làm việc ở vị trí Technical Project Manager cho đến nay. Công việc này cũng khá giống với trách nhiệm của Software Architect. Anh chịu trách nhiệm quản lý các nhóm dự án và tham gia hỗ trợ các development team về những vấn đề kỹ thuật như kiến trúc hệ thống và nghiên cứu công nghệ.

Việc làm Software Architect tại TP. HCM

Việc làm Software Architect tại Hà Nội

Vậy công việc của một Software Architect là gì?

Khá nhiều người nghĩ Software Architect là người chỉ thiết kế kiến trúc hệ thống lúc đầu là xong việc, như kiểu vẽ bản vẽ để người ta xây nhà rồi đi mất. Thực chất công việc của Software Architect liên tục và gắn liền với dự án từ khi bắt đầu đến lúc kết thúc.

Software Architect không chỉ phân tích yêu cầu của khách hàng (bên trong hoặc bên ngoài công ty) rồi đưa ra thiết kế hệ thống mà phải theo dõi sát đội Developer để đảm bảo họ làm theo đúng thiết kế. Software Architect phải theo sát đội Developer khi xây dựng hệ thống, khi vận hành hệ thống, cũng như khi duy trì và mở rộng hệ thống.

Thường một ngày làm việc của anh sẽ như thế nào?

Mỗi sáng, anh sẽ họp với các bạn Developer, review những yêu cầu của khách hàng (khách hàng ở đây bao gồm cả khách hàng ở ngoài lẫn các phòng ban khác trong công ty). Anh sẽ cùng các bạn Developer phân tích những yêu cầu mà có thể ảnh hưởng đến performance hệ thống và lựa chọn các giải pháp phù hợp nhất.

Ví dụ, anh nhận được yêu cầu thiết kế một framework server đáp ứng được tính ổn định và khả năng mở rộng. Trong team, có một bạn Senior Developer muốn chọn ngôn ngữ C++ và kiến trúc server khá phức tạp. Tuy nhiên, các thành viên khác trong team lại không có ai biết nhiều về C++, mọi người thiên về Java hơn.

Vì vậy, anh phải cố gắng thuyết phục bạn Senior Developer đó chọn hướng làm theo ngôn ngữ Java và kiến trúc framework Netty để cân bằng điểm mạnh và yếu giữa các thành viên với nhau, để cả team có thể cùng nhau làm framework server tốt hơn.

Sau buổi họp, anh sẽ review hệ thống, xem nó có chạy ổn định không, có phát sinh lỗi gì không.

Thông thường mỗi tuần anh sẽ có 2-3 buổi họp với các development team. Anh sẽ thảo luận với các Technical Leader của những team này về các dự định của họ, chẳng hạn như mở rộng hệ thống hay kết nối với đối tác mới. Anh sẽ phân tích và tư vấn cho các Technical Leader về những kế hoạch này.

Xem thêm Làm thế nào để trở thành một Technical Lead

Xem thêm Làm thế nào để trở thành một Technical Architect

Anh có tham gia code không?

Công việc của anh không yêu cầu anh phải code. Tuy nhiên, anh vẫn thường xuyên code bằng ngôn ngữ Java and C++ khi thiết kế hệ thống để duy trì kỹ năng kỹ thuật của mình.

Anh Dũng (đứng thứ 3, từ phải sang) chụp ảnh cùng team Developer nhân dịp kỷ niệm 10 năm thành lập Công ty M_Service (MoMo) năm 2017

Sai lầm lớn anh từng mắc phải trong công việc Software Architect là gì?

Chuyện này xảy ra ở công ty cũ, lúc anh vừa được “promote” lên làm công việc Software Architect. Anh thấy rất háo hức và tin là mình sẽ làm tốt vai trò này.

Lần đó anh được sếp giao cho một dự án lớn: thiết kế framework cho toàn bộ game server của công ty.

Cứ mỗi khi anh thiết kế xong một module, ví dụ như về chức năng hay cách hoạt động, anh gửi email báo cáo sếp. Sếp anh trả lời lại: “OK em”, “OK em”. Anh nghĩ sếp OK tức là duyệt rồi, nên sau đó chia việc cho 2 anh Senior Developer trong team làm.

6 tháng sau, khi team phát triển xong framework, anh trình sếp. Và ảnh làm anh bị sốc.

“Cái framework này không được rồi em ơi! Em design kiến trúc sai rồi. Cái này mà nếu apply, khi có nhiều user connect vào là treo luôn máy chủ đó!”

“Design database cũng có vấn đề luôn, có chỗ bị deadlock khi caching nè,” sếp anh nói tiếp.

Anh thật sự sốc. Lúc đó anh mới nhận ra là sếp anh không thực sự hiểu những đề xuất của anh mặc dù ảnh trả lời “OK”.

Anh bắt đầu thấy sợ. Anh nghĩ trong đầu: “Thôi chết rồi, cú này chắc khó sống rồi. Dự án này mất nhiều thời gian quá. Mọi người đang rất kỳ vọng vào nó, mà mình làm nó fail mất rồi.”

Anh cũng cảm thấy khó tha thứ cho bản thân mình. Vì cái lỗi này ngớ ngẩn quá. Chỉ cần anh vẽ mọi thứ ra rồi đưa sếp xem là không xảy ra rắc rối rồi.

Anh nghĩ chắc mình sẽ bị đuổi việc nên anh đã chuẩn bị sẵn tờ đơn xin nghỉ việc để trong hộc bàn. Anh định sẽ gửi cho sếp rồi nghỉ.

Nhưng sếp làm anh bất ngờ. Ảnh nói với anh: “Dự án lần này chú làm fail rồi. Nhưng thôi không sao, nó thuộc khối R&D (Research & Development), sẽ phục vụ lâu dài cho công ty. Nên anh chấp nhận delay, coi như là bài học cho chú trưởng thành.”

Thế là anh và 2 anh Senior Developer trong team sửa lại framework. Khoảng 3 tuần sau thì tụi anh hoàn thành.

Sau sự cố này, anh rút ra được bài học: phải tăng cường giao tiếp, giao tiếp là mấu chốt khi làm bất kỳ dự án nào. Anh mắc lỗi vì đã cho rằng sếp hiểu những đề xuất của anh nên mới duyệt.

Từ đó về sau, mỗi khi làm việc gì, anh đều đảm bảo là ngoài việc gửi email, hai bên phải cùng hiểu và cùng đồng ý trên một mô hình cụ thể, document cụ thể. Đến giờ, anh không còn mắc phải những lỗi về giao tiếp như vậy nữa.

3 lời khuyên anh muốn gửi tới các bạn muốn trở thành Software Architect là gì?

Dựa trên kinh nghiệm của bản thân mình, anh có vài lời khuyên cho các bạn trẻ.

1. Tìm hiểu thật kỹ và sâu về kỹ thuật, không chỉ đơn thuần về công nghệ mà còn về những thứ xung quanh công nghệ. Ví dụ, bên game có công nghệ mới là Unity. Bên cạnh Unity, bạn cũng nên tìm hiểu những thứ xung quanh nó như design, hiệu ứng, và plug-in.

2. Trung thành với con đường mà mình chọn. Khá nhiều bạn vạch ra con đường sự nghiệp và đích đến. Tuy nhiên sau vài năm code, một số bạn lại quyết định rẽ hướng, chuyển sang một công việc khác ngoài kỹ thuật.

Kết quả là các bạn phải đối mặt với nhiều khó khăn và rủi ro khi thử sức ở một lĩnh vực hoàn toàn mới. Bạn cũng phải từ bỏ các kinh nghiệm quý báu tích luỹ được ở lĩnh vực mình đã làm.

Các bạn đổi nghề vì nghĩ rằng: Ngoài 30 tuổi là nên nghỉ code. Nhưng quan điểm này là sai. Anh từng làm việc với những đồng nghiệp người Thụy Sỹ và Đức, họ làm Senior Developer đến khi về hưu. Họ thích tập trung nghiên cứu kỹ thuật chứ không muốn chuyển sang hướng khác.

3. Khi đã chọn làm việc trong một lĩnh vực nào đó, bạn nên tìm hiểu thật kỹ về nó.

Ví dụ, nếu bạn chọn làm trong ngành fintech, thì ngoài code ra, bạn phải biết những thứ xung quanh fintech. Chẳng hạn như bạn phải biết ngân hàng hoạt động ra sao, dòng tiền cân bằng trong một hệ thống ngân hàng như thế nào.

Bạn càng biết nhiều về lĩnh vực bạn tham gia thì bạn càng có thể thiết kế hệ thống chi tiết và cung cấp nhiều lựa chọn hỗ trợ hơn cho team và đối tác.

Giá trị của một Software Architect không phải ở chỗ họ giỏi về kỹ thuật, mà là tầm nhìn của họ về lĩnh vực họ đang làm. Khi hệ thống họ design đáp ứng càng nhiều mặt trong lĩnh vực họ đang làm, hệ thống đó càng có giá trị.

Từ vị trí Developer, cần phải trải qua những vị trí nào để trở thành Software Architect?

Nếu bạn thích trở thành Software Architect, con đường nghề nghiệp của bạn thường sẽ như thế này: Junior Developer -> Developer -> Senior Developer -> Team Leader -> Software Architect.

Tham khảo thêm: Lương ngành công nghệ thông tin

Theo anh, những kỹ năng và tố chất cần thiết để làm Software Architect là gì?

Anh nghĩ có 4 kỹ năng và tố chất quan trọng nhất:

1. Siêng năng, thường xuyên cập nhật kiến thức kỹ thuật

Nhiều người bên ngoài nghĩ Software Architect là công việc nhàn hạ, chỉ “vẽ đường cho hươu chạy”. Thực tế không phải vậy, mình phải thường xuyên cập nhật kiến thức, vì làm về kỹ thuật thì kiến thức thay đổi từng ngày, những công nghệ mới ra liên tục, thậm chí ngôn ngữ mới cũng ra đời liên tục, đòi hỏi phải tự nghiên cứu rất nhiều.

Khi mình biết thêm một kỹ thuật mới và áp dụng nó vào hệ thống của mình, nó sẽ mang lại giá trị cho bản thân mình, cho tập thể mình đang cống hiến, và cho những người xung quanh.

Ví dụ, nếu như mình chỉ biết mỗi C++ thì sẽ rất khó khăn nếu mình nhận được yêu cầu phát triển những phần mềm dựa trên ngôn ngữ khác như Java chẳng hạn.

Hơn nữa, khi mình biết nhiều công nghệ, mình sẽ có thể đề xuất nhiều lựa chọn hơn cho khách hàng.

2. Kỹ năng giao tiếp, truyền đạt

Khi design một framework nào đó, việc đầu tiên của Software Architect là phải nói cho các bạn Developer hiểu cái mình đang làm.

Chẳng hạn, thay vì ép buộc các bạn Developer làm theo hướng của mình, thì cần phải chịu khó giải thích cho các bạn hiểu lý do vì sao mình lại chọn công nghệ hoặc ngôn ngữ đó, có thể là vì trong team mọi người quen thuộc hơn, hoặc vì khả năng mở rộng hay do được cộng đồng hỗ trợ nhiều hơn.

3. Kỹ năng quan sát, phân tích vấn đề

Đôi khi Software Architect mắc sai lầm, design hệ thống rất hoành tráng, trong khi nhu cầu của khách hàng chỉ là một phần hoặc một chức năng trong đó thôi. Điều này dẫn đến kết quả là mất thời gian và công sức của cả team.

Ví dụ như nhu cầu của khách hàng chỉ là một website trưng bày hàng đơn giản, mình lại cố gắng thiết kế cả một trang web e-commerce với các tính năng hoàng tráng như tích hợp các phương thức thanh toán, phân quyền truy cập.

4. Khả năng dự đoán

Khi mình design, mình phải dự đoán được hệ thống:

• có khả năng mở rộng hay không
• khi có vấn đề thì phương án backup là gì
• các bạn Developer có dễ dàng code trên hệ thống mình design hay không.

Chẳng hạn, mặc dù bạn được yêu cầu design một website trưng bày hàng đơn giản như nêu ở trên, bạn vẫn nên nghĩ về khả năng nó được yêu cầu nâng cấp lên thành một website e-commerce trong tương lai.

Nếu có một điều mà anh ước rằng anh biết trước khi bắt đầu đi làm, thì đó là điều gì?

Anh ước mình biết là mentor rất quan trọng. Một người mentor tốt (một người có tầm nhìn và có tâm) sẽ ảnh hưởng rất lớn đến suy nghĩ, định hướng nghề nghiệp và cuộc đời của mình.

Anh may mắn gặp được 2 người mentor rất tốt.

Người đầu tiên là chị sếp trong công ty đầu tiên của anh. Chị ấy giúp anh vẽ career path rất chi tiết như anh đã kể. Chị ấy cũng dắt anh đi gặp anh Software Architect và anh Team Leader trong công ty để tham khảo thêm kiến thức.

Những gì chị ấy giúp anh thật sự rất ý nghĩa vì lúc đó anh chưa có định hướng sự nghiệp gì trong đầu cả. Thời đó, ngành IT còn khá mới ở Việt Nam. Nhiều sinh viên IT lúc đó, trong đó có anh, không biết chính xác mình sẽ làm gì sau khi tốt nghiệp. Anh chọn học ngành này vì anh thích máy tính từ nhỏ.

Người thứ hai là một giảng viên dạy về quản lý dự án ở Viện FMIT tại Quận 3. Thầy đã giúp anh hiểu được giao tiếp có thể giải quyết mọi vấn đề trong công việc.

Một câu thầy từng nói:

Công việc của một Project Manager 90% là giao tiếp, kết nối các thành viên trong team lại với nhau.

Thầy dạy anh cách để tìm sự đồng thuận của đối tác và đồng nghiệp khi thảo luận một vấn đề.

Các bạn sinh viên bây giờ có điều kiện hơn tụi anh khi xưa. Anh nghĩ các bạn nên tìm mentor cho mình từ khi còn ngồi trên ghế nhà trường, để giúp các bạn có thêm thông tin về ngành nghề và định hướng sự nghiệp.

Người mentor không cần ở đâu quá xa lạ. Họ có thể là những anh chị khóa trước hay các giảng viên trong trường.

Những resource anh muốn đề xuất cho các bạn muốn trở thành Software Architect là gì?

1. System Analysis and Design của Howard Gould: Cuốn sách này cho anh thấy toàn cảnh của việc phân tích và thiết kế một hệ thống, các bước cần phải làm là gì, và những lưu ý trong quá trình thiết kế và vận hành hệ thống.

2. Developing Information Systems của 6 tác giả và do James Cadle biên tập. Một cuốn sách khá hay về mô hình hoá hệ thống.

3. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development của Craig Larman. Đây là cuốn sách gối đầu giường của anh từ thời sinh viên, bao gồm tất cả những kiến thức cơ bản về lập trình.

Cảm ơn anh Dũng vì những chia sẻ về hành trình nghề nghiệp đầy thú vị và hữu ích. Chúc anh luôn thành công trong công việc!

Cảm ơn ITviec!

Nếu bạn nghĩ những chia sẻ này có thể giúp ích cho bạn bè hoặc đồng nghiệp, đừng quên nhấn nút Share bên dưới nhé!

Và đừng quên tham khảo việc làm Software Architect tại ITviec!