06  Nghề Architect trong IT?

Wow, đây là một câu hỏi từ một bạn Intern ở chỗ iGà làm hỏi làm Architect là làm gì? Bài này iGà viết chia sẻ theo góc nhìn và kinh nghiệm đi làm cá nhân. Tùy vào tổ chức, cấp độ của các bạn làm việc có thể rất khác nhau về Architect. Đôi khi ít hơn, đôi khi nhiều hơn. Mong được sự góp ý của các bạn thêm ở phần comment.

Ở bài trước iGà đã phân tích sự khác nhau giữa Solution Architect và Solution Consultant là gì rồi. Đi làm một vài năm khi va vấp các dự án quy mô dần lớn, đặc biệt làm các dự phán phức tạp về phần mềm chúng ta có thể gặp rất nhiều role liên quan Architect như là:

  1. Software Architect
  2. Technical Architect
  3. Solution Architect
  4. Data Architect
  5. Application Architect
  6. Business Architect
  7. Enterprise Architect.

Ở bài này iGà mong sẽ chia sẻ một cái nhìn chung về các role architect này. Việc mô tả công việc chính và hàng của các role architect này còn phụ thuộc khá nhiều vào lĩnh vực và đặc thù sản phẩm dịch vụ của tổ chức mà các bạn đang làm việc hoặc hợp tác.

Dù ở bất kỳ vị trí Architect (Kiến trúc sư) thì sự hiểu biết kỹ thuật và nghiệp vụ (Business) là việc hết sức quan trọng để nắm yêu cầu / mong đợi / pain points, từ đó phân tích đưa ra cách giải quyết bài toán đó bằng cách sử dụng là công nghệ.

Vậy chúng ta có một công thức  tạo nên Architect như sau:

Architect = Technology + Strategy

Deep dive về Technical thì có Technical Architect / Software Architect người am hiểu từng thành phần của phần mềm, cách thức tương tác giữa các components, các interface, cách tổ chức các pattern trong cốt, hay thậm chí các cấu phần phần cứng để đáp ứng cho phần mềm.

Sự khác nhau giữa Software Architect và Technical Architect:

  1. Software Architect tập trung vào một công nghệ. VD: Lập trình backend sử dụng Django Framework.
  2. Technical Architect tập trung vào nhiều hơn một công nghệ. VD: Trong phần mềm có nhiều layer về Backend, Database, Front End cần một bạn Technical Architect thiết kế và tối ưu theo workload của phần mềm.

Có business sense và cái nhìn tổng quan hướng nghiệp vụ hơn thì có Business Architect. Họ nắm nhu cầu của thị trường, doanh nghiệp, lợi ích của từng giải pháp trong một bức tranh tổng thể (porfolio).

Solution Architect (SA) là làm gì?

Solution Architect là vị trí cầu nối giữa Enterprise Architect và Technical Architect. Xem như là một cầu nối rất chặt chẽ đem lại sự thành công dự án. Thông thường Solution Architect sẽ cần đặc thù cho một giải pháp cụ thể (A specific Solution), ví dụ như: Solution Architect cho giải pháp contact center, Solution Architect cho giải pháp thu hồi nợ collection, Solution Architect cho giải pháp ví điện tử…

Để làm việc này một cách thành công, SA cần thu thập và phân tích từ nhiều góc nhìn: Business, Information và Technical. Từ đó đưa ra các quyết định công nghệ và giải pháp tối ưu nhất.

SA đóng vai trò gắn liền với dự án từ giai đoạn thiết kế giải pháp, phát triển giải pháp (develop), và triển khai giải pháp (implementation), thậm chí các quy trình liên quan kiến trúc với phía khách hàng (thông thường mỗi khách hàng ở VN đều có một quy trình tuân thủ về hệ thống kiến trúc trước khi golive đưa vào sử dụng). SA làm việc với các team nội bộ và bên ngoài (khách hàng, đối tác) để đóng vai trò kết nối về công nghệ.

