Những sai lầm lựa chọn công nghệ thường gặp

Vì vậy, sai lầm lựa chọn công nghệ thường không nằm ở việc chọn một sản phẩm “kém”, mà ở sự không tương thích giữa giải pháp với yêu cầu, dữ liệu, quy trình, năng lực vận hành hoặc điều kiện phát triển trong tương lai. Những sai lệch ban đầu này thường chỉ bộc lộ rõ sau khi triển khai, khi doanh nghiệp bắt đầu phải trả thêm chi phí tích hợp, tùy chỉnh, đào tạo, vận hành hoặc thay thế hệ thống.

Một quyết định tốt cần xem xét đồng thời yêu cầu chức năng và các đặc tính chất lượng như hiệu năng, khả năng tương thích, độ tin cậy, bảo mật và khả năng bảo trì. Đây cũng là cách tiếp cận phù hợp với các mô hình chất lượng phần mềm như ISO/IEC 25010: không đánh giá một hệ thống chỉ bằng số lượng chức năng mà phải xem xét nhiều đặc tính ảnh hưởng trực tiếp đến khả năng sử dụng và vận hành lâu dài.

Chọn công nghệ trước khi xác định rõ bài toán

Một trong những sai lầm lựa chọn công nghệ phổ biến nhất là bắt đầu bằng câu hỏi “nên dùng công nghệ nào?” thay vì “vấn đề cần giải quyết là gì?”.

Khi yêu cầu chưa được xác định rõ, đội dự án thường đánh giá giải pháp dựa trên danh sách tính năng, mức độ phổ biến hoặc cảm nhận kỹ thuật. Kết quả là một hệ thống có thể đáp ứng rất nhiều chức năng nhưng lại không xử lý tốt những quy trình thực sự quan trọng.

Ví dụ, doanh nghiệp cần một hệ thống phục vụ 200 người dùng nội bộ với quy trình phê duyệt tương đối ổn định nhưng lại lựa chọn một nền tảng được thiết kế cho kiến trúc phân tán quy mô rất lớn. Công nghệ đó không nhất thiết sai về kỹ thuật, nhưng mức độ phức tạp có thể vượt xa nhu cầu thực tế. Doanh nghiệp phải duy trì thêm hạ tầng, công cụ giám sát và năng lực kỹ thuật mà giá trị kinh doanh thu được không tương xứng.

Điều ngược lại cũng xảy ra. Một giải pháp đơn giản có thể đáp ứng nhu cầu hiện tại nhưng không đáp ứng được một yêu cầu bắt buộc như khối lượng giao dịch, thời gian phản hồi, phân quyền hoặc khả năng tích hợp.

Trước khi so sánh công nghệ, cần xác định tối thiểu:

·         Bài toán nghiệp vụ cần giải quyết

·         Nhóm người sử dụng và quy mô sử dụng

·         Chức năng bắt buộc và chức năng có thể bổ sung sau

·         Dữ liệu cần xử lý

·         Yêu cầu hiệu năng và tính sẵn sàng

·         Yêu cầu bảo mật và kiểm soát truy cập

·         Các hệ thống phải tích hợp

·         Giới hạn ngân sách, thời gian và nguồn lực vận hành

Các yêu cầu này không cần được biến thành một tài liệu quá phức tạp, nhưng phải đủ cụ thể để một lựa chọn có thể được chứng minh là phù hợp hoặc không phù hợp. Nếu tiêu chí lựa chọn không tồn tại trước khi xem sản phẩm, quá trình đánh giá rất dễ bị dẫn dắt bởi chính những gì nhà cung cấp đang bán.

Chạy theo xu hướng, thương hiệu hoặc số lượng tính năng

Một công nghệ mới có thể giải quyết những vấn đề mà thế hệ trước xử lý kém hơn, nhưng “mới hơn” không đồng nghĩa với “phù hợp hơn”.

Sai lầm xảy ra khi mức độ phổ biến của một xu hướng công nghệ được dùng thay cho phân tích yêu cầu. Cloud, microservices, AI, low-code, container hay bất kỳ mô hình kiến trúc nào đều có những điều kiện mà chúng tạo ra giá trị, đồng thời có chi phí và giới hạn riêng.

