OpenAPI 3.0 đã trở thành tiêu chuẩn phổ biến trong thiết kế và quản trị API, nhưng vẫn tồn tại một hạn chế lớn: OpenAPI Schema chưa hoàn toàn tương thích với JSON Schema. Sự bất đồng bộ này thường xuyên gây ra những phiền toái không đáng có cho các kỹ sư hệ thống khi phải duy trì hai bộ quy tắc mô tả dữ liệu khác nhau cho cùng một sản phẩm. Điều này làm giảm đáng kể hiệu suất tự động hóa trong các quy trình vận hành phức tạp.

Đó là lý do OpenAPI 3.1 ra đời như một lời giải hoàn hảo cho bài toán chuẩn hóa mô hình dữ liệu toàn cầu. Phiên bản này không thay đổi hoàn toàn cách OpenAPI hoạt động, nhưng giải quyết một trong những vấn đề quan trọng nhất của hệ sinh thái API hiện đại: chuẩn hóa mô hình dữ liệu và đồng bộ hóa với JSON Schema. Đối với nhiều tổ chức đang triển khai API-First Development hoặc API Governance, OpenAPI 3.1 được xem là bước tiến lớn nhất kể từ OpenAPI 3.0.

OpenAPI 3.1 Trong 60 Giây

Trước khi đi vào các phân tích sâu hơn, bảng tóm tắt dưới đây sẽ cung cấp cho bạn những thông tin cốt lõi nhất về phiên bản đặc tả kỹ thuật này. Việc nắm bắt nhanh các thông số này giúp bạn có cái nhìn định hình rõ ràng hơn về lộ trình dịch chuyển của tiêu chuẩn công nghệ.

OpenAPI 3.1 Là Gì?

Định nghĩa OpenAPI 3.1

OpenAPI 3.1 là phiên bản nâng cấp của đặc tả OpenAPI Specification (OAS), giúp tiêu chuẩn API tương thích gần như hoàn toàn với JSON Schema và cải thiện khả năng mô tả, kiểm tra và quản trị dữ liệu API. Bằng việc loại bỏ những vùng xám khác biệt giữa hai bộ tiêu chuẩn lớn, phiên bản 3.1 tạo ra một nền tảng kỹ thuật đồng nhất cho toàn hệ thống phần mềm.

Giờ đây, các công cụ phần mềm và lập trình viên có thể dùng chung một ngôn ngữ mô tả dữ liệu từ khâu thiết kế giao diện, kiểm thử gói tin cho đến khâu vận hành thực tế. Sự hợp nhất này giúp loại bỏ hoàn toàn các lớp thư viện dịch đổi trung gian vốn là nơi thường xuyên phát sinh lỗi trong quá trình tích hợp hệ thống.

OpenAPI 3.1 có phải phiên bản thay thế OpenAPI 3.0 không?

Xét về mặt lộ trình công nghệ, OpenAPI 3.1 là phiên bản kế nhiệm hợp pháp và được khuyến nghị sử dụng cho tương lai dài hạn. Tuy nhiên, trong thực tế, nó không hoạt động theo kiểu khai tử hay thay thế hoàn toàn OpenAPI 3.0 ngay lập tức. Thay vào đó, hai phiên bản này đang cùng tồn tại song song để hỗ trợ cho nhiều mô hình kiến trúc doanh nghiệp khác nhau.

Tình hình áp dụng thực tế cho thấy các dự án cũ, hệ thống kế thừa vẫn đang vận hành cực kỳ ổn định trên nền tảng 3.0 và chưa cần thiết phải dịch chuyển. Trong khi đó, OpenAPI 3.1 đang ghi nhận tốc độ tăng trưởng vượt bậc tại các doanh nghiệp xây dựng hệ thống mới từ đầu, hoặc các tổ chức đòi hỏi quy trình xác thực dữ liệu có độ phức tạp cao.

Vì sao OpenAPI 3.1 được phát triển?

Nguyên nhân gốc rễ thúc đẩy sự ra đời của OpenAPI 3.1 chính là những hạn chế cố hữu về mặt Schema Object của phiên bản 3.0. Ở phiên bản cũ, dù dựa trên JSON Schema nhưng OpenAPI lại tự ý tạo ra một số biến thể riêng biệt không giống ai. Điều này khiến lập trình viên không thể bê nguyên các file validate dữ liệu tiêu chuẩn vào trong file cấu trúc API, gây ra sự trùng lặp lãng phí.

