Vài suy nghĩ về Chính phủ điện tử Việt nam (phần 2)

Vài suy nghĩ về Chính phủ điện tử Việt nam (phần 2)

(Bài đã đăng trên tạp chí Tin học & Đời sống 5/2012)

2- Kiến trúc, khung kiến trúc CPĐT.

CPĐT là một lĩnh vực mới bắt đầu phát triển từ cuối những năm 90 và hiện còn đang trong quá trình phát triển. Vì vậy có rất nhiều điều còn chưa rõ ràng, có nhiều cách hiểu, cách làm khác nhau. Dưới đây là vài ví dụ:

Khái niệm khung (framework) được hiểu khác nhau. Zachman định nghĩa khung ¹ như một sơ đồ phân loại; TOGAF lại coi khung là “một phương pháp chi tiết và bộ công cụ hỗ trợ để phát triển một kiến trúc” ², Roger Sessions coi khung kiến trúc “là một cấu trúc khung xương – skeleton structure” ³, kiến trúc FEA của Mỹ cũng được coi như một framework, v.v….

Ngay trong một loại khung kiến trúc, nội dung cũng khác nhau. Khung CPĐT của Uganda ⁴ có nội dung khá đơn giản, trong khi đó khung CPĐT của Mỹ ⁵ tương đối đầy đủ và phức tạp.

Trong CPĐT có nhiều loại khung: khung kiến trúc, khung pháp lý, khung kỹ thuật, khung tương hợp, v.v… Trong một khung lại có thể có các khung khác.

Vấn đề phức tạp, rối đến mức mà có chuyên gia phải viết cả một quyển sách “Làm thế nào để sống sót trong rừng rậm các khung kiến trúc” ⁶.

Vì vậy, mặc dù khung CPĐT do tư vấn nước ngoài xây dựng, nhưng về phía chúng ta cũng cần có những nghiên cứu nhất định để có thể ra đầu bài, hiểu, điều khiển và đánh giá, nghiệm thu được kết quả của tư vấn. Qua tham khảo một số công trình nghiên cứu trong nước, xin có vài đề xuất rút kinh nghiệm cho lần này.

Ý tưởng chung là đi vào một khu “rừng rậm” như đã dẫn ở trên, có nhiều góc nhìn khác nhau, nhiều phương pháp tiếp cận, nhiều loại công cụ. Cần chọn ra, tạo ra những cái của riêng mình, phù hợp với điều kiện đặc thủ của mình ngay trước khi bước vào khám phá nếu không muốn bị lâm vào tình trạng “chỉ thấy cây mà không thấy rừng”, hoặc bước vào rừng với hai bàn tay không, nhìn bằng con mắt người khác, phó mặc cho người dẫn dắt.

Dưới đây nêu lên vài điều cần lưu ý khi chọn phương pháp, công cụ “ đi rừng”, chưa bàn đến các vấn đề kỹ thuật cụ thể.

a) Chọn phương pháp luận để xây dựng khung CPĐT

Theo một nghiên cứu gần đây ⁷, khoảng 90% kiến trúc tổ chức (tạm dịch cụm từ enterprise architecture, mà kiến trúc CPĐT là một trường hợp riêng) được xây dựng dùng một trong 4 phương pháp luận (methodology) sau:

• Khung kiến trúc Zachman (The Zachman Framework for Enterprise Architectures) ⁸: là một hệ thống phân loại (taxonomy), mô tả các thành phần kiến trúc phải có dưới góc nhìn khác nhau của những người liên quan. Nhưng có nhiều vấn đề quan trọng không được Zachman đề cập tới. Nó cũng không chỉ cách xây dựng một kiến trúc mới như thế nào.
• Khung kiến trúc TOGAF (The Open Group Architectural Framework – TOGAF) ⁹: là một phương pháp (method) hướng dẫn chi tiết cách xây dựng một kiến trúc kèm theo các công cụ hỗ trợ, nhưng lại không chỉ cách làm thế nào xây dựng một kiến trúc tốt, cho nên kết quả có thể không như mong muốn.
• Kiến trúc Chính phủ liên bang Mỹ (The Federal Enterprise Architecture – FEA) ¹⁰: không chỉ là 5 mô hình tham chiếu, mà còn có 4 tài liệu về phương pháp luận áp dụng và hướng dẫn từng bước. Vì vậy, FEA được xem là một phương pháp luận đầy đủ, kết hợp được cả hai phương pháp luận nói trên, có khung đánh giá kết quả. Mặc dù tên chính thức của nó là kiến trúc nhưng cũng được xem như một framework, kế thừa từ FEAF.
• Phương pháp luận Gartner (The Gartner Methodology): Gartner là một công ty nghiên cứu và tư vấn về IT nổi tiếng ¹¹. Phương pháp luận xây dựng kiến trúc của Gartner được đánh giá cao do uy tín và tay nghề (practise) của công ty ¹² và do đó, phải do người của công ty thực hiện.

