Tham khảo năm sơ đồ kiến trúc kỹ thuật với các hướng dẫn để dễ dàng thiết kế và triển khai giải pháp số.

Cách vẽ Sơ đồ Kiến trúc Kỹ thuật hữu ích

Photo by Alex wong on Unsplash

Một sơ đồ kiến trúc kỹ thuật (technical architecture diagram) cung cấp cái nhìn toàn cảnh về cơ sở hạ tầng của tổ chức bạn. Sơ đồ minh họa cách các thành phần (components) trong một hệ thống tương tác với nhau ở quy mô lớn.

Có nhiều loại sơ đồ kiến trúc phục vụ các mục đích khác nhau. Thông thường, một kiến trúc sư giải pháp số (digital solution architect) sẽ phác thảo các sơ đồ kiến trúc cấp cao (high-level architecture diagrams) để cung cấp thiết kế giải pháp công nghệ. Có hai lợi ích chính của một sơ đồ kiến trúc:

1. Chúng giúp hiểu rõ — cung cấp cái nhìn tổng quan về các hệ thống có sẵn và sự tương tác, điều này giúp dễ dàng đánh giá tác động từ các thay đổi.
2. Chúng cải thiện việc giao tiếp và cộng tác với nhau — sắp xếp kế hoạch thực hiện giữa các dự án và các bên liên quan (stakeholders) để giảm khoảng cách trong giao tiếp. Một sơ đồ kiến trúc hữu ích nên giải quyết từng nhu cầu của các bên liên quan ở một mức độ nhất định.

Trong bài viết này, tôi sẽ đề cập đến năm sơ đồ kiến trúc đã giúp tôi rất nhiều trong việc thiết kế và triển khai giải pháp số. Đó là:

• Sơ đồ Kiến trúc Ứng dụng (Application Architecture Diagram)
• *Sơ đồ Kiến trúc Tích hợp (Integration Architecture Diagram)
• Sơ đồ Kiến trúc Triển khai (Deployment Architecture Diagram)
• Sơ đồ Kiến trúc DevOps (DevOps Architecture Diagram)
• Sơ đồ Kiến trúc Dữ liệu (Data Architecture Diagram)

Một lưu ý nhanh: Các thực hành tốt nhất (best practices) thường khác nhau giữa các tổ chức. Tôi sẽ chia sẻ những gì đã mang lại hiệu quả cho tôi trong quá trình triển khai các giải hạ tầng đám mây - từ góc độ AWS Cloud.

Cũng như mã phần mềm, tính hữu ích của một kiến trúc được vẽ-tốt (well-drawn architecture) thường bị bỏ qua cho đến khi hệ thống trở nên lớn và phức tạp.Một sơ đồ kiến trúc hữu ích có sự kết hợp của ba thành phần sau:

1. Tiêu chuẩn hóa luồng quy trình thông tin (Standardised process flow of information), ví dụ đọc từ trên-xuống — điều này cho biết cách các thành phần tương tác với nhau.
2. Cung cấp đầy đủ thông tin thành phần với các nhóm hợp lý (Provides sufficient information in components with logical groupings) — điều này chỉ ra hạn chế ở đâu, ví dụ ranh giới mạng (network boundaries).
3. Bao gồm các chú thích với nhiều thông tin hơn (Includes annotations with more information) — chi tiết hơn ở từng bước để dễ dàng triển khai các giải pháp, ví dụ miêu tả quy trình.

Tôi sẽ cố gắng cung cấp một số ngữ cảnh và ví dụ về cách mỗi sơ đồ được sử dụng để giúp thiết kế và triển khai giải pháp.

FYI: Các sơ đồ mẫu minh họa bên dưới được tạo bằng công cụ miễn phí: https://draw.io/.

1/ Sơ đồ Kiến trúc Ứng dụng (Application Architecture Diagram)

Sơ đồ Kiến trúc Ứng dụng bao gồm tổng quan ở mức độ cao (high-level overview) của các thành phần và tương tác cơ bản trong hệ thống, ví dụ microservices, databases, v.v…