Nhu cầu chuẩn hóa mô hình dữ liệu ngày càng trở nên cấp thiết khi các kiến trúc hiện đại đòi hỏi tính tự động hóa tuyệt đối. Việc duy trì sự bất đồng bộ giữa cấu trúc API và cấu trúc dữ liệu khiến các bộ công cụ sinh code mẫu, sinh tài liệu hoặc kiểm thử tự động thường xuyên gặp lỗi. Do đó, một phiên bản mới đồng bộ hơn là bước đi bắt buộc để giải phóng sức lao động cho kỹ sư.

JSON Schema Là Gì Và Vì Sao Nó Quan Trọng Với OpenAPI?

Khái niệm và vai trò trong validation

Để hiểu được tầm vóc của bản cập nhật 3.1, chúng ta cần làm rõ khái niệm JSON Schema trong thế giới lập trình. Đây là một tiêu chuẩn mở toàn cầu dùng để mô tả và xác thực cấu trúc của các dữ liệu định dạng JSON. It hoạt động như một bộ luật nghiêm ngặt quy định một gói tin JSON hợp lệ phải chứa những trường thông tin nào, kiểu dữ liệu ra sao và các ràng buộc đi kèm.

Trong kiến trúc phần mềm, JSON Schema đóng vai trò là chốt chặn bảo vệ tối cao cho tính toàn vẹn của dữ liệu trước các nguy cơ tấn công. Trước khi một gói tin được hệ thống Backend tiếp nhận và xử lý sâu vào cơ sở dữ liệu, nó bắt buộc phải đi qua bộ lọc này. Nếu gói tin chứa dữ liệu sai định dạng, hệ thống sẽ ngay lập tức từ chối để bảo vệ an toàn cho máy chủ.

Ứng dụng thực tế của JSON Schema

Trong thực tế vận hành, JSON Schema được ứng dụng rộng rãi vào ba nhiệm vụ cốt lõi bao gồm kiểm tra tính hợp lệ của dữ liệu đầu vào, xác thực các gói tin yêu cầu và đối chiếu cấu trúc phản hồi. Nhờ có nó, lập trình viên không cần phải viết hàng ngàn dòng lệnh kiểm tra thủ công trong mã nguồn, giúp code sạch sẽ hơn rất nhiều.

Chính vì JSON Schema quá quan trọng và phổ biến trong thế giới Web API, việc OpenAPI bị lệch pha với nó là một điểm trừ lớn. OpenAPI rất cần tương thích hoàn toàn với JSON Schema để giảm thiểu sự khác biệt giữa hai chuẩn lớn, tăng khả năng tái sử dụng lại các file cấu trúc dữ liệu sẵn có và mở đường cho hệ sinh thái công cụ tự động hóa phát triển lên tầm cao mới.

Những Cải Tiến Quan Trọng Nhất Của OpenAPI 3.1

Tương thích hoàn toàn với JSON Schema

Cải tiến mang tính lịch sử của OpenAPI 3.1 chính là việc tái cấu trúc hoàn toàn Schema Object để đạt mức tương thích 100% với JSON Schema. Điều này có nghĩa là mọi từ khóa, mọi quy tắc định nghĩa dữ liệu của JSON Schema giờ đây đều hợp lệ bên trong tài liệu OpenAPI. Lập trình viên có thể trực tiếp sao chép các tệp cấu trúc dữ liệu phức tạp của hệ thống vào file API mà không cần chỉnh sửa.

Lợi ích thực tế của sự thay đổi này là cực kỳ to lớn đối với các dự án vận hành theo mô hình lớn. Các đội ngũ phát triển không còn phải duy trì hai bộ tài liệu độc lập cho phần cấu trúc và phần kiểm thử dữ liệu nữa. Sự hợp nhất này giúp tiết kiệm một nửa thời gian thiết kế hệ thống và triệt tiêu hoàn toàn các lỗi sai lệch tài liệu giữa các phòng ban.

Hỗ trợ JSON Schema Draft 2020-12

Để hiện thực hóa điều đó, OpenAPI 3.1 đã chính thức tích hợp và hỗ trợ phiên bản JSON Schema Draft 2020-12. Phiên bản này mang đến cho các nhà phát triển những vũ khí cực kỳ mạnh mẽ trong việc xác thực dữ liệu, tiêu biểu như các mệnh đề logic điều kiện nâng cao. Ý nghĩa thực tế là quy trình thiết lập điều kiện validate dữ liệu giờ đây trở nên vô cùng linh hoạt.