(Một nghiên cứu khác cho rằng hiện có 6 khung kiến trúc hàng đầu ¹³, nhưng điều đó chưa quan trọng ở đây).

Mỗi một phương pháp luận trên có ưu nhược điểm, điều kiện áp dụng riêng (và còn một số phương pháp khác ¹⁴). Việc lựa chọn một hoặc vài phương pháp hay tổ hợp các ưu điểm của nhiều phương pháp phù hợp với điều kiện nước ta phải là nội dung của một nghiên cứu riêng. Nhưng xét đến thực tế đội ngũ chuyên gia về kiến trúc tổng thể hiện nay, một trong những yêu cầu cần có là phương pháp luận phải có hướng dẫn áp dụng (method, guidance) rõ ràng, chi tiết và dễ hiểu.

Và điều quan trọng nữa, khi đã chọn phương pháp luận rồi phải theo đúng nó. Có những công trình nói là dựa vào TOGAF, FEA,… nhưng khi thực hiện chỉ dùng mỗi các mô hình tham chiếu là không đủ. Một ví dụ áp dụng pha sơ bộ của TOGAF vào CPĐT xem ở đây ¹⁵.

b) Chọn phương pháp để so sánh, đánh giá khung CPĐT

Khi đã có phương pháp luận, bước tiếp theo là so sánh, đánh giá một số khung CPĐT của các nước để rút kinh nghiệm và chọn ra một số mẫu. Nếu chỉ đơn thuần là liệt kê, mô tả kinh nghiệm các nước thì không đủ. Cần phải có phương pháp, tiêu chí để so sánh, đánh gíá khung CPĐT.

Mặt khác, xây dựng được một khung CPĐT rồi, làm sao biết nó tốt hay xấu để nghiệm thu? Cũng cần có phương pháp, tiêu chí thậm chí thang điểm theo yêu cầu đặt ra ban đầu.

Đã có một số công trình nghiên cứu về vấn đề này. Ví dụ: Roger Sessions ¹⁶ đưa ra nhiều tiêu chí để chấm điểm; Kostovska et al ¹⁷ đề xuất hẳn một phương pháp luận để đánh giá, v.v… Bộ Tài chính Phần lan có đưa ra một khung đánh giá hoạt động xây dựng CPĐT, mặc dù chưa đủ chi tiết theo nhu cầu của chúng ta, nhưng cũng đáng tham khảo ¹⁸

Phương pháp đánh giá khung CPĐT không đơn thuần chỉ là về mặt kỹ thuật. Nó phải thể hiện được đặc điểm cụ thể của quốc gia trong quá trình xây dựng CPĐT, thể hiện những trọng tâm cần nhấn mạnh và những mục tiêu đầu bài đặt ra cho việc xây dựng khung CPĐT. Ví dụ: nếu coi trọng cải cách hành chính hướng CPĐT thì phần mô hình nghiệp vụ phải được cho điểm số cao, nếu hướng tới phân quyền mạnh thì tính tương hợp phải được ưu tiên hàng đầu, v.v….. Các công cụ nói trên (phương pháp, tiêu chí, thang điểm hay khung) không phải là cố định, có thể tùy biến, sửa đổi, kết hợp để tạo nên một công cụ phù hợp với nhu cầu riêng.

Sau bước đánh giá, lựa chọn một cách có phương pháp như trên phải chỉ ra được cái khung ta cần có hình hài như thế nào, có những nội dung gì, chi tiết đến đâu, các mẫu đã chọn là gì và quan trọng nhất là tại sao lại quy định, chọn như vậy.

Tóm lại, đây cũng là vấn đề cần quan tâm và giải quyết trước khi bắt tay vào xây dựng khung CPĐT và là cơ sở để nghiệm thu.

c) Tính tương hợp và kiến trúc CPĐT

Ngay cả khi chưa có kiến trúc, một yêu cầu sống còn là các hệ thống ICT phải có tính tương hợp (interoperability) về mặt kỹ thuật: trao đổi thông suốt được dữ liệu với nhau và sử dụng được dữ liệu đó. Để đảm bảo tính tương hợp ở cấp độ này, các chính phủ thường ban hành một bộ chuẩn kỹ thuật hoặc khung tương hợp (interoperability frameworks) mà các hệ thống ICT nên hoặc phải tuân thủ.