Microservices là một ví dụ điển hình. Kiến trúc này có thể giúp các thành phần được triển khai và mở rộng tương đối độc lập, nhưng đổi lại hệ thống phải xử lý thêm giao tiếp mạng, quan sát hệ thống phân tán, quản lý lỗi giữa dịch vụ, triển khai nhiều thành phần và đảm bảo tính nhất quán dữ liệu. Một ứng dụng có quy mô nhỏ và ít thay đổi có thể không thu được đủ lợi ích để bù cho mức độ phức tạp đó.

Số lượng tính năng cũng dễ tạo ra một đánh giá sai. Hai giải pháp có 100 và 150 tính năng không thể được kết luận rằng giải pháp thứ hai tốt hơn 50%. Giá trị thực tế phụ thuộc vào những chức năng nào cần thiết, tần suất sử dụng và mức độ chúng phù hợp với quy trình.

Một cách đánh giá hữu ích hơn là chia tiêu chí thành ba nhóm:

·         Bắt buộc: Thiếu tiêu chí này thì giải pháp không thể đáp ứng nhu cầu

·         Quan trọng: Có ảnh hưởng đáng kể đến hiệu quả vận hành nhưng có thể xử lý bằng phương án thay thế

·         Tùy chọn: Tạo thêm tiện ích nhưng không quyết định khả năng thành công của hệ thống

Cách phân loại này hạn chế tình trạng một danh sách dài các chức năng phụ làm lu mờ một vài yêu cầu thực sự quan trọng.

Chỉ so sánh giá mua mà bỏ qua tổng chi phí sở hữu

Giá giấy phép hoặc chi phí mua ban đầu chỉ là một phần của chi phí công nghệ.

Một giải pháp có mức giá thấp hơn có thể trở thành phương án đắt hơn nếu doanh nghiệp phải chi nhiều cho tích hợp, tùy chỉnh, hạ tầng, nhân sự vận hành hoặc xử lý các hạn chế của hệ thống trong nhiều năm.

Tổng chi phí sở hữu có thể được xem xét theo mô hình:

TCO = chi phí mua triển khai tích hợp chuyển đổi dữ liệu hạ tầng vận hành hỗ trợ nâng cấp rủi ro gián đoạn chi phí chuyển đổi khi rời hệ thống

Không phải mọi dự án đều có thể xác định chính xác từng khoản ngay từ đầu. Tuy nhiên, việc đưa chúng vào mô hình đánh giá giúp tránh một sai lệch phổ biến: tiết kiệm ở thời điểm mua nhưng phát sinh chi phí lớn hơn trong vận hành.

Giả sử giải pháp A có giá ban đầu 500 triệu đồng, còn giải pháp B là 700 triệu đồng. Nếu A cần thêm 300 triệu đồng tùy chỉnh và mỗi năm tốn thêm 150 triệu đồng vận hành, trong khi B hầu như không cần tùy chỉnh và chỉ phát sinh thêm 70 triệu đồng mỗi năm, thì so sánh 500 với 700 triệu đồng không còn phản ánh đúng quyết định kinh tế.

Ngoài chi phí trực tiếp còn có chi phí cơ hội. Một hệ thống khó thay đổi có thể kéo dài thời gian đưa một chức năng mới vào sử dụng. Một nền tảng cần quá nhiều thao tác thủ công có thể làm tăng chi phí nhân sự. Một giải pháp thiếu công cụ giám sát có thể khiến thời gian phát hiện và xử lý sự cố kéo dài.

Vì vậy, khi đánh giá công nghệ, khoảng thời gian phân tích nên phản ánh vòng đời dự kiến của hệ thống thay vì chỉ ngân sách dành cho giai đoạn triển khai.

Bỏ qua khả năng tích hợp, dữ liệu và kiến trúc hiện hữu

Một công nghệ hiếm khi vận hành độc lập. Nó phải trao đổi dữ liệu với các hệ thống khác, sử dụng cơ chế xác thực chung, tham gia quy trình nghiệp vụ và tồn tại bên cạnh những thành phần đã được triển khai trước đó.

Do đó, một giải pháp có thể rất tốt khi xem xét riêng lẻ nhưng trở nên không phù hợp khi đặt vào kiến trúc thực tế.

