Nhận thức đó không phải lúc nào cũng không công bằng. Rất phổ biến để tìm câu hỏi trong các diễn đàn, chẳng hạn như "Bạn có thể giải thích giá trị của Kiến trúc Chính phủ điện tử trong một câu không?" hoặc "Trở ngại chính cho thành công của Kiến trúc Chính phủ điện tử là gì?". Thực tế những câu hỏi này chỉ ra một điều rất phổ biến rằng Kiến trúc Chính phủ điện tử bị hiểu lầm và kết thúc hoàn toàn như một chức năng biệt lập có rất ít liên hệ với các vấn đề và cơ hội thực sự của tổ chức.

Nhưng mặt khác, thực sự không khó để hiểu Kiến trúc Chính phủ điện tử có thể cung cấp giá trị gì - rất nhiều giá trị. Các nguyên tắc về tái sử dụng, tiêu chuẩn hóa, liên kết giữa công nghệ thông tin và nghiệp vụ,... Rõ ràng những điều đó có thể giúp bất kỳ tổ chức nào giảm các chi phí không cần thiết để đạt được hiệu quả và thúc đẩy hoạt động. Vấn đề không phải là "tại sao - Why" hay "cái gì - What" mà là "làm thế nào - How". Và Kiến trúc giải pháp là nơi cho biết “Làm thế nào”.

Nói cách khác, để kiến ​​trúc sư có cái nhìn thực tế về bối cảnh công nghệ thông tin và nhu cầu tương lai của các lĩnh vực nghiệp vụ, anh ta cần tham gia vào các dự án công nghệ thông tin. Sau đó, mới có thể bảo vệ cho các khuyến nghị của mình trong thực tế chứ không chỉ trong lý thuyết.

Vì vậy, rõ ràng, Kiến trúc Chính phủ điện tử và Kiến trúc giải pháp phải gắn kết cùng nhau để xây dựng bức tranh kiến ​​trúc một cách hiệu quả và thu được những lợi ích tối đa với lãng phí tối thiểu. Trên thực tế, Kiến trúc Chính phủ điện tử và Kiến trúc giải pháp là các khía cạnh của cùng một chức năng nghiệp vụ: kiến ​​trúc. Đó là tất cả về việc tối ưu hóa việc sử dụng các nguồn lực để đáp ứng nhu cầu hoạt động theo chiến lược ưu tiên của tổ chức. Có rất nhiều thách thức để xây dựng một bức tranh tối ưu, trong đó, dựa trên Kiến trúc hướng dịch vụ (SOA) là một giải pháp tốt.

Mô hình hóa kiến ​​trúc nghiệp vụ

Bước đầu tiên trong việc tạo ra một kiến ​​trúc khái niệm cho hệ thống là mô hình hóa nghiệp vụ. Nói chung, trong bất kỳ tổ chức nào, mọi người đều có vai trò, thông qua việc họ tham gia vào quy trình xử lý để cung cấp một dịch vụ cho ai đó trong hoặc ngoài tổ chức. Các dịch vụ ứng dụng được cung cấp để hỗ trợ các quá trình đó và được cụ thể hóa trong các thành phần và chức năng của ứng dụng. Chúng sử dụng các dịch vụ hạ tầng và các thành phần vật lý, như network, server, storage,... Điều này cung cấp một mô hình lớp nghiệp vụ, chứa hầu hết các thông tin được yêu cầu bởi người làm kiến ​​trúc để bắt đầu thiết kế hệ thống.

Mô hình hóa nghiệp vụ cho phép người làm kiến ​​trúc trực tiếp tham gia từ các lĩnh vực nghiệp vụ và đó là công việc rất tốt để thực hiện khi bắt đầu bất kỳ dự án mới nào, ngay khi yêu cầu của người dùng đã có. Bất kỳ ai đã tham gia vào các dự án công nghệ thông tin đủ lâu đều biết, các số liệu thống kê về các thất bại của dự án cho thấy hầu hết các vấn đề trong các dự án được tạo ra từ lâu trước khi bắt đầu triển khai. Thiếu sự rõ ràng và đầy đủ trong các yêu cầu, hiểu biết kém về quy trình nghiệp vụ và thay đổi các yêu cầu là những vấn đề phổ biến nhất và tốn kém nhất. Phương pháp Agile giúp xử lý chúng, nhưng vẫn khó tìm được ngôn ngữ chung giữa công nghệ thông tin và nghiệp vụ.