Đây là một ví dụ về Solution Architect khi thiết kế một giải pháp thu cho vay:

Ở ví dụ này chúng ta hãy cùng xem ở mỗi vị trí Architect khác nhau sẽ khác nhau về standpoint thế nào nhé:

  • Business Architecture: How does a customer apply for a loan online?
  • Data Architecture: What information is needed to enable loan risk assessment and processing? How to manage customer info with maximum security, integrity and optimal cost, performance, reliability, consistency?
  • Application Architecture: What UX, process management, and functional system components/services are needed to enable customer loan application via mobile and web devices?
    Integration Architecture: How will the distributed application component and services talk to each other?
  • Security Architecture: How to properly verify and authenticate customer identity? How to ensure that customer data is secure in a distributed environment? How to prevent unauthorized data access and data theft over the wire?
  • Technology Architecture: How to configure supporting infrastructure for high availability and recoverability in case of system or facility failure?
  • DevOps Architecture: How to enable rapid product delivery and continuous maintenance?

Bạn có thể tham khảo sau đây là một số mô tả công việc chính của một SA:

  • Lead teams made up of cross-functional members (both IT and non-IT) for technical architecture discussions and High Level and Systems design aspects.
  • Collaborate with the team members to arrive at the Solution architecture/High level Design with urgency without drawing the teams into protracted discussions leading members astray.
  • Use strong verbal and written communication skills, including ability to explain complex concepts in appropriate terms to suit the audience with varying technical prowess.
  • Communicate ideas, design in clear and concise manner using the graphical tools such as PowerPoint, Visio and other Enterprise Architecture depicting tools.
  • Define the “Current State” and contrast that to the “Future State” as well as the path/roadmap to get there.
  • Investigate and solve complex technical problems and data discrepancies as well as develop solutions architecture that aligns tactical solutions (near-term) with Strategic goals/objectives (longer-term).
  • Work closely with Business stakeholders, IT Systems.

Còn đây là một ví dụ của Software Architect khi làm việc:

 

  • Domain Object Model Class Diagram is essential in defining a consistent data format for information management, persistence, and sharing.
  • Services Component Diagram breaks down system functional services into self-contained API components that can be implemented as microservices
  • Sequence Diagram demonstrates how software modules and distributed components integrate with one another in a context of each use case.
  • Deployment Diagram is necessary to demonstrate software deployment on compute and middleware infrastructure in order to engineer a DevOps pipeline, manage software/infrastructure dependencies, and design for performance and failure

Kết bài

Hy vọng qua bài này các bạn có cái nhìn về các nghề Architect khác nhau. Đối với một số tổ chức nhỏ họ ko phân nhiều vai trò Architect như này. Hay thậm chí một số hình tổ chức lại tổ chức Solution Consultant làm front end tương tác giống như Enterprise Architect nhưng ở góc độ nhỏ hơn, còn Solution Architect nằm sau đóng vai trò bao gồm cả Technical Architect và Software Architect. Nên đây là một chủ đề luôn gây nhiều tranh cãi tùy thuộc mô hình tổ chức của doanh nghiệp các bạn làm việc (Business Model).

Quan điểm cá nhân, là một architect giỏi bạn cần ko ngừng trau dồi về công nghệ và nghiên cứu thị trường. Việc chuyển đổi giữa các role là tùy vào sự đòi hỏi công việc, có lúc cần high level, có lúc cần deep dive, có lúc lại phải là cầu nối. Kỹ năng cần nhất của một người lao động đó là sự thích nghi với thay đổi (Adaptive).

Bài cũng đã khá dài, có nhiều đoạn iGà ko diễn tả bằng tiếng Việt vì sợ tối nghĩa. Nếu đoạn nào chưa hiểu hoặc có chia sẻ, iGà rất cảm kích về điều này. Cảm ơn cả nhà.

iGà

[email protected]

 

Topics #architect #business architect #data architect #enterprise architect #software architect #solution architect #technical architect