Sơ đồ Kiến trúc Ứng dụng chủ yếu đề cập đến “What” liên quan đến hệ thống.

Cách sử dụng phổ biến của sơ đồ này là để dễ dàng lập kế hoạch và triển khai giải pháp dưới dạng đánh giá tác động của việc nâng cấp, thay thế hoặc hợp nhất các ứng dụng hiện có. Với các ứng dụng mới liên tục được phát hành và hứa hẹn tăng hiệu quả, giảm chi phí (đặc biệt trong không gian container hóa), điều quan trọng là có một cái nhìn tổng quan về các ứng dụng trong hệ thống của bạn.

Chẳng hạn, các ứng dụng của bạn có thể ở trong nhiều cụm container (container clusters), như bare-metal Kubernetes, AWS ECS, … vì nhiều lý do; và bạn có nhiệm vụ củng cố và hợp nhất các ứng dụng để chỉ còn dùng một nền tảng quản lý container, ví dụ bare-metal Kubernetes để tối ưu hóa chi phí và hợp lý hóa hoạt động trên môi trường multi-cloud. Khi mới bắt đầu, một số câu hỏi sau đây có thể xuất hiện trong đầu bạn:

• Những loại ứng dụng trong từng cụm (What types of applications are in each cluster)?
• Các phụ thuộc và tương tác của ứng dụng là gì (What are the applications’ dependencies and interactions)?
• Kết quả dự định và trạng thái mong muốn của kiến trúc là gì (What’s the intended outcome and desired state of the architecture)?

Sơ đồ ví dụ dưới đây minh họa trạng thái hiện trạng (as-is state) của kiến trúc ứng dụng. Các thành phần trong “Logic Layer” của sơ đồ giải quyết hai điểm đầu tiên.

Sơ đồ mẫu của tác giả

Với các câu hỏi được giải quyết, giải sử kết hoạch là hợp nhất ứng dụng AWS ECS cluster vào Kubernetes cluster, có một số mục hành động yêu cầu đầu vào (inputs) từ các bên liên quan khác nhau dựa trên sơ đồ.

Ví dụ, bạn có thể liên lạc với project manager để kiểm tra các loại tích hợp đối tác (types of partner integrations), ví dụ internal/external, với DevOps để kiểm tra keys và quản lý cấu hình, và với các kỹ sư hệ thống để kiểm tra cách tổ chức các clusters … để hỗ trợ phân tích tác động.

Sau khi có được thông tin liên quan, bạn sẽ có thể thiết lập trạng thái mong muốn/tương lai (desired/to-be state) của kiến trúc và triển khai kế hoạch factoring trong các cân nhắc quan trọng.

Các thành phần hữu ích trong sơ đồ này:

• Các thành phần được nhóm thành các lớp và bối cảnh hạn chế (Grouped components into layers and bounded contexts) —mỗi ranh giới có thể gợi ý một nhóm stakeholder khác, ví dụ các kỹ sư dữ liệu cho lớp dữ liệu (data layer), nhóm nền tảng cốt lõi (core platform team) cho các dịch vụ chung/chia sẻ… cung cấp ý tưởng ai sẽ tham gia lập kế hoạch/thảo luận.
• Chú thích với thông tin bổ sung (Annotations with additional information) — cung cấp chi tiết về cách từng cluster được quản lý và tổ chức, ví dụ dựa trên bản chất của ứng dụng và mối quan tâm về bảo mật, … có lẽ được bao gồm để dễ dàng thảo luận.
• Chi tiết và ngữ cảnh của ứng dụng (Application details and context) — nêu rõ tên và loại ứng dụng để cung cấp ý tưởng về cách các ứng dụng được tổ chức.

Bạn có thể tải sơ đồ mẫu bên trên  ở đây.

2/ Sơ đồ Kiến trúc Tích hợp (Integration Architecture Diagram)