Tuy nhiên theo nghĩa rộng của tính tương hợp: các cơ quan chính phủ làm việc được với nhau qua CPĐT ¹⁹ thì tương hợp kỹ thuật như nói trên là không đủ, CPĐT phải được xây dựng trên một kiến trúc chung ²⁰, ²¹. Vì vậy có 3 cách để đảm bảo tính tương hợp: a/ Xây dựng đồng thời bộ chuẩn tương hợp và kiến trúc CPĐT ²², b/Xây dựng khung và/hoặc kiến trúc CPĐT trong đó một trong những nguyên tắc là đảm bảo tính tương hợp ²³, tức là lồng ghép khung tương hợp vào nội dung kiến trúc hoặc c/Chia làm 2 giai đoạn: đầu tiên ban hành khung tương hợp (hoặc bộ chuẩn kỹ thuật), sau đó mới ban hành kiến trúc CPĐT ²⁴.

Với đặc điểm tình hình cụ thể của Việt nam, cách thứ ba có vẻ hợp lý, kịp thời và khả thi hơn. Trong khi chờ đợi xây dựng và áp dụng khung và/hoặc kiến trúc CPĐT, cần có ngay một bộ chuẩn kỹ thuật tương hợp để tránh những phức tạp, tốn kém sau này. Đó là điều mà các quyết định và thông tư số 20/2008/QĐ-BTTTT, 01/2011/TT-BTTTT đã làm và cần tiếp tục hoàn thiện.

Nay đến giai đoạn xây dựng khung CPĐT, cần chú ý đưa việc đảm bảo tính tương hợp theo cách a/ hoặc b/ ở trên.

d) Chọn công cụ kiến trúc

Vấn đề này tuy không vĩ mô như những cái đã bàn ở trên, nhưng lại rất quan trọng nếu muốn áp dụng kiến trúc thành công. Một kiến trúc cụ thể được xây dựng và áp dụng có liên quan đến các yếu tố: a/Kế thừa kiến trúc cấp trên, b/Sử dụng lại những phần có thể của các kiến trúc ngang cấp, c/Chia sẻ các phần có thể dùng chung cho các đơn vị khác, d/Sửa đổi, cập nhật liên tục theo quá trình phát triển, e/ Truyền đạt xuống các cấp dưới để triển khai tiếp, áp dụng vào các sản phẩm cụ thể, f/ Nhiều người, nhiều bộ phận tham gia xây dựng, xét duyệt, triển khai dưới nhiều góc nhìn khác nhau v.v…

Tất cả những điều đó không thể thực hiện được nếu không có một ngôn ngữ chung và các công cụ phù hợp được thống nhất trong toàn hệ thống. Tương tự như ngôn ngữ bản vẽ kỹ thuật và các phần mềm thiết kế trong kiến trúc xây dựng, có hai vấn đề dưới đây nên được chỉ rõ và thống nhất sử dụng:

1- Ngôn ngữ mô hình kiến trúc ( enterprise architecture modeling language )

Một kiến trúc có rất nhiều đối tượng quan tâm (stackeholders) dưới nhiều góc nhìn (viewpoint) khác nhau và gồm nhiều loại mô hình khác nhau. Để các đối tượng đó có thể hiểu, thông tin với nhau, cần có ngôn ngữ chung.

Hiện nay, chưa có một ngôn ngữ duy nhất cho kiến trúc tổng thể (enterprise architecture) nói chung và kiến trúc CPĐT nói riêng ²⁵. Vì vậy một bộ các ngôn ngữ phù hợp với từng lĩnh vực kiến trúc CPĐT (ArchiMate, BPMN, UML,…) nên được chọn và quy định thống nhất trong toàn hệ thống.

Sau khi đã quy định, ví dụ mô tả các quy trình nghiệp vụ bằng BPMN, các đoạn văn mô tả dài lê thê, các sơ đồ vẽ tùy ý mỗi nơi một kiểu sẽ không được phép tồn tại nữa. Cũng giống như những người tham gia xây dựng một công trình có thể hiểu nhau, cùng làm dựa trên các bản vẽ xây dựng, những người tham gia xây dựng CPĐT sẽ dễ dàng hiểu nhau, cùng phối hợp trên nền một bộ ngôn ngữ mô hình kiến trúc CPĐT chung.

2- Phần mềm xây dựng kiến trúc (enterprise architecture tools)