Đối với các lập trình viên, việc hỗ trợ Draft 2020-12 đồng nghĩa với việc họ có thể sử dụng các từ khóa nâng cao để mô tả các cấu trúc dữ liệu động. Hệ thống kiểm thử tự động dựa trên file OpenAPI giờ đây có thể phát hiện ra những lỗi dữ liệu tinh vi nhất mà trước đây phiên bản 3.0 đành bất lực bỏ qua, nâng cao đáng kể chất lượng của sản phẩm.

Hỗ trợ Webhooks chính thức

Một bước đi đúng đắn khác của OpenAPI 3.1 là việc đưa Webhooks lên thành một thành phần gốc cấp cao nhất trong cấu trúc tài liệu, đứng ngang hàng với trường paths truyền thống. Webhooks là cơ chế giúp máy chủ chủ động gửi thông báo thời gian thực về cho phía khách hàng khi có một sự kiện kích hoạt diễn ra, ví dụ như thông báo đã nhận được tiền thanh toán.

Trước đây, việc mô tả luồng Webhooks trong phiên bản 3.0 buộc phải nằm lồng bên trong cấu trúc phức tạp của Callbacks, gây khó khăn cho việc đọc hiểu. Việc tách riêng Webhooks trong bản 3.1 giúp các kiến trúc hướng sự kiện được mô tả một cách rõ ràng, mạch lạc, hỗ trợ đắc lực cho công tác thiết kế các hệ thống tích hợp tự động hóa hiện đại.

Đơn giản hóa việc phát triển và quản trị API

Bằng việc mang đến khả năng mô tả dữ liệu chính xác hơn, OpenAPI 3.1 giúp cho bức tranh quản trị hệ thống của doanh nghiệp trở nên vô cùng sáng sủa. Các bộ lọc tự động giờ đây có thể quét qua file thiết kế để đánh giá chất lượng một cách dễ dàng. Quy trình này giúp doanh nghiệp định hình rõ ràng hướng đi của sản phẩm, giảm thiểu xung đột kỹ thuật phát sinh từ sự bất đồng bộ giữa các phòng ban.

OpenAPI 3.1 Khác OpenAPI 3.0 Như Thế Nào?

Bảng so sánh nhanh sự khác biệt

Để giúp bạn có một cái nhìn đối chiếu trực quan và rõ ràng nhất về sự chuyển dịch công nghệ giữa hai phiên bản, bảng dưới đây sẽ liệt kê các tiêu chí thay đổi cốt lõi:

Khác biệt về Schema Object và Validation

Sự khác biệt lớn nhất nằm ở cách thức định nghĩa kiểu dữ liệu trống. Trong phiên bản 3.0, nếu một trường thông tin có thể vừa là chuỗi ký tự vừa có thể để trống, bạn phải khai báo kiểu chuỗi kèm theo một dòng riêng biệt là nullable: true. Sang đến phiên bản 3.1, quy trình này được đơn giản hóa bằng cách sử dụng một mảng kiểu dữ liệu trực tiếp, giúp cấu trúc file gọn gàng hơn.

Về mặt kiểm tra dữ liệu, OpenAPI 3.1 cho phép bạn sử dụng toàn bộ sức mạnh của các từ khóa phức tạp thuộc chuẩn JSON Schema mới. Sự nâng cấp này giúp hệ thống tài liệu kiểm soát cực kỳ chặt chẽ các trường dữ liệu lạ do phía khách hàng cố tình truyền lên nhằm mục đích tấn công. Phiên bản 3.0 trước đây thường bỏ qua các quy tắc này khiến bộ lọc bảo mật bị lỏng lẻo.

Khác biệt về Webhooks và Tool Support

Việc chuyển dịch Webhooks ra thành một trường độc lập đã thay đổi hoàn toàn cách thức thiết kế tài liệu. Lập trình viên không còn phải tạo ra các đường dẫn giả lập để mô tả luồng nhận thông báo như thời kỳ chạy bản 3.0 cũ. Mặc dù hệ sinh thái công cụ hỗ trợ của bản 3.1 đang trong quá trình hoàn thiện, các nền tảng lớn đều đã cập nhật đầy đủ để không bị bỏ lại phía sau.

Ví Dụ OpenAPI 3.1 Trong Thực Tế

Đoạn mã mô tả bằng định dạng YAML

Để kiểm chứng những lý thuyết trên, hãy cùng xem xét một đoạn mã tài liệu OpenAPI 3.1 hoàn chỉnh dưới đây mô tả một hệ thống đăng ký tài khoản thành viên:

Giải thích cấu trúc của đoạn mã mẫu

Nhìn vào dòng đầu tiên, ký hiệu phiên bản thông báo cho các bộ công cụ biết file tuân thủ theo tiêu chuẩn mới nhất. Điểm đáng chú ý đầu tiên là sự xuất hiện của trường webhooks nằm độc lập hoàn toàn ở cùng cấp với trường paths. Nó mô tả một sự kiện kích hoạt sẽ tự động gửi gói tin thông báo về cho phía khách hàng ngay khi tài khoản được kích hoạt thành công trên máy chủ.

Điểm cải tiến mang tính bản chất thứ hai nằm ở mục định nghĩa cấu trúc dữ liệu người dùng ở cuối tệp tin. Tại trường dữ liệu tuổi tác, thay vì dùng thuộc tính bổ trợ lỗi thời của bản 3.0, đoạn mã mẫu đã áp dụng cú pháp mảng chuẩn của phiên bản 3.1. Cách viết này vừa tường minh, vừa giúp các bộ thư viện xác thực dữ liệu chạy mượt mà mà không gặp lỗi.

Có Nên Nâng Cấp Từ OpenAPI 3.0 Lên OpenAPI 3.1 Không?

Khi nào nên tiếp tục sử dụng OpenAPI 3.0?

Quyết định nâng cấp công nghệ luôn là một bài toán chiến lược đòi hỏi sự cân nhắc kỹ lưỡng giữa lợi ích và chi phí đầu tư. Bạn nên tiếp tục duy trì hệ thống chạy phiên bản OpenAPI 3.0 nếu toàn bộ hạ tầng phần mềm hiện tại của doanh nghiệp đang vận hành cực kỳ ổn định. Tính ổn định của một hệ thống cũ đôi khi có giá trị kinh tế cao hơn việc chạy theo xu hướng.

Lý do quan trọng thứ hai để giữ lại bản 3.0 là sự phụ thuộc vào hệ thống công cụ nội bộ của doanh nghiệp. Nếu doanh nghiệp của bạn đang sử dụng các cổng quản lý API cũ được viết từ nhiều năm trước, chúng có thể chưa kịp cập nhật để đọc hiểu được cú pháp của bản 3.1. Việc cố tình nâng cấp trong trường hợp này sẽ làm gián đoạn chuỗi vận hành tự động.

Khi nào nên chuyển sang OpenAPI 3.1?

Ngược lại, việc chuyển dịch hoặc xây dựng mới dựa trên tiêu chuẩn OpenAPI 3.1 là quyết định hoàn toàn đúng đắn đối với các dự án công nghệ khởi nghiệp bắt đầu từ con số không. Việc tiếp cận ngay với chuẩn mới giúp bạn tránh được chi phí chuyển đổi kỹ thuật về sau. Đây cũng là lựa chọn bắt buộc cho các doanh nghiệp đang xây dựng một nền tảng API quy mô lớn cho đối tác.

Nếu hệ thống của bạn yêu cầu các quy trình xác thực dữ liệu đầu vào cực kỳ khắt khe hoặc đang vận hành theo kiến trúc hướng sự kiện phụ thuộc nhiều vào luồng thông báo Webhooks, OpenAPI 3.1 sẽ là vị cứu tinh giúp cắt giảm hàng ngàn giờ lao động thủ công. Nó giúp thiết lập một quy trình quản trị hệ thống chặt chẽ và có khả năng mở rộng vô hạn.

Kinh Nghiệm Triển Khai OpenAPI 3.1 Trong Doanh Nghiệp

Những lợi ích và khó khăn khi nâng cấp

Sau khi thực hiện nâng cấp thành công lên tiêu chuẩn OpenAPI 3.1, lợi ích lớn nhất mà các doanh nghiệp nhận được ngay lập tức là sự nhất quán tuyệt đối của hệ thống dữ liệu. Tình trạng sai lệch kiểu dữ liệu giữa bản thiết kế và bộ lọc xác thực thực tế tại Backend hoàn toàn bị triệt tiêu, giúp giảm thiểu tối đa các lỗi logic ngớ ngẩn trong quá trình lập trình phần mềm.

Tuy nhiên, con đường chuyển dịch công nghệ này cũng ẩn chứa những rào cản không nhỏ đối với các đội ngũ nhân sự. Khó khăn lớn nhất thường đến từ việc các lập trình viên đã quá quen thuộc với tư duy viết file của bản 3.0 cũ và chưa có kiến thức sâu sắc về chuẩn JSON Schema mới. Sự thiếu đồng bộ của một vài công cụ mã nguồn mở cũng là điểm cần lưu ý.

Hướng dẫn các bước chuyển đổi hệ thống (Migration)

Để quá trình chuyển dịch diễn ra êm đẹp mà không làm gián đoạn hệ thống đang vận hành, doanh nghiệp cần thực hiện theo một lộ trình ba bước nghiêm ngặt:

• Bước 1: Đánh giá khả năng tương thích của hệ thống công cụ nội bộ. Hãy liệt kê toàn bộ các phần mềm đang đọc file OpenAPI và kiểm tra xem chúng đã hỗ trợ phiên bản 3.1 hay chưa.
• Bước 2: Tiến hành chuyển đổi thử nghiệm trên một dịch vụ nhỏ. Lập trình viên sẽ sử dụng các công cụ tự động để dịch đổi cú pháp định nghĩa kiểu dữ liệu và đưa vào chạy thử trong môi trường độc lập.
• Bước 3: Tự động hóa quy trình. Sau khi thử nghiệm thành công, doanh nghiệp tiến hành cập nhật đồng loạt các file cấu trúc và cấu hình lại bộ lọc kiểm thử trên hệ thống CI/CD chung.

Bộ quy tắc Best Practices từ chuyên gia

Để tiêu chuẩn mới thực sự phát huy tối đa sức mạnh, doanh nghiệp của bạn nên tuân thủ nghiêm ngặt theo bộ quy tắc Best Practices từ chuyên gia. Đầu tiên, hãy luôn kiên định với tư duy Thiết kế trước trong mọi dự án tính năng mới. Tiếp theo, hãy xây dựng một tệp lưu trữ tập trung toàn bộ các cấu trúc dữ liệu cốt lõi của công ty để các phòng ban tái sử dụng, tránh phân mảnh dữ liệu.

Ưu Điểm Và Hạn Chế Của OpenAPI 3.1

Ưu điểm vượt trội

Ưu điểm lớn nhất biến OpenAPI 3.1 thành tương lai của ngành công nghệ chính là việc hiện thực hóa giấc mơ đồng bộ hóa mô hình dữ liệu toàn cầu thông qua mối liên minh với JSON Schema. Sự đồng nhất này mang đến khả năng kiểm soát dữ liệu mạnh mẽ, giúp công tác quản trị kiến trúc của doanh nghiệp đạt độ chính xác tối đa, biến tệp tài liệu thành một lá chắn bảo vệ an toàn.

Bên cạnh đó, cấu trúc mở rộng linh hoạt với sự xuất hiện độc lập của Webhooks giúp phiên bản này đáp ứng hoàn hảo các mô hình kiến trúc hiện đại nhất thế giới. OpenAPI 3.1 cũng sở hữu độ tương thích tuyệt vời với các hệ thống tự động hóa sử dụng trí tuệ nhân tạo, dọn đường cho doanh nghiệp của bạn dễ dàng tích hợp và làm chủ các công nghệ thông minh.

Hạn chế cần lưu ý

Mặc dù sở hữu những đặc tính ưu việt, OpenAPI 3.1 vẫn có những điểm hạn chế đòi hỏi các nhà quản lý phải nhìn nhận một cách khách quan. Đường cong học tập của phiên bản này tương đối dốc đối với các nhân sự mới do cấu trúc dữ liệu yêu cầu kiến thức nền tảng rất sâu về JSON Schema, đòi hỏi doanh nghiệp phải đầu tư thời gian đào tạo ban đầu.

Hạn chế thứ hai nằm ở tính sẵn sàng của hệ sinh thái công cụ xung quanh. Dù phần lớn các công cụ lớn như Swagger hay các API Gateway hàng đầu đã hỗ trợ hoàn hảo, một số thư viện sinh code mẫu mã nguồn mở quy mô nhỏ do cộng đồng phát triển vẫn đang trong quá trình cập nhật tính năng, đòi hỏi phải kiểm tra kỹ lưỡng trước khi áp dụng.