Một Sơ đồ Kiến trúc Tích hợp khá tương tự với Sơ đồ Kiến trúc Ứng dụng, ngoại trừ việc nhấn mạnh thêm vào các giao thức tích hợp giữa các thành phần, ví dụ Batch, Events, REST/SOAP/XML, v.v…

Sơ đồ Kiến trúc Tích hợp đề cập đến “How” liên quan đến tính liên kết cùa các thành phần trong hệ thống.

Một cách ứng dụng phổ biến của sơ đồ này là để dễ dàng cho việc tích hợp của các hệ thống bên ngoài bởi các đối tác hoặc các hệ thống nội bộ khác. Ngày nay, với việc các doanh nghiệp thiết lập quan hệ đối tác mới thông qua hệ sinh thái để tạo ra giá trị chung, bạn có thể phải thường xuyên làm việc với các đối tác để tích hợp các hệ thống với nhau, ví dụ e-commerce, thanh toán, đặt phòng khách sạn, chuyến bay…

Ví dụ, có một đối tác có ứng dụng du lịch muốn đưa danh mục sản phẩm của bạn lên ứng dụng của họ để tăng sự lựa chọn cho người tiêu dùng. Bạn có nhiệm vụ làm việc với kiến trúc sư giải pháp của đối tác để tạo điều kiện thuận lợi cho việc tích hợp các hệ thống nhằm cung cấp dịch vụ của bạn cho họ. Đối tác thích dùng dịch vụ thông qua REST APIs.

Một số trong những câu hỏi này có thể đến với tâm trí bạn:

• Các dịch vụ hiện có của tôi được tổ chức và khám phá bên trong/bên ngoài thế nào (How are my services currently organised and exposed internally/externally)?
• Đối tác muốn tích hợp với hệ thống của tôi như thế nào, ví dụ mạng nội bộ, giao thức… (How does the partner want to integrate with my system, e.g. internal networks, protocols, etc.)?
• Tôi bảo mật, theo dõi và quản lý việc tích hợp các dịch vụ của tôi như thế nào (How do I secure, track and manage the integration of my exposed services)?

Sơ đồ tích hợp dưới đây minh họa (ở high level) việc giao thức truyền thông hiện có giữa các thành phần. Bạn cũng sẽ thấy cách một số dịch vụ được tiếp xúc với các developers bên thứ ba thông qua External API Gateway ở logic layer

Sơ đồ của tác giả

Từ sơ đồ trên, bạn nhận ra rằng hệ thống được thiết kế hướng-API (API-driven), giúp dễ dàng tích hợp. Hầu như toàn bộ dịch vụ đều được tiếp xúc (exposed) thông qua dịch vụ web, bao gồm các thành phần lưu trữ dữ liệu.

Bước kế tiếp là kiểm tra với đối tác về danh sách dịch vụ mà họ yêu cầu, cách thức (mode) tích hợp, ví dụ internal hay external, và tham chiếu chéo (cross-reference) các yêu cầu với những dịch vụ được cung cấp thông qua danh mục API. Ngoài ra còn có những mục hành động tiếp theo, như làm việc với các kỹ sư hệ thống để quyết định về bảo mật và giám sát các dịch vụ được tiếp xúc.

Đôi khi, có thể có những khoảng trống (gaps) như đối tác muốn tích hợp bên ngoài, nhưng dịch vụ của bạn chỉ có thể tiếp xúc nội bộ (internal), hoặc thiếu một số thuộc tính dữ liệu (data attributes) cụ thể. Trong những trường hợp như vậy, những nỗ lực phải được tính đến để đáp ứng các yêu cầu. Sơ đồ tích hợp phải làm nổi bật chi tiết, như internal services/APIs, link to API catalogue, … để nhanh chóng xác định những lỗ hổng.

Các thành phần hữu ích trong sơ đồ này: Bạn có thể tải sơ đồ trên tại