Nói đến CPĐT tức là nói đến phần mềm là công cụ cơ bản của nó. Vì vậy, xây dựng, bảo trì một kiến trúc CPĐT cụ thể cũng không thể thiếu phần mềm công cụ. Lợi ích của việc dùng phần mềm công cụ có lẽ không cần phải bàn cãi.

Xây dựng CPĐT tức là áp dụng phần mềm, truyền thông vào các công việc, dịch vụ của chính phủ. Vậy thì khi xây dựng kiến trúc CPĐT chẳng có lý do gì không dùng các phần mềm xây dựng kiến trúc hệ thống có sẵn.

Nghiên cứu, lựa chọn một hoặc nhiều phần mềm xây dựng kiến trúc hệ thống là nhiệm vụ của một đề tài riêng, nên được thực hiện và quy định thống nhất trong toàn hệ thống. Một số gợi ý, danh mục có thể xem tại ²⁶, ²⁷

e) Mô hình phát triển

Xây dựng CPĐT, nhất là vào giai đoạn hiện nay bắt đầu dựa vào khung và kiến trúc, chúng ta giống như những người lần đầu tiên xây dựng một ngôi nhà riêng cho mình. Kiến thức, kinh nghiệm, đội ngũ chuyên gia đều rất thiếu. Vì vậy:

• Việc sử dụng tư vấn kỹ thuật nước ngoài là cần thiết. Nhưng có lẽ tư vấn nước ngoài về quản lý quá trình triển khai (ví dụ: quản lý gói thầu xây dựng khung CPĐT nói trên) cũng nên có, nhất là với những dự án đầu tiên.
• Trong mọi lúc, mọi nơi có thể, cần sử dụng các công cụ có sẵn. Như ví dụ đã nêu ở trên, để tìm hiểu so sánh kinh nghiệm xây dựng CPĐT các nước cũng cần có một khung đánh giá và các tiêu chí cụ thể. Thực tế một số công trình đã thực hiện chưa chú ý sử dụng công cụ, suy luận theo nhận thức chủ quan, thậm chí chọn công cụ rồi nhưng không theo đến cùng. Đó là một điều đáng tiếc.
• Thách thức lớn nhất với chúng ta khi bước vào xây dựng, áp dụng kiến trúc CPĐT như đã nói ở trên là kiến thức, kinh nghiệm, đội ngũ chuyên gia đều rất thiếu. Vì vậy, mô hình phát triển kiến trúc CPĐT cho các địa phương, bộ, ngành nên theo hướng “phát huy trí tuệ tập thể”: a/ Công khai hóa quá trình triển khai và các kết quả từng bước trên Internet để mọi người có thể tham gia, b/Chia sẻ, cho phép sử dụng chung các kết quả đạt được và c/Tiến tới xây dựng được một cộng đồng CPĐT bao gồm người quản lý, người thiết kế, người sử dụng, người thử nghiệm, đánh giá, v.v…. ở trong và ngoài nước có thể trao đổi, chia sẻ kinh nghiệm và các kết quả kiến trúc công khai trên mạng (tất nhiên là trừ những phần “mật”).
  Tóm lại là theo mô hình phát triển “mở” tương tự như mô hình phát triển Phần mềm Tự do Nguồn mở. Với nguồn lực nhân sự còn thiếu và yếu, có lẽ đó là cách duy nhất đảm bảo thành công khi triển khai đại trà.

3- Lời kết:

Các ý kiến nêu trên đây chỉ có tính chất gợi mở, đặt vấn đề. Các tài liệu đã dẫn cũng chỉ để nêu vấn đề, tham khảo, không có nghĩa là tài liệu tốt nhất, còn rất nhiều tài liệu khác tương tự. Mỗi vấn đề đặt ra đều đòi hỏi được nghiên cứu đầy đủ, bài bản và sâu sắc hơn bởi một đội ngũ chuyên gia dù chỉ để ra đầu bài, hiểu, điều khiển và đánh giá, nghiệm thu được kết quả của tư vấn.

Trước đây, người viết bài này cũng mới tìm hiểu được một phần về chiến lược và kiến trúc doanh nghiệp điện tử với dự định áp dụng nhưng không có điều kiện thực hiện. Tuy vậy, cũng mạnh dạn đóng góp vì lợi ích chung. Xin cám ơn anh Lê Trung Nghĩa, bộ KHCN đã giúp nhiều tài liệu tham khảo.

Hy vọng là có ích. Mọi ý kiến xin gửi về địa chỉ phanvinhtri@gmail.com.

Tài liệu trích dẫn: