Case Study: Web Portal trên nền tảng Web 3.0

Recommended for you

Vì sao Portal đã trải qua 20 năm mà vẫn đang được săn tìm và đặt hàng tới tấp như vậy? Hãy cùng TIGO đưa ra một insights về nền tảng công nghệ "bình cũ rượu mới" này nhé.

Cổng thông tin Doanh nghiệp, Cục phát triển Doanh Nghiêp (AED), Bộ Kế Hoạch và Đầu Tư do TIGO phát triển. Xem thêm: Launching Cổng thông tin doanh nghiệp AED

Theo định nghĩa, cổng thông tin (Portal) là điểm đi tới của tất cả các ứng dụng và dịch vụ. Về bản chất thì Portal giống như một cái chợ giúp người dùng có thể tận dụng tối đa những tài nguyên có sẵn và nâng cao giá trị của thông tin nhờ trao đổi thường xuyên.

Portal là một giải pháp đa hình – không có mô hình công thức chung (one-size-fits-all) cho tất cả các bài toán. Thí dụ: Portal cho cộng đồng doanh nghiệp, portal cho mạng việc làm, portal cho games....

Thực trạng các Portal hiện nay:

Hệ thống phần mềm “nguyên khối” cứng nhắc xây dựng trên nền tảng Website, khó bảo trì và nâng cấp.
Quá nhiều tính năng phức tạp làm cản trở sự linh hoạt của hệ thống và tăng chi phí phát triển.
Thiếu giải pháp phân loại dữ liệu theo nhiều tiêu chí và nhiều lớp.
Thiếu sự gắn kết giữa các tập dữ liệu khác nhau (thí dụ giữa tin tức và thông tin hỏi đáp FAQ không có kết nối từ khóa hoặc chủ đề).
Thiếu bộ lọc nội dung chất lượng.
Không có hệ thống “Recommendation” đủ tốt do thiếu cơ chế quét từ khóa và phân tích hành vi người dùng.
Chức năng tìm kiếm hoạt động chưa hiệu quả.
Hiệu năng hoạt động thấp do không được thiết kế để vận hành trên môi trường Cloud.

Giao diện Prototype của một Portal

Trước hết chúng ta hãy so sánh giữa các thế hệ Web 1.0, Web 2.0 và Web 3.0 trên bài viết: So sánh các cuộc cách mạng Web 1.0, Web 2.0 và Web 3.0

Rõ ràng để không bị "lạc hậu" sau vài năm nữa, bản thân mô hình Portal cần phải có thay đổi về cả "tinh" và "chất" để có thể phát huy hiệu quả từ các xu hướng đón đầu làn sóng mới. Portal không phải là phá bỏ đi tất cả các di sản của Web 2.0, mà nó có sự kế thừa, có sự giao thoa giữa cái cũ (Web 2.0) và cái mới (Web 3.0).

Giải pháp tổng thể:

Portal là một “mô hình”, không phải là một giải pháp hay một sản phẩm cụ thể. Portal được ứng dụng rộng rãi trong nhiều lĩnh vực như: Portal cho lĩnh vực B2B, Portal cho bất động sản, Portal cho mạng lưới nghề nghiệp, Portal cho văn phòng chính phủ…

Portal truyền thống là một Website mở rộng. Ngày nay Portal được phát triển theo xu hướng “mạng xã hội” (MXH). Portal sẽ là một MXH thu nhỏ trong một thị trường ngách (niche), ở đó người dùng có thể khai thác tối đa khả năng chia sẻ và tìm kiếm một lượng dữ liệu khổng lồ trong ngách đó.

Khả năng scalability của Portal
Portal có thể xem là một "hub" - là nơi đi đến và đi của các services. Các services có thể trao đổi dữ liệu với Portal thông qua cơ chế nhúng trong Porlet (dữ liệu trả về là HTML markups) hoặc thông qua API (trả về json format).

Kiến trúc Portal hiện đại cho phép tương tác 2 chiều mạnh mẽ hơn, sâu rộng hơn. Thí dụ với Portal dành cho cổng thông tin Chính phủ, Collaboration portals (MXH và hợp tác giữa các người dùng) thì mỗi ngày có hàng ngàn câu hỏi được gửi đến qua dịch vụ Information Desk (hoặc HelpDesk). Portal không thể tự xây dựng một dịch vụ riêng để xử lý khối lượng lớn thông tinh như vậy. Nó sẽ chỉ đóng vai trò là nơi trung chuyển, chuyến tiếp dữ liệu đến một dịch vụ thứ ba là "Quản lý Tickets/Requests" và thậm chí chuyển tiếp đến một dịch vụ xa hơn nữa là "Quản lý công việc, nhiệm vụ".

Portal khác với CMS như thế nào?

Portal chia sẻ nhiều tính năng chung với CMS. Bản thân CMS cũng có thể là một "hạt nhân" của Portal. Tuy vậy Portal cần nhiều hơn thế. Hãy lấy thí dụ trang vnexpress, dantri đều base trên nền tảng CMS. Các trang này tập trung nhiều vào nghiệp vụ báo chí và sử dụng công nghệ để theo dõi lượt xem của độc giả. Trong khi đó Portal hướng tới kết nối nhiều hơn. Portal quản lý số lượng tin ít hơn và nó đóng vai trò như một platform để phục vụ công tác tìm kiếm và tra cứu dữ liệu. Đó là lý do vì sao những tính năng rất "hay ho" như tạo TOC động (bảng chỉ mục tự quét các thẻ Heading h1, h2, h3, h4) không phải lúc nào cũng có trên các trang báo điện tử, nhưng sẽ rất thích hợp cho Portal theo mô hình B2B, B2C như portal về bất động sản, portal về jobs...

Có nên tích hợp Drag & Drop Porlets?

Các frameworks lớn đều có sẵn tính năng này. Tuy vậy thì nó có lẽ sẽ không có giá trị lớn nếu người quản trị Portal không thành thạo các thao tác trực quan giống như một lập trình viên, thậm chí còn sinh ra nhiều việc hơn cho Admin/Mod mỗi khi đến kỳ phải nâng cấp giao diện (đôi khi chỉ 1 lần mỗi năm). Mỗi lần "động" vào là chắc chắn một điều là họ sẽ quên các thao tác (ngay cả khi có sổ hướng dẫn) giống như mấy bạn Front-End engineer cả năm mới động vào Photoshop một hai lần thì sẽ không thể thành thục được. Cuối cùng phòng IT của DN đó vẫn phải thuê đội ngũ IT bên ngoài hỗ trợ. Vậy thì có tính năng quản trị Porlet cũng không khác gì so với không có.

Drag & Drop thích hợp cho lập thứ tự các nhóm dữ liệu?
Đúng vậy, bạn có 30 phân loại nhóm dữ liệu. Nếu bạn để thứ tự nhóm chạy lên xuống "tự động" (dựa trên số lượt xem hoặc bài viết mới nhất) thì những nhóm khác sẽ bị trôi xuống. Lúc này ta cần "ghim" (pushpin) nó lại để đảm bảo nó luôn hiển thị trên top. Hoặc chúng ta có thể kéo thả nó vào vị trí ngay đằng sau một chuyên mục ABC nào đó. Tính năng drag & drop thích hợp với sắp xếp dữ liệu hơn là dàn trang (page builder with portlets/widgets). Sắp xếp dữ liệu là công việc "thường xuyên" trong khi dàn trang chỉ "họa hoằn mới có".

Portal xây dựng theo mô hình Mạng Xã Hội?

Không hẳn là giống MXH 100%. Portal có thể là phiên bản lai (hybrid) của MXH và forum, CMS... Hãy quan sát MXH Facebook sẽ thấy dòng chảy thông tin được phân bố rất hợp lý và cực kỳ thông minh. Portal không nhất thiết xây dựng bộ lọc dữ liệu rác thông minh như FB vì quy mô cộng đồng của Portal nhỏ hơn, ít bị tấn công và lợi dụng hơn. Tuy nhiên Portal cần tìm kiếm những giải pháp tiếp cận dữ liệu đúng đối tượng, đúng thời điểm như FB và Google đã và đang thực hiện rất thành công.

Sẽ bắt đầu xây dựng Portal theo lộ trình như thế nào?

Hãy cùng thử tưởng tượng về quá trình vẽ bức ảnh nàng Mona Lisa.

Chúng ta sẽ đặt những tính năng nào vào Iterative hay Incremental?

Iterative bao gồm các phác họa ban đầu chưa có mường tượng rõ rệt về đối tượng cần vẽ (thí dụ một cô gái trong bức ảnh chụp bằng máy ảnh). Những nét vẽ phác thảo đó tương tự với các requirements hết sức mơ hồ và chỉ có thể làm rõ và "mịn" hơn trong suốt quá trình xây dựng. Các thí dụ về các yêu cầu mơ hồ như: Xây dựng tính năng tính điểm KPI (bài toán badgification/gamification), tạo các kiểu hồ sơ mới (custom fields), báo cáo thống kê (custom reports), digest emails, và hàng loạt các bài toán nghiệp vụ mơ hồ khác.

Trong khi đó Incremental bao gồm các tính năng đã được định hình rõ ràng, nó đại diện cho tập các tính năng cốt lõi (core features) mà nhà sản xuất phần mềm đã sở hữu. Việc customize thêm (không quá 20% chẳng hạn) là nằm trong kiểm soát của nhà sản xuất phần mềm do vậy chi phí và chất lượng được đảm bảo.

Các tính năng cốt lõi có thể là: Tìm kiếm dữ liệu, phân quyền (theo roles và permissions), đa ngôn ngữ (localization), quản trị tin tức cơ bản (CMS), Single Sign On...

Kết luận

Kiến trúc thông tin là yếu tố quan trọng quyết định đến “Value Proposition” của hệ thống Portal trong dài hạn..
Portal xây dựng trên các nền tảng mã nguồn mở (DotNetNuke, Liferay…) tiềm ẩn các vấn đề an toàn dữ liệu và đặc biệt không đem lại khả năng “may đo” (customize) tốt nhất vì Open Source phù hợp với Community hơn là Enterprise.
Kiến trúc Micro-Services là một sự lựa chọn tốt hơn “Monolithic” (nguyên khối).
Mã nguồn Portal cần phát triển trên nền tảng công nghệ mới nhất, hạn chế tái sử dụng mã nguồn từ các hệ thống cũ do tiềm ẩn lỗi bảo mật.

Tác giả: Phạm Đình Trường
CEO of TIGO SOLUTIONS

A A A A

Nguồn

{content}