FAQ – Các Câu Hỏi Thường Gặp

Sự khác biệt cốt lõi nhất giữa OpenAPI 3.1 và 3.0 là gì?
Điểm khác biệt lớn nhất là bản 3.1 tương thích hoàn toàn 100% với chuẩn JSON Schema Draft 2020-12, loại bỏ thuộc tính nullable cũ và tách biệt thành phần webhooks lên cấp cao nhất độc lập.

Có thể sử dụng chung tệp cấu trúc dữ liệu JSON Schema cho OpenAPI 3.1 không?
Hoàn toàn được. Bạn có thể sao chép trực tiếp các tệp định nghĩa JSON Schema tiêu chuẩn vào tài liệu OpenAPI 3.1 mà không cần chỉnh sửa cú pháp, giúp tối ưu hóa khả năng tái sử dụng.

Hệ sinh thái công cụ đã hỗ trợ tốt cho OpenAPI 3.1 chưa?
Tính đến thời điểm hiện tại, hầu hết các nền tảng công nghệ lớn toàn cầu, các cổng API Gateway và bộ công cụ Swagger đều đã hoàn thiện việc hỗ trợ đầy đủ cho các tính năng mới của phiên bản 3.1.

OpenAPI 3.1 có phù hợp cho các dự án API mới không?
Có, đây là sự lựa chọn được khuyến nghị hàng đầu cho các dự án mới nhằm đón đầu các tiêu chuẩn công nghệ tương lai và tránh được chi phí chuyển đổi kỹ thuật phức tạp về sau.

Kết Luận

Tổng kết lại, OpenAPI 3.1 không phải là một cuộc cách mạng đập đi xây lại toàn bộ kiến trúc nền tảng, nhưng nó xứng đáng là bản nâng cấp quan trọng và giá trị nhất của ngành công nghệ API kể từ sau sự ra đời của bản 3.0. Bằng việc giải quyết triệt để bài toán đồng bộ hóa với JSON Schema, phiên bản này đã xóa bỏ hoàn toàn ranh giới phân mảnh dữ liệu, mang đến một quy trình thiết kế, xác thực và quản trị API mượt mà, khoa học và tự động hóa tối đa.

Đối với các dự án công nghệ xây dựng mới hoặc các tổ chức đang kiên định theo đuổi chiến lược phát triển API-First dài hạn, OpenAPI 3.1 không còn là một sự lựa chọn mang tính thử nghiệm, mà chính là nền móng vững chắc bắt buộc phải có để kiến tạo nên một hệ thống hạ tầng số hiện đại, bền vững và sẵn sàng bứt phá trong tương lai.

---

Công ty TNHH Giải pháp Phân tích Dữ liệu Insight Data (INDA) là đơn vị hàng đầu cung cấp các dịch vụ và giải pháp về dữ liệu và trí tuệ nhân tạo (AI). Với chuyên môn sâu trong lĩnh vực Big Data, Data Analytics và AI Data Platform, chúng tôi cung cấp danh mục dịch vụ toàn diện bao gồm tư vấn và triển khai, thuê ngoài nhân sự IT, đào tạo và cung cấp bản quyền phần mềm.

Đội ngũ chuyên gia giàu kinh nghiệm của chúng tôi luôn cam kết đề cao chất lượng, tính chuyên nghiệp và sự thấu hiểu khách hàng – đồng hành cùng doanh nghiệp để mang đến những giải pháp phù hợp, hiệu quả, giúp khai mở tối đa tiềm năng từ dữ liệu.

Một số dịch vụ cơ bản INDA đang cung cấp:

Triển khai kho dữ liệu: Tư vấn, xây dựng, hỗ trợ về Data Warehouse và di chuyển Data Warehouse lên cloud.
Dịch vụ phát triển phần mềm: Tư vấn và hỗ trợ trang bị giấy phép phần mềm bản quyền (License).
Dịch vụ Outsourcing – Cho thuê nhân sự ngành Data: Tuyển dụng và sàng lọc ứng viên, có phương án dự phòng thay thế nhân sự kịp thời.
Dịch vụ Xây dựng Báo cáo BI: Cung cấp giải pháp chuyên sâu về Power BI.