Điều còn thiếu là bức tranh tổng thể. Nếu người làm kiến ​​trúc có thể tạo ra một mô hình và trình bày cho những người xử lý chuyên môn nghiệp vụ, họ sẽ ngay lập tức nhận ra nếu vai trò nghiệp vụ và quy trình nghiệp vụ được thể hiện chính xác. Điều này dẫn tới phải cho phép người làm kiến ​​trúc hiểu các quy trình nghiệp vụ. Mặt khác, người xử lý chuyên môn nghiệp vụ cũng sẽ có thể hiểu cách người làm kiến ​​trúc đang định hình các hệ thống mà họ sẽ sử dụng. Các công cụ mô hình hóa hiện nay như Archimate rất tốt trong việc kết nối mọi người lại với nhau vì nó giúp dễ dàng xây dựng và hiểu một mô hình.

Chỉ định mẫu thiết kế cho mỗi dịch vụ chia sẻ

Một lĩnh vực quan trọng mà kiến ​​trúc có trách nhiệm lớn là trong việc tối ưu hóa việc sử dụng tài nguyên tổ chức. Các tài nguyên nên được cung cấp thông qua các dịch vụ có hợp đồng xác định thỏa thuận cấp độ dịch vụ đi kèm (SLA).

Việc hấp thụ các dịch vụ đó phải tuân theo các hướng dẫn được đặt ra bởi chức năng kiến ​​trúc. Mặt khác, kiến ​​trúc sư sẽ nhanh chóng mất dấu vết về những gì thực sự được triển khai và giá trị lớn nhất mà anh ta có thể mang lại - thúc đẩy tái sử dụng, tối ưu hóa tài nguyên, giảm chi phí và cho phép thay đổi nghiệp vụ - sẽ bị "biến mất".

Nói chung, xây dựng kiến trúc hướng dịch vụ SOA thực sự là thách thức lớn nhất của bài toán kiến ​​trúc. Mặc dù đã được thừa nhận nhiều lần rằng đó là mô hình mang lại hiệu quả cao nhất, nhưng thực tế là việc triển khai nó vẫn gây gián đoạn trong hầu hết các tổ chức vì nó không tuân theo các quy định theo hệ thống dọc.

Triển khai Trục tích hợp (ESB) là một trong những yếu tố chính để giữ cho bức tranh hệ thống được kiểm soát, nhưng điều đó là không đủ. Hầu hết các ESB trên thị trường có thể cung cấp tất cả các dịch vụ được yêu cầu: điều phối, giám sát hoạt động, quản lý cộng đồng, thích ứng giao tiếp, chuyển đổi thông điệp và tích hợp dữ liệu, tất cả được cung cấp thông qua một nền tảng an toàn, được quản lý tập trung, có tính sẵn sàng cao. Nhưng có tất cả các công cụ này không đảm bảo rằng chúng được sử dụng hợp lý. Các giao diện và luồng thông điệp tại ESB phải được thiết kế theo các mẫu tích hợp được thiết lập sẵn để đảm bảo rằng chúng thực sự có thể được sử dụng lại và không trùng lặp.

Có nhiều nguồn cho các mẫu cho tất cả các loại công nghệ. Để sử dụng hiệu quả chúng, một việc làm tốt là xem xét những gì hiện đang được yêu cầu tại tổ chức và thiết kế ngược các giao diện hiện có thành các mẫu chung. Điều này sẽ mang lại một danh sách mà sau này có thể được mở rộng khi cần thiết. Danh sách đó sẽ trở thành một tài liệu tham khảo cho tất cả các giao diện mới và bất cứ khi nào có thể, được sử dụng để thiết kế lại các giao diện hiện có.

Đánh giá các lựa chọn khác nhau với phân tích kiến ​​trúc

Một khi nghiệp vụ được mô hình hóa chính xác và hội tụ đầy đủ nhu cầu của người dùng và nhận thức của kiến ​​trúc sư, khi đó cần tiến hành mô hình hóa ứng dụng.

Kiến trúc sư nên lấy các yêu cầu của người dùng, mô hình nghiệp vụ được thực hiện, các dịch vụ nên được sử dụng lại, các chính sách có liên quan, các mẫu nên được áp dụng và các yêu cầu về bảo mật và vận hành. Với những đầu vào này, sẽ tạo ra một hoặc nhiều kiến ​​trúc giải pháp khả thi và đề xuất một hướng đi.

Mô hình ứng dụng được gắn vào mô hình nghiệp vụ dưới dạng các lớp thấp hơn, với các dịch vụ ứng dụng được "sử dụng" bởi các quy trình nghiệp vụ đã xác định.

