Một ví dụ để chúng ta có thể hình dung về bước thực hiện này, khi chúng ta nhận được yêu cầu Xây dựng hệ thông một cửa điện tử cho một đơn vị thì điều đầu tiên cần xác định là trên hệ thống một cửa điện tử này, chúng ta sẽ cần cung cấp dịch vụ gì, mỗi quy trình cho các dịch vụ đưa ra cần mô hình hóa như thế nào và khi triển khai dịch vụ này ai sẽ là đối tượng tham gia, hiệu quả mang lại ra sao.
Bước 2: Xác định ứng dụng, thành phần ứng dụng liên quan đến bai toán
Chúng ta sẽ không biết bắt đầu từ đâu nếu như không chia nhỏ các yêu cầu nghiệp vụ và đưa ra các vấn đề liên quan cho từng quy trình nghiệp vụ, việc xác định phạm vi các vấn đề liên quan đến từng quy trình nghiệp vụ giống như chúng ta phân chia bài toán thành các miền nhỏ để giải quyết từng phần, đây là tư tưởng chung của SOA.
Một hệ thống lớn không nhất thiết phải được xây dựng đồng thời, việc phân chia các miền vấn đề sẽ giúp chúng ta biết được vấn đề cần giải quyết thực sự là gì và sắp thứ tự ưu tiên. SOA không hướng đến việc xây dựng Chính phủ điện tử một lần cho tổng thể, mà nó khuyến khích chúng ta xây dựng theo “nhu cầu” của từng thời điểm điều này phù hợp với bản chất của Chính phủ điện tử là một hệ thống “trưởng thành” theo thời gian.
Xác định các ứng dụng, thành phần ứng dụng liên quan Phân tích độ phức tạp hệ thống, phân chia miền các vấn đề, thu thập dữ liệu liên quan
Đề xuất mô hình gồm các thành phần liên quan theo hướng đóng gói các dịch vụ Mô tả các thành phần theo miền các vấn đề Mô hình đề xuất Hình 3.5 Xác định ứng dụng, thành phần ứng dụng liên quan
Mỗi quy trình nghiệp vụ thường gắn liền với yêu cầu nghiệp vụ cụ thể, như bài toán Một cửa điện tử bên trong nó có thể bao gồm các dịch vụ công như Cấp giấy khai sinh, cấp sổ hộ khẩu, chứng minh nhân dân… Mỗi dịch vụ công này lại gắn liền với miền các vấn đề riêng, như Cấp giấy khai sinh sẽ gắn liền với các dữ liệu về giấy chứng sinh tại Bệnh viện, về xác minh giấy tờ chứng minh của cha mẹ do Công an cấp. Như vậy chúng ta sẽ xác định được phạm vi của miền vấn đề về Cấp giấy khai sinh bao gồm thành phần liên quan đến các dịch vụ từ Bệnh viện và Công An. Từ đó đề ra mô hình phù hợp theo hướng các đối tượng tham gia sẽ cung cấp và xử dụng dịch vụ lẫn nhau để đảm bảo yêu cầu của SOA.
Bước 3: Làm rõ thông tin ứng dụng, bổ sung thông tin hồ sơ ứng dụng bao gồm các dịch vụ liên quan
Một điều rất rõ ràng là chúng ta không thể xử lý thông tin nếu không hiểu được thông tin mình cần quản lý. SOA hướng đến việc chia nhỏ hệ thống thành các dịch vụ đóng gói, do đó đối tượng chính cần quản lý là các dịch vụ, vì vậy chúng ta sẽ phải hiểu được các thông tin liên quan đến dịch vụ bao gồm cả các đặc tính và ngữ cảnh sử dụng chúng. Mục tiêu của chúng ta tại bước này chính là xuất phát từ các yêu cầu của từng ứng dụng để đưa ra được các thông tin về những dịch vụ cần cung cấp.
Làm rõ thông tin, bổ sung hồ sơ ứng dụng Làm rõ thông tin, cập nhật hồ sơ ứng dụng di sản (Legacy) Làm rõ thông tin, cập nhật hồ sơ ứng dụng mới và các dịch vụ liên quan Thông tin các ứng dụng đang có Các thông tin hệ thống mục tiêu Định nghĩa dữ liệu cần quản lý trong mỗi dịch vụ
Các thông tin cần quản lý trong từng dịch vụ
Hình 3.6 Làm rõ thông tin các ứng dụng
Trong bước trước, chúng ta đã có được thông tin các ứng dụng, thành phần ứng dụng và mô hình kết nối tổng thể, tại bước này, chúng ta sẽ tiếp tục làm rõ hơn các thông tin để đưa được ra các dịch vụ và thông tin liên quan đến các dịch vụ cần cung cấp trong hệ thống mục tiêu. Để làm được điều này, chúng ta cần dựa vào việc phân tích thông tin các hệ thống đang có (bao gồm cả ứng dụng nội tại trong hệ thống và ứng dụng có kết nối từ bên ngoài), từ đó đề ra được các thông tin cần quản lý trong hệ thống và phân chia các ứng dụng, thành phần ứng dụng thành các dịch vụ có tính đóng gói và tái sử dụng. Ví dụ từ thông tin đã làm rõ về các quy trình Cấp giấy khai sinh, chúng ta sẽ có được danh sách các ứng dụng liên quan, như hệ thống thông tin bệnh viện, hệ thống cơ sở dữ liệu về công dân của cơ quan Công an, từ đó làm rõ hơn các thông tin cần quản lý như thông tin về chứng minh nhân dân, thông tin về nơi cư trú, thông tin về độ tuổi, nghề nghiệp… đây là các thông tin bắt buộc phải duy trì trong hệ thống. Các thông tin tổng hợp lại sẽ cho chúng ta một khung nhìn rõ hơn về hệ thống, từ đó đưa ra được các dịch vụ và mô tả mức trừu tượng cao của các dịch vụ, như với trường hợp Cấp giấy khai
sinh, đó có thể là dịch vụ Kiểm tra số chứng minh nhân dân, dịch vụ vấn tin thông tin bệnh nhân…
Bước 4: Xác định và làm rõ thông tin các dịch vụ trong hệ thống mục tiêu
Khi đã xác định được các dịch vụ cần quản lý (bao gồm cả những dịch vụ có sẵn và dịch vụ được tạo mới), chúng ta sẽ cần làm rõ các thông tin về từng dịch vụ, một số thông tin như dịch vụ sẽ được thực thi ở đâu, mục đích của dịch vụ, thông tin về giao diện, các ràng buộc nếu có và đặc biệt là vấn đề về bảo mật (ai được gọi, ứng dụng nào được gọi, khả năng mã hóa dữ liệu…)
Mỗi dịch vụ được đưa ra đều nhằm giải quyết các yêu cầu của hệ thống, để tránh trùng lặp và nâng cao khả năng tái sử dụng, chúng ta cần cung cấp thông tin một cách chi tiết nhất có thể cho từng dịch vụ, việc làm này giúp cho hệ thống có sự rõ ràng trong tất cả các thành phần.
Một hệ thống phần mềm lớn như Chính phủ điện tử sẽ bao gồm rất nhiều ứng dụng nhỏ hơn, trong đó có thể có những ứng dụng đã được triển khai trước tại mỗi đơn vị, như hiện nay phần mềm Quản lý văn bản điều hành đang được triển khai khá tốt tại mỗi đơn vị cơ quan nhà nước, những ứng dụng đó cũng có thể là các cổng kết nối tới hệ thống bên ngoài như giao dịch tài chính với các ngân hàng. Vì có rất nhiều loại dịch vụ khác nhau trong hệ thống, nên cần xác định rõ thông tin của mỗi dịch vụ để chuẩn hóa danh sách và quản lý hệ thống được tốt hơn.
Bên cạnh những thông tin về chức năng của mỗi dịch vụ thì việc đưa ra các thông tin về hiệu năng và các yêu cầu bảo mật cũng hết sức quan trọng, một hệ thống phức tạp sẽ rất khó để kiểm soát hiệu năng, vì vậy cần kiểm soát hiệu năng ngay khi xác định và đưa ra thông tin của từng dịch vụ để lấy đó làm căn cứ khi sử dụng dịch vụ.
Trong bước này chúng ta cần đưa ra được một mẫu mô tả thống nhất cho tất cả các dịch vụ, việc xây dựng mẫu mô tả này sẽ được trình bày trong chương sau.
Bổ sung, cập nhật danh mục các dịch
vụ
Phân tích thông tin về các dịch vụ, đưa ra danh sách dịch vụ đã chuẩn
hóa
Phân tích dữ liệu và thông tin cho từng dịch vụ theo yêu cầu chức năng
Danh sách các dịch vụ đã chuẩn hóa
Dịch vụ và thông tin đi kèm theo tính năng
Phân tích, đưa ra các thông tin về hiệu năng của dịch
vụ
Dịch vụ và thông tin hiệu năng tương ứng
Hình 3.7 Xác định và làm rõ thông tin các dịch vụ
Kết quả của bước này, chúng ta sẽ có tập hợp danh sách các dịch vụ đã được chuẩn hóa và các thông tin mô tả tính năng, hiệu năng tương ứng.
Bước 5: Định nghĩa, xây dựng các dịch vụ mới.
Các dịch vụ mới này chính là thành phần làm nên SOA, dựa vào các thông tin về dịch vụ và các ứng dụng, chúng ta có thể phân loại các dịch vụ mới thành các loại:
● Các dịch vụ di sản (Legacy): Đây là các dịch vụ bao bên ngoài các ứng dụng sẵn có của hệ thống mà chúng ta vẫn sẽ cần duy trì, sử dụng trong hệ thống mục tiêu.
● Các dịch vụ kết hợp (Composite): Tổ hợp nhiều dịch vụ nhỏ thành một dịch vụ lớn có tính sử dụng cao hơn, việc phân chia này có thể dựa vào tần suất sử dụng của nhóm các dịch vụ.
● Loại dịch vụ thứ ba là dịch vụ xây dựng hoàn toàn từ đầu, đây là các dịch vụ mà chúng ta cần đầu tư nhiều thời gian hơn, việc xây dựng mới cần tính đến tái sử dụng về sau.
Để định nghĩa ra các dịch vụ mới chúng ta cần thực hiện qua các bước: Xây dựng các tài liệu mô tả định nghĩa dịch vụ, Thiết kế các dịch vụ, Cài đặt các dịch vụ trong hệ thống thực. Tài liệu mô tả dịch vụ sẽ được dùng cho các thành phần khác khi tham chiếu tới dịch vụ được xây dựng. Thiết kế và cài đặt dịch vụ chính là các bước để hiện thực hóa các định nghĩa được đưa ra trong tài liệu mô tả dịch vụ.
Định nghĩa, xây dựng các dịch vụ
mới
Xây dựng tài liệu mô tả dịch vụ Thiết kế các dịch vụ Mô tả định nghĩa dịch vụ Bản thiết kế các dịch vụ Hiện thực hóa các dịch vụ Dịch vụ đã cài đặt Hình 3.8 Xây dựng dịch vụ mới
Bước 6: Định nghĩa, xây dựng các quy trình nghiệp vụ mới.
Tương tự như với việc định nghĩa các dịch vụ mới, tuy nhiên định nghĩa quy trình nghiệp vụ mới ở mức trừu tượng cao hơn. Bước này cần thực hiện sau khi chúng ta đã có thông tin đầy đủ về hệ thống cần xây dựng, đã có được các dịch vụ cả cũ cả mới, vì
một quy trình nghiệp vụ thường liên quan đến nhiều dịch vụ, và có thể liên quan cả đến những quy trình khác như với trường hợp các thủ tục hành chính liên thông.
Tuy rằng các quy trình nghiệp vụ thường chấp nhận sự tham gia của con người trong một bước nào đó, nhưng chúng ta nên hướng tới một hệ thống tự động hóa, giảm thiểu sự tác động của con người để tránh sai sót, nhầm lẫn trong quá trình tác nghiệp, đồng thời nâng cao sự minh bạch.
Nền tảng để xây dựng các quy trình nghiệp vụ mới là dựa trên các dịch vụ đã được chỉ ra, việc thiết kế một quy trình nghiệp vụ theo hướng dịch vụ là sự tổ hợp các dịch vụ và các thao tác của con người nếu có vào trong một quy trình được mô hình hóa theo chuẩn ngôn ngữ nào đó như BPMN (Business Process Model and Notation). Các bước để xây dựng các quy trình nghiệp vụ trong hệ thống cũng tương tự như với dịch vụ.
ĐỊnh nghĩa, xây dựng các quy trình
nghiệp vụ mới
Xây dựng tài liệu đặc tả quy trình nghiệp vụ cần xây
dựng
Thiết kế các quy trình nghiệp vụ
Mô tả định nghĩa quy trình nghiệp vụ Bản thiết kế các quy trình nghiệp vụ Cài đặt các quy trình nghiệp vụ Quy trình đã cài đặt
Kết quả của bước 5 và bước 6 là chúng ta sẽ có được các thành phần mảnh ghép mới vào hệ thống, đó là các dịch vụ mới, các quy trình nghiệp vụ mới. Đặt tình huống nếu chúng ta đưa ra dịch vụ mới và quy trình nghiệp vụ mới trong ngữ cảnh hệ thống đang hoạt động ổn định, như vậy chắc chắn yêu cầu kiểm soát về chất lượng sản phẩm và đánh giá hiệu năng là hết sức quan trọng. Vì vậy trong quá trình áp dụng vào thực tiễn, chúng ta cần có kế hoạch cho việc thực hiện kiểm thử và đánh giá chất lượng dịch vụ, quy trình nghiệp vụ mới.
Cả bước 5 và bước 6 đều thiên về lựa chọn công nghệ để có thể xây dựng, biểu đạt dịch vụ và quy trình nghiệp vụ, hiện tại có rất nhiều công cụ để hỗ trợ thực hiện công việc tại các bước này, có thể kể đến như các giải pháp phần mềm đóng của IBM, Oracle, TIBCO cho các phần về sản phẩm ESB (Enterprise Service Bus) và BPM (Business Process Management) hay các sản phẩm tương tự nhưng trên nền tảng nguồn mở như Bonita, Activiti với BPM và Talend, Mule với ESB. Như đã đề cập trước đó, SOA không phụ thuộc quá nhiều vào công nghệ, tuy nhiên lựa chọn giải pháp công nghệ tốt cũng sẽ tác động tích cực đến các vấn đề như hiệu năng, tính bảo mật, thời gian phát triển của hệ thống.
Trong phần tiếp theo của luận văn chúng ta sẽ thảo luận thêm về việc lựa chọn các công nghệ và vận dụng trong các bài toán thực tế để minh chứng tính đúng đắn cho các bước thực hiện đã đưa ra.
Chương 4. Khảo sát và áp dụng vào bài toán thực tiễn
4.1.Bài toán liên thông thủ tục hành chính
Như đã đề cập ở phần trước, xây dựng giải pháp phần mềm cho Chính phủ điện tử Việt Nam là bài toán lớn gồm nhiều vấn đề cần giải quyết và hướng tiếp cận của SOA là phát triển một hệ thống “trưởng thành” qua thời gian. Chúng ta không đưa được ra giải pháp cho tất cả các vấn đề gặp phải mà sẽ đưa ra giải pháp cho từng bài toán nhỏ theo các bước đã đề ra để đảm bảo việc tuân thủ SOA.
Để kiểm chứng cơ sở lý thuyết cho hướng áp dụng SOA vào thực tiễn Chính phủ điện tử Việt Nam, luận văn lựa chọn bài toán Một cửa điện tử liên thông với quy trình thủ tục hành chính thực tế hiện đang được vận hành liên thông giữa các cơ quan nhà nước tại mỗi địa phương là Đăng ký khai sinh, Đăng ký thường trú và Cấp thẻ bảo hiểm y tế cho trẻ em dưới 6 tuổi.
Trong phần tiếp theo chúng ta sẽ đi chi tiết hơn vào bài toán thực tiễn và cách thức thực hiện.
4.2.Áp dụng hướng đã đề xuất để giải quyết bài toán
4.2.1.Đề xuất mô hình khung cho bài toán xây dựng Chính phủ điện tử Việt Nam
Trước khi bắt đầu với các bài toán thực tế trong xây dựng Chính phủ điện tử Việt Nam, chúng ta sẽ cùng đưa ra mô hình hiện thực hóa ý tưởng xuất phát từ Khung chính phủ điện tử Việt Nam theo SOA.
Trong mô hình kiến trúc mục tiêu chúng ta sẽ hướng đến phạm vi triển khai về mặt hệ thống cho đơn vị hành chính cấp tỉnh và cấp bộ, vì trong thực tế ở các cấp thấp hơn chúng ta có thể sử dụng chung hạ tầng của hai cấp này để vừa có tính nhất quán trong kiến trúc đồng thời tránh được đầu tư dàn trải lãng phí.
Xuất phát từ ý tưởng đưa ra giải pháp phần mềm giải quyết vấn đề liên thông, kết nối và tái sử dụng trong Chính phủ điện tử Việt Nam, luận văn đề xuất sử dụng mô hình mẫu dựa trên SOA. Trong đó tập trung việc giải quyết vấn đề kết nối, liên thông dựa vào thành phần ESB ở các cấp địa phương và trung ương tương ứng với thành phần LGSP và NGSP được đưa ra trong Khung chính phủ điện tử Việt Nam, đồng thời với hướng tiếp cận dịch vụ hóa các ứng dụng, thành phần ứng dụng, đặc biệt là đưa vào thành phần Quản lý quy trình nghiệp vụ (BPM) như một sự đảm bảo cho vấn đề chuẩn hóa và tái sử dụng cả về các chức năng cũng như nghiệp vụ trong hệ thống.
Hình 4.1 Mô hình đề xuất triển khai Chính phủ điện tử Việt Nam