• Các thành phần được nhóm thành các lớp và bối cảnh hạn chế (Grouped components into layers and bounded contexts) — một dấu hiệu của internal/external API gateways and services
• Chú thích với thông tin bổ sung (Annotations with additional information) — các liên kết tham chiếu đến danh mục API nơi có thể thu thập chi tiết các thuộc tính dữ liệu để đánh giá các lỗ hổng.
• Chi tiết và bối cảnh của ứng dụng (Application details and context) — các dịch vụ được đặt tên phù hợp để cho phép nhanh chóng đánh giá yêu cầu với thực tế.

Bạn có thể tải sơ đồ trên tại đây.

3/ Sơ đồ Kiến trúc Triển khai (Deployment Architecture Diagram)

Một Sơ đồ Kiến trúc Triển khai bao gồm các ranh giới mạng (network boundaries) và các thành phần phần cứng/phần mềm cơ sở hạ tầng. Kích thước và số lượng của các thành phần thỉnh thoảng cũng được chỉ định để dễ dàng lập kế hoạch.

Kiến trúc Triển khai chủ yếu giải quyết “Where” và “How many” liên quan đến các thành phần trong hệ thống.

Một sử dụng phổ biến của sơ đồ này là tạo thuận lợi để nâng cấp ứng dụng và dịch vụ để xử lý tải trọng bổ sung (additional load) hoặc tối ưu hóa tài nguyên. Theo thời gian, khi có nhiều người dùng hơn, đến từ nhiều nơi trên thế giới, bắt đầu sử dụng ứng dụng và dịch vụ của bạn, các tài nguyên hiện có của bạn có thể không xử lý nổi tải trọng và quy mô (scale and load) tăng thêm.

Chẳng hạn, API gateway của bạn hiện được triển khai trong một EC2 instance lớn duy nhất (t2.xlarge) và gần đây đang đối mặt với sự gián đoạn dịch vụ không liên tục do hiệu suất. Bạn có nhiệm vụ chuyển đổi API gateway thành thiết lập (với các máy mới) trong nhiều availability zones (AZ) để cải thiện tính khả dụng của gateway. Một vài câu hỏi có thể xuất hiện trong đầu của bạn là:

• Có bao nhiêu AZ (How many AZ)?
• Phiên bản mới được triển khai ở đâu (Where to deploy the instance)?
• Phiên bản mới sẽ lớn đến mức nào (How large would the new instance be)?

Kiến trúc triển khai bên dưới minh họa việc thiết lập hiện tại của mạng và các thành phần. Có hai AZs cho ứng dụng hiện tại với API gateway instance ở ap-southeast-1.

Sơ đồ của tác giả

Dựa trên sơ đồ trên, bạn có thông tin về kích thước của API Gateway instance hiện tại, ví dụ (t2.xlarge), để dùng như một tiêu chuẩn cho kích thước instance mới. Ngoài ra, còn có một database instance tương ứng được gắn thẻ cho API Gateway instance ở cùng availability zone.

Sơ đồ cũng nhắc nhở các thảo luận xa hơn về vị trí của instance mới, như private subnet-2b hoặc 2c hoặc liệu có thể lập kế hoạch tiếp theo về việc hợp nhất một API gateway trung tâm cho tất cả các dịch vụ trên AWS Core Platform để tập trung hóa việc quản lý API.

Bước kế tiếp sẽ là ước tính ảnh hưởng dựa trên các kế hoạch triển khai khác nhau, như tập trung hóa hoặc phi tập trung việc quản lý API,… và đề xuất để ban quản lý và các bên liên quan tương ứng tiến hành đánh giá.

Thường có nhiều cách tiếp cận khác nhau để giải quyết các vấn đề hiệu suất như vậy. Nếu bạn ở một tổ chức lớn, quan trọng là phải điều chỉnh cách tiếp cận thông qua một ủy ban kiến trúc trung tâm để quản trị kiến trúc phù hợp.

Các thành phần hữu ích trong sơ đồ này:

• Ranh giới mạng (Network boundaries) — thể hiện sự cô lập của các thành phần và hàm ý kết nối tiềm ẩn.
• Kích thước phiên bản (Instance sizing) — cho biết kích thước của máy để dễ dàng tối ưu hóa và tiêu chuẩn hóa tài nguyên với các yêu cầu về hiệu suất.
• Hiển thị các phần của tích hợp bên ngoài (Show parts of external integration) — thể hiện phần mở rộng của hệ thống (nếu có) với các hệ thống và mạng khác để chỉ ra một bức tranh lớn hơn và tạo điều kiện sắp xếp hợp lý tài nguyên, như common/shared services, … và các cơ hội cộng tác.

Bạn có thể tải sơ đồ trên tại đây.

4/ Sơ đồ Kiến trúc DevOps (DevOps Architecture Diagram)

Một Sơ đồ Kiến trúc DevOps thường bao gồm các thành phần hệ thống, quy trình và môi trường. Loại sơ đồ này giống như sơ đồ-luồng-quy-trình (process flow diagram) minh họa các hoạt động để chuyển một codebase/app sang production.

Kiến trúc DevOps chủ yếu giải quyết “How” và “What” liên quan đến việc tối ưu hóa các quy trình và luồng triển khai.

Một ứng dụng chung của sơ đồ này là tạo điều kiện thuận lợi để cải tiến các quy trình liên quan đến triển khai ứng dụng. Những thay đổi liên tiếp của kiến trúc hệ thống và các cải tiến đối với công cụ/phương thức (tools/methods) triển khai, ví dụ Containers, Serverless, … thúc đẩy nhu cầu thích nghi những quy trình và kiến trúc DevOps hiện có để theo kịp thời đại.

Chẳng hạn, quản lý ứng dụng, ví dụ configs … cho nhóm của bạn hiện chưa được chuẩn hóa trên các nền tảng, và bạn có nhiệm vụ khám phá việc triển khai một công cụ mới (Habitat) để quản lý hiệu quả các ứng dụng. Một số câu hỏi có thể xuất hiện trong đầu bạn là:

• Luồng quy trình hiện tại là gì (What’s the current process flow)?
• Các cấu hình hiện tại được quản lý trên các ứng dụng như thế nào (How are configurations currently managed across applications)?
• Các loại ứng dụng nào sẽ được triển khai (What are the types of applications to be deployed)?

Kiến trúc DevOps bên dưới minh họa luồng quy trình để triển khai những ứng dụng vào một Kubernetes cluster trên các môi trường. Có thể có nhiều biến thể khác nhau cho các loại ứng dụng khác nhau.

Sơ đồ của tác giả

Dựa trên sơ đồ trên, bạn có thể lấy thông tin về các giai đoạn khác nhau của luồng DevOps để xác định những quy trình có thể được nâng cao bằng công cụ mới, ví dụ như quản lý cấu hình, hoặc điểm tích hợp (integration points) để kết hợp (những) công cụ mới.

Những sơ đồ DevOps của các loại ứng dụng khác nhau có thể nhắc nhở những thảo luận xa hơn để khám phá một bộ quy trình và những công cụ mới tiềm năng nhằm đáp ứng nhu cầu của nhóm.

Bước tiếp theo đòi hỏi sự tham gia của các bên liên quan khác nhau để thảo luận về các cải tiến của quy trình và công cụ cũng như tác động tiềm tàng đến các hoạt động hiện có với việc triển khai Habitat, ví dụ yêu cầu plugins mới, …

Đối với các tổ chức lớn, các quy trình phức tạp hơn nhiều với các mối lo ngại về bảo mật trên các môi trường, hạn chế rất nhiều việc triển khai tài nguyên. Ngoài ra còn có nhiều ứng dụng kế thừa tuân thủ các phương thức triển khai cũ. Do đó, bạn nên tài liệu hóa các quy trình cho các biến thể ứng dụng khác nhau và xem xét chúng một cách tổng thể để cải tiến hiệu quả.

Các thành phần hữu ích trong sơ đồ này:

• Hiển thị các quy trình trên các môi trường (Showcase processes across environments) — DevOps thường trải dài trên nhiều môi trường, và việc trình bày các quy trình quảng bá ứng dụng thường hữu ích.
• Chú thích với thông tin bổ sung (Annotations with additional information) — các chi tiết bổ sung cho các giai đoạn và các quy trình tương ứng để tạo điều kiện thảo luận và lập kế hoạch.
• Quyết định cổng và quy trình người dùng (Decision gateways and user processes) — DevOps không chỉ bao gồm những thành phần hệ thống. Để xây dựng văn hóa DevOps tốt, không thể bỏ qua yếu tố thành phần con người.

Bạn có thể tải sơ đồ trên tại đây. Và đây là  danh sách 31 kiến trúc cho DevOps.

5/ Sơ đồ Kiến trúc Dữ liệu (Data Architecture Diagram)

Một Sơ đồ Kiến trúc Dữ liệu chứa các thành phần trong một hệ thống xác định cách thức dữ liệu được thu thập, xử lý, lưu trữ và sử dụng. Sơ đồ cũng minh họa luồng dữ liệu qua các thành phần hệ thống bên trong cơ sở hạ tầng CNTT.

Kiến trúc dữ liệu đề cập “How” và “Where” liên quan đến quá trình xử lý, luồng và cách sử dụng dữ liệu.

Một trong những trường hợp sử dụng của sơ đồ này là để dễ dàng nâng cấp tài nguyên để tối ưu chi phí thu thập và lưu trữ dữ liệu. Ngày nay, với lượng dữ liệu được thu thập ngày càng tăng và chi phí lưu trữ dữ liệu ngày càng rẻ, kiến trúc dữ liệu cho tổ chức chắc chắn sẽ được điều chỉnh liên tục.

Chẳng hạn, hiện tại nhật ký dữ liệu (logs data) của API gateway được lưu trữ trong một cơ sở dữ liệu (database) MySQL và được hiển thị trực quan trên một bảng điều khiển web. Khi dữ liệu được tích tụ theo thời gian vào database, các truy vấn (queries) trở nên chậm hơn và tốn kém hơn. Bạn có nhiệm vụ giải quyết vấn đề hiệu suất và thiết lập nền tảng cho các khả năng máy học (machine learning) và phân tích (analytics) trong tương lai trên các data sets từ những ứng dụng khác. Một vài câu hỏi có thể xuất hiện trong đầu bạn:

• Dữ liệu hiện tại đang được xử lý thế nào (How is data being processed currently)?
• Dữ liệu đang được lưu trữ và sử dụng ở đâu (Where is the data being stored and used)?
• Chúng ta đang đề cập đến bao nhiêu dữ liệu (How much data are we talking about)?

Kiến trúc dữ liệu bên dưới minh họa luồng dữ liệu từ nguồn đến lưu trữ và trực quan hóa. Trong vài trường hợp, có thể hữu ích khi đưa những thành phần mới vào sơ đồ để hiển thị những thay đổi nhằm dễ dàng thảo luận.

Sơ đồ của tác giả

Sơ đồ trên giải quyết các câu hỏi liên quan đến quá trình xử lý, lưu trữ và tỷ lệ tăng dữ liệu - đủ hợp lý để bắt đầu thảo luận về việc khám phá các lựa chọn thay thế tiềm năng, để hỗ trợ các hệ thống truy vấn mới và các trường hợp sử dụng kinh doanh.

Những bước tiếp theo có thể là lôi kéo các bên liên quan tham gia thảo luận chi tiết về việc triển khai, ví dụ thời gian lưu trữ dữ liệu (data retention periods), những yêu cầu về hiệu suất, hiểu biết sâu sắc và mục tiêu kinh doanh, mô hình và cấu trúc dữ liệu, ước tính chi phí…

