Software Architect: các loại Software Architect

Hãy tiếp tục loạt bài viết về Software Architect. Trong mọi lĩnh vực hoạt động nghề nghiệp đều có các chuyên ngành khác nhau. Ví dụ, trong y học có phẫu thuật, tim mạch, nhãn khoa, nha khoa, ...

Sự chuyên môn hóa là cần thiết khi lượng kiến ​​thức trong lĩnh vực này vượt quá giới hạn hợp lý. Và vì kiến ​​trúc phần mềm là một lượng lớn kiến ​​thức, điều cần thiết là phải giảm bớt nhiệm vụ của một người để có năng suất tốt hơn. Do đó, các loại kiến ​​trúc sư phần mềm sẽ được thảo luận trong bài viết này.

Loạt bài viết về Software Architect

1. Con đường trở thành kiến ​​trúc sư phần mềm.
2. Các bên liên quan (Stakeholder).
3. Phân loại Software Architect (bài viết này).
4. Các thuộc tính chất lượng trong Software Architecture.
5. Tài liệu về Software Architecture.
6. Chứng chỉ về Software Architecture.
7. Sách về Software Architecture.
8. Cheatsheet thiết kế hệ thống.

Phân loại Software Architect

Hãy xem xét sự phân loại sau:

Kiến trúc sư hệ thống (System Architect)

• Ảnh hưởng đến một hệ thống và xây dựng các kết nối bên trong nó.
• Tập trung vào thành phần kỹ thuật của quá trình phát triển.
• Giúp người quản lý dự án đưa ra các quyết định quản lý.
• Có kiến ​​thức sâu về các công nghệ.

Kiến trúc sư giải pháp (Solution Architect)

• Tham gia thảo luận công việc.
• Tạo kết nối giữa nhiều hệ thống.
• Cung cấp thông tin liên lạc giữa một số đội.
• Thiết kế kết nối giữa các hệ thống.
• Mã độc lập chỉ các nguyên mẫu giải pháp.
• Hoạt động như một người lính toàn cầu về kinh doanh và công nghệ.

Kiến trúc sư doanh nghiệp (Enterprise Architect)

• Ảnh hưởng đến mọi sự phát triển của công ty.
• Làm việc với các bản tóm tắt cấp cao của các hệ thống đã tạo.
• Cung cấp thông tin liên lạc kỹ thuật trong toàn công ty.
• Không làm việc trực tiếp với mã.
• Tập trung vào thành phần kinh doanh.
• Có tầm nhìn rộng về công nghệ.
• Sở hữu một số miền (kiến thức về nghiệp vụ kinh doanh).

Kiến trúc sư miền (Domain Architect)

Tôi thường nghe câu hỏi - liệu một kiến ​​trúc sư có thể tồn tại trong các ứng dụng di động không? Và câu hỏi này gây được tiếng vang lớn đến nỗi thật khó để có được một câu trả lời hợp lý cho nó. Có thể có một kiến ​​trúc sư chỉ biết ngăn xếp công nghệ JavaEE, hoặc chỉ .NET? Những chuyên gia này nên được gọi như thế nào? Công nghệ dẫn đầu hay cái gì khác?

Trong khi suy nghĩ, làm thế nào để trả lời câu hỏi này, tôi đã thay đổi suy nghĩ của mình vài lần, trong sự nghiệp của mình. Trong các cuộc trao đổi của tôi với các chuyên gia giữ chức vụ kiến ​​trúc sư chuyên môn cao, họ đương nhiên cố gắng đưa ra những lý lẽ để biện minh cho quan điểm của mình. Những người khác nói rằng điều đó là vô nghĩa và bạn nên gọi một người như vậy là bất cứ thứ gì, nhưng không phải là kiến ​​trúc sư.

Hãy xem xét một tình huống trong đó một công ty khởi nghiệp ba người có một CEO (giám đốc điều hành), một CTO (giám đốc kỹ thuật) và một CMO (giám đốc tiếp thị). Có thể có một nhân viên kỹ thuật cho một nhà phát triển không? Hay một nhân viên tiếp thị cho một bộ phận của một chuyên gia? Có thể xác định xem một cấp bậc hư cấu là để theo đuổi một danh lợi hay một nhu cầu thực sự?

Chúng ta hãy cố gắng trả lời những câu hỏi này. Có đăng thì phải có mô tả công việc mà chuyên viên làm. Đối với các kiến ​​trúc sư, chúng tôi đã mô tả chúng trong bài viết trước.

Trong các dự án lớn, có những bài viết có hướng dẫn trùng với những gì được mô tả trong bài viết trên. Nếu dự án bao gồm một hoặc nhiều nền tảng, thì mỗi nền tảng yêu cầu một chuyên gia đóng vai trò là kiến ​​trúc sư miền và thực hiện các nhiệm vụ sau:

• Xác định các bên liên quan trong dự án. Điều quan trọng cần lưu ý là kiến ​​trúc sư miền nên chọn các bên liên quan có ảnh hưởng đến nền tảng của mình và làm việc với họ.
• Xác định các yêu cầu kinh doanh và các yêu cầu của các bên liên quan trong dự án. Nếu kiến ​​trúc sư tìm thấy các bên liên quan theo nền tảng cụ thể, thì anh ta / cô ta sẽ tìm thấy các yêu cầu với các hạn chế, cụ thể cho miền.
• Thiết kế toàn bộ hệ thống dựa trên các yêu cầu đã nhận. Đối với một kiến ​​trúc sư miền, điều quan trọng hơn không phải là thiết kế toàn bộ hệ thống, mà là tích hợp nền tảng vào phác thảo dự án. Ngoài ra, để xem xét các kết nối giữa các thành phần ảnh hưởng đến nền tảng.
• Lựa chọn công nghệ để thực hiện từng thành phần và kết nối giữa các thành phần. Không giống như các kiến ​​trúc sư cấp cao hơn, một kiến ​​trúc sư miền, theo quy luật, có tác động đáng kể nhất đến việc lựa chọn công nghệ ứng dụng cho nền tảng của cô ấy / anh ấy. Ví dụ: trong các ứng dụng dành cho thiết bị di động, kiến ​​trúc sư giải quyết các vấn đề như loại thử nghiệm nào sẽ sử dụng trong dự án, liệu nó có cần tạo mã hay không, cách tổ chức các lớp dịch vụ và trình bày, những mẫu kiến ​​trúc nào cần sử dụng và tại sao nó nói chung là cần thiết. cho dự án.
• Viết tài liệu dự án và hỗ trợ nó. Nếu có một kiến ​​trúc, thì nó nên được ghi lại. Ngay cả trong điều kiện của một nền tảng. Như đã viết trong cuốn sách “Kiến trúc phần mềm trong thực tế”, nếu kiến ​​trúc không được lập thành văn bản, thì nó không phải là kiến ​​trúc. Trong phát triển di động, nó có thể là một sơ đồ để làm việc với cơ sở dữ liệu, mô tả các tương tác mạng, sơ đồ lớp, v.v.
• Tạo ra các tiêu chuẩn phát triển thống nhất trong công ty. Điểm này đặc biệt phù hợp với một kiến ​​trúc sư miền vì tất cả các tiêu chuẩn thường được phát triển cho một nền tảng cụ thể.
• Kiểm soát kiến ​​trúc trong lần lặp lại tiếp theo của bản phát hành hệ thống.

Một kiến ​​trúc sư miền phải kiểm soát toàn bộ chu trình phát triển sản phẩm. Và là người gần nhất với thành phần kỹ thuật của nền tảng, đồng thời, nhìn nó như một bức tranh toàn cảnh, kiến ​​trúc sư hoàn toàn chịu trách nhiệm về chất lượng của sản phẩm trên một nền tảng cụ thể.

Do đó, có một số lượng lớn các loại kiến ​​trúc sư miền khác nhau:

Bức tranh chỉ cho thấy một phần nhỏ của kiến ​​trúc sư miền. Trên thực tế, có rất nhiều loại kiến ​​trúc sư miền, cũng như các ngăn xếp công nghệ khác nhau.

Mặt khác, chỉ cần bổ sung chức vụ của kiến ​​trúc sư khi đã rõ trách nhiệm tương ứng. Nếu bạn có một dự án từ một nền tảng và hai nhà phát triển, thì việc thêm một vị trí của kiến ​​trúc sư là không cần thiết và một trong các nhà phát triển có thể thực hiện các nhiệm vụ này.

Phát triển từ kiểu kiến ​​trúc sư này sang kiểu kiến ​​trúc sư khác

Để xem xét chủ đề này, chúng ta hãy sử dụng khái niệm về mô hình T-Shape. Nó giả định rằng một chuyên gia có thể phát triển theo chiều dọc và chiều ngang. Tăng hàng dọc có nghĩa là cải thiện các kỹ năng trong chuyên môn của bạn, tức là kiến thức sâu. Tăng hàng ngang có nghĩa là có được kỹ năng và kinh nghiệm trong nhiều lĩnh vực miền và nền tảng công nghệ, nghĩa là trải nghiệm rộng. Bằng cách kết hợp hai tính năng này, bạn có thể nhận được thông tin về mức độ kiến ​​thức và kinh nghiệm hiện tại của nhân viên bất kỳ lúc nào.

Ví dụ: mức tăng trưởng cấp nhà phát triển được mô tả bằng thanh dọc. Nhà phát triển học kiến ​​thức mới về các khuôn khổ, ngôn ngữ và công cụ phát triển trong giới hạn của một ngăn xếp kỹ thuật. Tuy nhiên, kiến ​​trúc sư không chỉ phải có kiến ​​thức sâu rộng mà còn phải có hiểu biết rộng về kỹ thuật trên nhiều nền tảng.

Đồng thời, sự phát triển của kiến ​​trúc sư liên quan chặt chẽ đến số lượng nền tảng mà anh ấy / cô ấy có chuyên môn lý thuyết và chủ yếu là thực hành, và cũng với số lượng lĩnh vực mà anh ấy / cô ấy biết. Mục tiêu phát triển nghề nghiệp của kiến ​​trúc sư là hình thành chuyên gia “m” - đa nền tảng & đa lĩnh vực.

Tại thời điểm này, chúng ta hoàn thành việc xem xét các loại kiến ​​trúc sư. Trong phần tiếp theo, chúng ta sẽ xem xét các thuộc tính chất lượng và cách sử dụng chúng trong kiến ​​trúc phần mềm.

Career Path • Software Architecture