Các vấn đề thường chỉ xuất hiện sau khi dự án bắt đầu gồm:

·         Không có API đáp ứng luồng tích hợp cần thiết

·         Định dạng dữ liệu không tương thích

·         Đồng bộ dữ liệu cần nhiều bước trung gian

·         Cơ chế xác thực không phù hợp với hệ thống danh tính hiện hữu

·         Phải xây thêm middleware chỉ để kết nối các nền tảng

·         Không hỗ trợ phiên bản giao thức hoặc chuẩn dữ liệu đang sử dụng

·         Việc chuyển dữ liệu cũ phức tạp hơn dự kiến

Chi phí tích hợp không chỉ xuất hiện một lần. Mỗi lớp kết nối tùy chỉnh tạo thêm một thành phần phải kiểm thử, giám sát, bảo trì và điều chỉnh khi một trong hai hệ thống thay đổi.

ISO/IEC/IEEE 42010 nhấn mạnh việc xem kiến trúc thông qua các bên liên quan và các mối quan tâm của họ. Trong lựa chọn công nghệ, điều này có ý nghĩa thực tế: không thể đánh giá một thành phần chỉ theo đặc tính riêng của nó mà phải xem nó sẽ tham gia vào kiến trúc tổng thể như thế nào.

Trước khi lựa chọn, cần kiểm tra các điểm kết nối chính bằng dữ liệu và luồng nghiệp vụ thực tế. Một tài liệu ghi “có API” chưa đủ. Cần biết API hỗ trợ thao tác nào, giới hạn ra sao, cơ chế xác thực gì và liệu dữ liệu cần thiết có thực sự được truy cập hay không.

Đánh giá thiếu các yêu cầu phi chức năng

Nhiều quá trình lựa chọn tập trung mạnh vào câu hỏi hệ thống “làm được gì” nhưng ít xem xét hệ thống “làm việc đó tốt đến mức nào”.

Đây là khoảng cách giữa yêu cầu chức năng và yêu cầu phi chức năng.

Một hệ thống có thể có đầy đủ chức năng nhưng vẫn không phù hợp nếu phản hồi quá chậm ở tải thực tế, khó bảo trì, không đạt yêu cầu bảo mật hoặc không thể phục hồi trong thời gian doanh nghiệp chấp nhận được.

Những tiêu chí cần được lượng hóa khi có thể. Thay vì yêu cầu “hệ thống phải nhanh”, có thể xác định thời gian phản hồi mục tiêu cho các giao dịch quan trọng. Thay vì “hệ thống phải ổn định”, nên xác định mức thời gian hoạt động hoặc thời gian phục hồi có thể chấp nhận. Nếu cần mở rộng, phải xác định tải hiện tại, tải dự kiến và điều kiện tăng tải.

Các nhóm cần xem xét thường gồm:

Hiệu năng và khả năng mở rộng

Cần kiểm tra hệ thống ở tải gần với điều kiện sử dụng thực tế. Một thử nghiệm với 10 người dùng không chứng minh rằng hệ thống có thể phục vụ 1.000 người dùng đồng thời.

Khả năng mở rộng cũng phải gắn với chi phí. Một nền tảng có thể mở rộng kỹ thuật nhưng nếu mỗi lần tăng tải đều đòi hỏi chi phí hạ tầng tăng quá nhanh thì nó vẫn có thể không phù hợp về kinh tế.

Độ tin cậy và khả năng phục hồi

Cần xác định hậu quả khi hệ thống ngừng hoạt động và thời gian gián đoạn có thể chấp nhận. Những hệ thống hỗ trợ hoạt động trọng yếu cần được đánh giá về sao lưu, khôi phục, dự phòng và khả năng xử lý lỗi chứ không chỉ kiểm tra chức năng khi mọi thành phần hoạt động bình thường.

Bảo mật

Bảo mật phải được xem như tiêu chí lựa chọn ngay từ đầu. Các yêu cầu về xác thực, phân quyền, ghi nhật ký, mã hóa, quản lý lỗ hổng và kiểm soát truy cập có thể ảnh hưởng trực tiếp đến kiến trúc và chi phí triển khai.