Khi các mô hình được tạo ra, hoạt động phân tích cấu trúc thể được thực hiện để so sánh các giải pháp và xác định các rủi ro, cơ hội và chi phí xuất phát từ bất kỳ quyết định kiến ​​trúc cần thiết nào. Ngay cả khi chỉ có một giải pháp, nó vẫn là trường hợp tốt để tiến hành phân tích vì giúp phát hiện các vấn đề kiến ​​trúc. Để phân tích ta có thể xây dựng các kịch bản khác nhau, tập trung vào người sử dụng để xây dựng các trường hợp sử dụng.

Nếu đã xác định nhiều hơn một thiết kế giải pháp, hoạt động phân tích nên được thực hiện độc lập cho từng tùy chọn để có thể so sánh kết quả.

Trình bày kiến ​​trúc và lợi ích của nó cho những người ra quyết định

Tất cả các kết quả của việc phân tích nêu trên nên được viết trong một báo cáo, có trình bày những vấn đề phát hiện ra. Báo cáo không nên bao gồm các chi tiết kỹ thuật dẫn đến kết luận, mà chỉ liên kết lại với tài liệu phân tích đầy đủ. Thay vào đó, nên bao gồm mô tả mức cao về các tùy chọn đã xác định, rủi ro, cơ hội và thông tin chi tiết. Bằng cách này, chủ sở hữu hệ thống, giám đốc công nghệ thông tin và bất kỳ bên liên quan nào khác có thể đưa ra quyết định. Người làm kiến trúc có cơ hội quý giá để thể hiện rõ tác động của từng quyết định đối với toàn bộ tổ chức và do đó, ảnh hưởng đến kiến ​​trúc hệ thống mới để đảm bảo nó phù hợp với Kiến trúc tổ chức. Tóm lại, báo cáo bao gồm tuyên bố ngắn gọn về kiến ​​trúc và các quyết định được đề xuất cần được thực hiện với các rủi ro, cơ hội và chi phí vốn có của chúng. Đây là tài liệu quan trọng mà người làm kiến ​​trúc sư sẽ xây dựng. Thông thường, người làm kiến ​​trúc sẽ cần sự giúp đỡ của các chuyên gia, bao gồm các nhà phân tích nghiệp vụ và chuyên gia công nghệ thông tin.

Đánh giá việc thực hiện và xác định các khoảng trống

Khi thiết kế giải pháp chi tiết đã hoàn thành hoặc thậm chí trong thời gian thực hiện, có thể kiến ​​trúc hệ thống được tài liệu hóa ban đầu không thể thực sự hoàn thành. Điều này có thể là do thay đổi yêu cầu, các ràng buộc không lường trước được (ví dụ: ngân sách ít hơn, ít thời gian hơn hoặc ít tài nguyên hơn) hoặc đơn giản là vì một cái gì đó bị bỏ qua hoặc giả định sai.

Bất kỳ sai lệch nào đối với kế hoạch có thể có hậu quả đối với toàn bộ tổ chức. Dựa trên tài liệu phân tích được tạo ra trước đó, cần phải hiểu rõ tác động là gì và nó xảy ra ở đâu. Một số phân tích bổ sung có thể được yêu cầu, nhưng đó là điều không muốn.

Bất kể trường hợp nào, hệ thống được thực hiện theo một cách khác so với kế hoạch ban đầu mà không có sự chấp thuận chính thức, người làm kiến ​​trúc nên truyền đạt các khoảng trống dự kiến ​​cho các bên liên quan càng sớm càng tốt.

Để viết một khoảng cách dự kiến, người làm kiến ​​trúc cần phải làm như sau:

- Chuyển các khoảng cách thành các tác động thực sự lên tổ chức.

- Hiểu nguyên nhân gốc rễ của từng khoảng cách và giải thích nguyên nhân bằng ngôn ngữ phi kỹ thuật.

- Đề xuất các biện pháp giảm thiểu, cùng với chi phí và tác động của chúng.

- Xác định và thông báo cho các bên liên quan bị ảnh hưởng. Cuối cùng, mỗi bên liên quan cần chấp nhận hoặc từ chối các thay đổi. Quá trình này cho phép người kiến ​​trúc ngăn chặn những sai lệch có thể làm tổn hại đến SOA.

Tóm tắt

Liên quan đến Kiến trúc Chính phủ điện tử trong việc phát triển các dự án và trong quản lý thay đổi là cách tốt nhất để thúc đẩy phát triển kiến trúc hướng dịch vụ. Truyền đạt rõ ràng tác động của từng quyết định đến tổ chức một cách nhanh chóng cho thấy rõ rằng việc chia sẻ dịch vụ, đầu tư vào các thành phần có thể tái sử dụng và luôn luôn sử dụng lại trước khi triển khai./.

TRUYỀN THÔNG TCHC EVNPMB3