Khám phá về công việc thú vị của Product Architect | EXPERT TALKS

Product Archiect trong lĩnh vực IT ngày nay tại Việt Nam còn khá mới lạ. Thật chất vai trò và nhiệm vụ của Product Architect là gì, cần biết và cần làm thế nào để trở thành một Product Architect. Tất cả câu trả lời sẽ có trong bài chia sẻ của anh Minh Tâm với chủ đề "Khám phá về công việc thú vị của Product Architect"

Võ Minh Tâm

Võ Minh Tâm

Product Architect

Amaris Việt Nam

Giới thiệu

Anh Võ Minh Tâm hiện đang giữ vị trí Product Architect tại công ty Amaris Việt Nam, và đã có 13 năm làm việc trong lĩnh vực IT, với xuất phát điểm là một Developer. Từ những ngày đầu theo đuổi sự nghiệp IT, anh xem công việc Product Architect như một công việc mơ ước. Với chuyên môn hiện tại, anh Tâm sẽ chia sẻ một số thông tin trải nghiệm xoay quanh vị trí công việc của một Product Architect.

Chủ đề EXPERTS TALK:

"Khám phá về công việc thú vị của Product Architect​​".

 Công việc hiện tại của anh có vai trò trách nhiệm gì?

 Công việc cụ thể gồm những gì và quy trình thế nào?

Công việc của mình bắt đầu bằng việc tìm hiểu phân tích thực trạng của hệ thống, đặc biệt chú ý đến những điểm nghẽn gây cản trở các hoạt động nghiệp vụ tài chính. Kết quả của việc phân tích này sẽ được cô đọng trong một số tài liệu kiến trúc phần mềm được gọi là Baseline architecture artifacts. 

Ngoài ra, hoạt động kinh doanh thường phát sinh nhiều yêu cầu mới đối với các hệ thống phần mềm và hệ thống FMS cũng không ngoại lệ. Tiếp nhận những yêu cầu mới này, công việc của mình trước hết là phải hiểu đúng nhu cầu này, sau đó sẽ tiếp tiếp tục xem xét tính khả thi và tính đáp ứng của hệ thống hiện tại.

Trong một vài tình huống, hệ thống hiện tại cơ bản là đã đáp ứng được yêu cầu mới (...).
ngược lại thì công việc của mình lại tiếp tục với việc đưa ra giải pháp cho những yêu cầu mới này. Và kết quả của quá trình này một lần nữa cần được ghi nhận trong tài liệu Target architecture artifacts.

 Yêu cầu thay đổi với hệ thống xuất phát từ đâu?

Những yêu cầu về sự thay đổi đối với hệ thống không chỉ đến từ hoạt động kinh doanh. Nó còn đến từ sự phát triển công nghệ và hoạt động phát triển phần mềm. Bạn biết đấy, phần mềm về cơ bản là công cụ hoặc sản phẩm công cụ hỗ trợ hoạt động kinh doanh và không nên là thứ gây cản trở các hoạt động đó.

Nếu công cụ hoạt động không đúng theo chức năng yêu cầu, hay không thay đổi đủ nhanh để đáp ứng yêu cầu mới của hoạt động kinh doanh thì đó đều là những cản trở.

 Tiêu chí đánh giá chất lượng của một hệ thống được kiến trúc là gì?

Để làm được việc này, chất lượng của kiến trúc phần cần được đảm bảo tốt ở các tính chất:

• Availability - tính sẵn sàng,
• Interoperability - tính tương tác,
• Modifiability - tính khả chuyển,
• Usability - tính khả dụng,
• Performance - tính hiệu quả,
• Security - tính bảo mật,
• Testability - Khả năng kiểm định.

Nắm bắt xu hướng phát triển của công nghệ đưa ra sự lựa chọn hướng đi cho hệ thống mà mình chịu trách nhiệm cũng như xây dựng năng lực công nghệ phù hợp với hướng đi đó cũng là một công việc quan trọng.

 “Gap” mà anh đề cập đến là gì?

Bất kỳ hệ thống nào cũng có 1 thiết kế rồi. Hiện tại nó thế nào, tương lai nó thế nào thì cần xác định gap.

Khi đã có baseline và target, nó là cơ sở để phân tích Gap, nói nôm na là độ vênh giữa cái hiện tại đang có và cái muốn có ở tương lai. Từ đây mình lại lên migration plan, đây là tài liệu thể hiện các bước cụ thể quá trình dịch chuyển của hệ thống từ baseline đến target, biến target thành baseline.

Architect cũng giống như xây nhà, nhưng có thể transform, lúc đầu thì dựa vào mức độ phù hợp resource, chi phí sau đó thì có thể cải tiến sau.

 Product Architect khác gì với: Solution Architect, System architect, Technical Architect?