Nếu chỉ kiểm tra bảo mật sau khi đã chọn nền tảng, doanh nghiệp có thể phải mua thêm sản phẩm, xây lớp kiểm soát bổ sung hoặc chấp nhận những giới hạn khó khắc phục.

Khả năng bảo trì và vận hành

Một hệ thống không kết thúc khi được đưa vào sử dụng. Nó cần giám sát, nâng cấp, xử lý lỗi, sao lưu và hỗ trợ người dùng.

Nếu công nghệ yêu cầu một bộ kỹ năng mà tổ chức không có, chi phí nhân sự và rủi ro phụ thuộc vào một số ít chuyên gia sẽ tăng. Vì vậy, tính phù hợp phải được đánh giá cùng với năng lực của đội ngũ sẽ chịu trách nhiệm vận hành hệ thống.

Bỏ qua vòng đời công nghệ, nhà cung cấp và khả năng thoát khỏi hệ thống

Một lựa chọn có thể phù hợp ở thời điểm triển khai nhưng trở thành gánh nặng khi sản phẩm thay đổi chính sách, ngừng hỗ trợ hoặc khiến dữ liệu và quy trình phụ thuộc quá sâu vào một nền tảng.

Đây là lý do cần đánh giá vòng đời công nghệ và mức độ phụ thuộc nhà cung cấp trước khi đưa ra quyết định.

Vendor lock-in không phải lúc nào cũng xấu. Sử dụng sâu các dịch vụ đặc thù của một nền tảng có thể giúp triển khai nhanh hơn và giảm đáng kể công sức xây dựng hệ thống. Vấn đề xuất hiện khi doanh nghiệp chấp nhận sự phụ thuộc đó mà không biết chi phí chuyển đổi sẽ lớn đến mức nào.

Một số câu hỏi cần được kiểm tra gồm:

·         Dữ liệu có thể xuất ra ở định dạng sử dụng được hay không

·         Có thể chuyển sang nhà cung cấp khác nếu cần không

·         Những thành phần nào sử dụng công nghệ độc quyền

·         Chính sách giá có thể ảnh hưởng thế nào khi quy mô tăng

·         Sản phẩm có lộ trình hỗ trợ rõ ràng không

·         Doanh nghiệp có phụ thuộc quá nhiều vào đội ngũ của nhà cung cấp không

·         Có đủ chuyên gia và tài liệu để tự vận hành những phần quan trọng không

Cuối cùng, những giả định quan trọng nên được kiểm chứng bằng proof of concept hoặc pilot trước quyết định đầu tư lớn. Tuy nhiên, thử nghiệm chỉ có giá trị khi tái hiện đúng rủi ro cần kiểm tra.

Nếu lo ngại hiệu năng, phải thử với tải phù hợp. Nếu rủi ro nằm ở tích hợp, cần kết nối với hệ thống thật hoặc môi trường tương đương. Nếu vấn đề là chuyển đổi dữ liệu, cần thử với dữ liệu đại diện. Một demo được nhà cung cấp chuẩn bị sẵn chỉ chứng minh rằng sản phẩm hoạt động trong kịch bản demo, không chứng minh rằng nó phù hợp với môi trường của doanh nghiệp.

Sai lầm lớn nhất trong lựa chọn công nghệ là xem quyết định này như việc tìm ra “công nghệ tốt nhất”. Trong thực tế, mục tiêu cần tìm là công nghệ phù hợp nhất với một tập hợp yêu cầu và giới hạn cụ thể.

Một lựa chọn bền vững cần bắt đầu từ bài toán, sau đó đánh giá sự phù hợp về chức năng, kiến trúc, dữ liệu, hiệu năng, bảo mật, khả năng vận hành và vòng đời. Chi phí cũng phải được nhìn theo toàn bộ thời gian sử dụng thay vì chỉ giá mua ban đầu.

Khi các tiêu chí được xác định trước, những công nghệ hấp dẫn nhưng không cần thiết sẽ dễ bị loại bỏ, còn những rủi ro như tích hợp phức tạp, chi phí vận hành cao hay phụ thuộc nhà cung cấp có thể được nhận diện trước khi chúng trở thành chi phí thực tế.