Ở những tổ chức lớn, có thể một nhóm quản lý dữ liệu trung tâm chịu trách nhiệm hợp nhất và quản lý các quy trình, thành phần dữ liệu chính (master data components and processes). Bạn nên thiết lập một tiêu chuẩn chung để áp dụng (càng nhiều càng tốt) trên các ứng dụng trong tổ chức thông qua việc sử dụng các sơ đồ đó.

Các thành phần hữu ích trong sơ đồ này:

• Trình bày các thành phần nguyên trạng và tương lai (Display as-is and to-be components) — cung cấp tổng quan những thay đổi trong nháy mắt để đánh tác động và tập trung vào các điểm thảo luận.
• Biểu thị tỷ lệ tăng dữ liệu (Indication of data increment rate) — đem đến cho các bên liên quan cảm nhận về quy mô dữ liệu cho mục đích thiết kế giải pháp và ước tính.
• Nhóm các thành phần một cách hợp lý (Logical grouping of components) —minh họa các mục tiêu của các thành phần ở những giai đoạn khác nhau, ví dụ xử lý, trực quan hóa … để tạo điều kiện thuận liện cho việc dễ dàng đọc.

Bạn có thể tải sơ đồ trên tại: đây.

Takeaways

1. Sơ đồ Kiến trúc Ứng dụng (Application architecture diagram) cung cấp một tổng quan high-level của các thành phần để dễ dàng cho việc lập kế hoạch dưới dạng đánh giá tác động dựa trên việc nâng cấp, thay thế và hợp nhất các ứng dụng.
2. Sơ đồ Kiến trúc Tích hợp (Integration architecture diagram) tập trung vào các giao thức tích hợp giữa các thành phần ứng dụng để dễ dàng tích hợp các hệ thống đối tác internal/external.
3. Sơ đồ Kiến trúc Triển khai (Deployment architecture diagram) làm nổi bật ranh giới mạng và kích thước các thành phần cơ sở hạ tầng để dễ dàng lập kế hoạch và nâng cấp ứng dụng, dịch vụ cho mục đích tối ưu hóa.
4. Sơ đồ Kiến trúc DevOps (DevOps architecture diagram) minh họa luồng quy trình liên quan đến hệ thống và con người trên các môi trường triển khai, để dễ dàng cải tiến và tự động hóa quy trình.
5. Sơ đồ Kiến trúc Dữ liệu (Data architecture diagram) thể hiện luồng dữ liệu giữa các thành phần hệ thống trong một cơ sở hạ tầng CNTT và cho biết cách thức dữ liệu được thu thập, xử lý, lưu trữ và sử dụng để dễ dàng tối ưu hóa hệ thống dữ liệu.

Các sơ đồ này thường được sử dụng với nhau trong thiết kế giải pháp số vì chúng bổ sung cho nhau và cung cấp cho các bên liên quan một bức tranh toàn cảnh về hệ thống.

Tuy nhiên, hãy nhớ rằng “the map is not the territory”. Hầu như không thể tài liệu hóa mọi phần của hệ thống với số lượng các bộ phận chuyển động và thay đổi. Tôi đã gặp nhiều trường hợp các thay đổi và thành phần không được ghi lại trong sơ đồ vì nhiều lý do khác nhau. Hãy chuẩn bị để ứng xử với các kịch bản như thế.

Ngoài ra, có nhiều biến thể của sơ đồ kiến trúc (dựa trên Google images) phục vụ cho các mục đích khác nhau - không có cách cố định để vẽ những sơ đồ kiến trúc. Những gì tôi cung cấp ở đây là các hướng dẫn và nguyên tắc mẫu để hỗ trợ hiểu rõ hơn về hệ thống nhằm tìm ra giải pháp tiềm năng.

Vào cuối ngày, những sơ đồ này là công cụ để dễ dàng giao tiếp và hiểu biết, và điều cần thiết là điều chỉnh sơ đồ sao cho phù hợp với nhu cầu và phong cách của nhóm bạn./.

Nguồn: How to Draw Useful Technical Architecture Diagrams | by Jimmy Soh | The Internal Startup | Medium

Ant (20230216)