Hiện tại chưa có một định nghĩa phổ quát nào cho architect trong lĩnh vực phần mềm. Thông thường tùy vào mục đích yêu cầu của tổ chức, họ xác định phạm vi và trách nhiệm của SA, SA và TA khác nhau.

 Riêng Solution Architect yếu tố về Business sẽ cao hơn yếu tố về Technical vì công việc của họ thường sẽ làm việc với stakeholder là businessman, executive về nghiệp vụ & và quy trình xử lý nghiệp vụ, nhằm hiểu về chi phí để lập một hệ thống vận hành phần mềm, vì đa phần các công ty không chuyên về lĩnh vực IT sẽ không nắm rõ được với yêu cầu hệ thống mà họ muốn thực hiện sẽ tốn bao nhiêu chi phí, nên người làm về Solution Architect phải làm công việc này

 Tại sao hệ thống cần có người chịu trách nhiệm Architect?

Nếu xét riêng về cụm từ Architect - kiến trúc sư không thì chắc các bạn cũng hiểu sơ qua về lý do vì sao phải có chúng mình rồi!

Để dễ hiểu thì lấy ví dụ về việc xây nhà. Nếu bạn cần ngôi nhà cấp 4 đơn giản thì bạn không cần kiến trúc sư. người lại nếu xây một toà nhà, 1 căn biệt thự thì hiển nhiên là cần vì quy mô lớn hơn và phức tạp hơn nên đòi hỏi sự khả thi, chính xác, rõ ràng và cụ thể. 
Tương tự đối với việc xây dựng phần mềm.

Hiện tại, CNTT được ứng dụng khắp mọi lĩnh vực, để giúp hoạt động kinh doanh tốt hơn hiệu quả hơn, doanh nghiệp có nhu cầu sử dụng nhiều phần mềm khác nhau. Nếu vậy câu hỏi đặt ra là: mua hay xây dựng phần mềm, mua cái phần mềm gì ở đâu, phần mềm mới sẽ tích hợp với hệ thống có sẵn như thế nào,..

Architect sẽ là người trả lời cho câu hỏi kiểu này vì những người làm ở các bộ phần khác nhau như HR, Sale ... họ sẽ không đưa ra câu trả lời chính xác được vì họ chỉ nêu lên cái mình cần mà thôi, thường không có và cũng không cần có những kỹ năng IT.  
Developer cũng không thể trả lời câu hỏi kiểu này vì mối bận tâm thường nhật của họ là code.

 Nếu hệ thống không có Architect thì sẽ ảnh hưởng như thế nào?

Như đã đề cập ở câu trên về những lợi ích khi có vai trò Architect trong hệ thống và một sản phẩm phần mềm, thì ngược lại nếu không có sự tồn tại của vai trò này thì khi doanh nghiệp đó muốn cải tiến hoặc thay đổi bất cứ điều gì sẽ gặp nhiều khó khăn. 

Vi dụ: Hệ thống và sản phẩm sẵn có của doanh nghiệp toàn bộ đã khác hoàn toàn và không thể đáp ứng với bất kỳ định hướng tương lai của doanh nghiệp. Kết quả tệ nhất là có thể phải cải tổ toàn bộ, điều này sẽ gây tổn thất rất lớn đớn hoạt động của doanh nghiệp trong quá trình “đập đi xây lại”. Thời gian cũng sẽ bị kéo dài ra!

 Có phải doanh nghiệp nào cũng cần phải có Architect?

Theo quan điểm cá nhân mình thì tương tự như câu chuyện xây nhà, phần mềm đơn giản thì không cần doanh nghiệp bé, nhu câu nhỏ, hệ thống đơn giản thì không cần.

Đối với các doanh nghiệp mới thành lập có thể vai trò của vị trí này không hề lớn do nhu cầu hoạt động ban đầu và ngân sách mới đầu chưa cho phép. Nhưng họ cũng cần phải suy nghĩ và định hướng sau 5 năm nữa trên mục tiêu hoạt động của doanh nghiệp mình để xây dựng phần mềm hệ thống có thể dễ để cải tiến nhật có thể. Như thế, trong tương lai khi đã thực sự cần đến Architect thì cũng không mất quá nhiều thời gian và công sức để kiến trúc.

 Architect cần quan tâm/ xem xét ở góc độ nào khi kiến trúc hệ thống?

Theo kinh nghiệm của mình thì có 4 khu vực (domain) mà Architect cần chú ý đó là: Business (hoạt động của doanh nghiệp), Data (Dữ liệu), Application (Ứng dụng), Technologies (Nền tảng công nghệ - kỹ thuật).

Đầu tiên các bạn phải nghiên cứu nhu cầu lẫn yêu cầu của doanh nghiệp cần gì từ hệ thống phần mềm mình sẽ kiến trúc để nó đảm bảo hiệu quả trong hoạt động kinh doanh của doanh nghiệp.

Tùy vào system thì trọng số sẽ khác nhau. Hệ thống có thể transform, phát triển, giống như cơ thể sống, có thể tốt hơn từng ngày.

 Có khi nào anh phải “đập đi xây lại” hoàn toàn?

Lúc mới vào nghề thì mình thường có suy nghĩ này, nhưng thực tế lựa chọn đập đi xây lại là “thất sách” khi không còn cách nào nữa. 

Do lúc mới vào nghề chưa có kinh nghiệm, khi nhìn vào một hệ thống mình chỉ nghĩ chủ quan theo ý tưởng cá nhân mà cho rằng các hệ thống phải cải tổ toàn bộ, nhưng một Architect thực thụ và đã có kinh nghiệm thì sẽ tận dụng bất cứ những gì có sẵn có thể để kiến trúc. Rất hiếm khi phải sử dụng “thất sách”.

Việc tích lũy kinh nghiệm càng nhiều thì càng giúp mình có nhiều hướng kiến trúc hơn là chỉ nghĩ đến việc đập đi xây lại như lúc mới đầu.

 Chia sẻ một vài khó khăn và bài học kinh nghiệm với vai trò là Product Architect?

Mình thấy hầu hết các khó khăn thường xuất phát từ việc communication giữa con người với con người trong công việc. 

Ban đầu mình chọn ngành IT vì nghĩ đây là ngành mình không cần tương tác với con người nhiều chỉ cần làm việc một mình và hoàn thành đúng phận sự được giao.

Tuy nhiên trên thực tế, nếu các bạn muốn thăng tiến sự nghiệp lên vị trí cao hơn thì sớm muộn gì bạn cũng phải phối hợp và tương tác cùng mọi người và đó cũng là phương pháp mĩnh nghĩ giúp các bạn phát triển nhanh chóng.

Đúng là với vị trí hiện tại, Architect phải phối hợp với rất nhiều người từ phía công ty, client đến cả từng người trong team dự án. Đó thực sự là một thử thách không hề nhỏ đối với anh.

Thử thách này đòi hỏi bản thân mình cần phải hoàn thiện thêm rất nhiều kỹ năng liên quan đến giao tiếp. Mình phải làm sao để thuyết phục được cả hai phía mình làm việc về kiến trúc.

Thêm nữa, mình còn phải có thêm trách nhiệm hướng dẫn người khác. 
Trong môi trường làm việc chịu nhiều sự tác động thì bạn cần giữ được bình tĩnh và cân bằng cảm xúc của mình. Mình nghĩ bạn cũng cần phải thực sự kiên nhẫn với công việc của mình.

 Tóm lại thì Architect cần có những tố chất, kỹ năng gì?

• Về năng lực thì phải có Technical: bạn phải chăm chỉ rèn luyện technical thường xuyên, bám sát technical sẽ không làm chuyên môn cơ sở của bạn bị mai một mà lại hỗ trợ rất nhiều khi bạn kiến trúc.
• Tiếp tục lặp lại chính là sự kiên nhẫn, không bỏ cuộc.
• Có khả năng diễn đạt: trong giao tiếp khi nói chuyện trực tiếp và cả truyền đạt bằng văn bản.
• Đặc biệt cần có khả năng và thích thú với việc mô hình hóa những thông tin, ý tưởng đến mọi người.

 Vì sao anh chọn trở thành một Architect?

Điều này mình nghĩ là xuất phát từ sở thích của bản thân mình khi còn là một Developer. Khi đó mình mong muốn bản thân có thể tự tạo ra một bức tranh tổng quan về một hệ thống phần mềm và nhìn nó hoạt động hiệu quả trơn tru. Từ đó, Architect trở thành mục tiêu sự nghiệp để mình vươn đến.
Mong muốn trong tương lai sắp tới của mình là vị trí Enterprise Architecture.

 Anh có thể chia sẻ vài trang web hay mô hình cần học về Architect?

https://medium.com/swlh/whats-the-difference-between-solution-architecture-and-design-2a3c1507fcb8

=> Đây là 1 bài viết thú vị về Architect các bạn có thể tham khảo thêm

Về chủ đề Architecture, mình tự học và nghiên cứu theo hai nguồn chính.

1. Khóa học kiến trúc phần mềm từ học viện kỹ nghệ phần mềm từ Carnegie Mellon University: https://www.sei.cmu.edu/our-work/software-architecture/
2. TOGAF một framework kiến trúc từ Open Group: https://www.opengroup.org/togaf-standard-version-92-overview.