Xác định bài toán trước khi chọn công cụ
Hãy mô tả công việc theo từng bước: ai thực hiện, dữ liệu đi vào và đi ra, điểm phê duyệt, hệ thống cần kết nối và hậu quả khi một bước bị gián đoạn. Sau đó chia yêu cầu thành ba nhóm: bắt buộc, nên có và có thể thay đổi. Cách làm này giúp phân biệt nhu cầu thực sự với thói quen hiện tại.
Gợi ý: lập bảng so sánh mức đáp ứng quy trình, khả năng tích hợp, quyền truy cập dữ liệu, vận hành, chi phí và thời gian triển khai. Với mỗi tiêu chí, ghi bằng chứng cần kiểm tra, chẳng hạn kết quả chạy thử hoặc tài liệu sản phẩm, thay vì chỉ dựa vào bản trình diễn.
Khi phần mềm có sẵn phù hợp hơn
Phần mềm có sẵn đáng cân nhắc khi quy trình tương đối phổ biến và doanh nghiệp có thể điều chỉnh cách làm để dùng chức năng tiêu chuẩn. Nên kiểm tra trên dữ liệu và vai trò người dùng thực tế, đặc biệt ở các điểm nhập xuất dữ liệu, phân quyền, báo cáo, tích hợp, giới hạn sử dụng và cách nhận hỗ trợ.
Ví dụ: một doanh nghiệp cần quản lý yêu cầu nội bộ có thể thử công cụ với một phòng ban. Kịch bản thử gồm tạo yêu cầu, phân công, phê duyệt, tìm kiếm, xuất dữ liệu và xử lý tài khoản của người nghỉ việc. Đây là tình huống minh họa, không phải kết quả triển khai thực tế.
Khi phát triển theo yêu cầu có cơ sở
Phát triển riêng có cơ sở khi quy trình tạo khác biệt đáng kể, yêu cầu tích hợp khó đáp ứng bằng công cụ sẵn có hoặc sản phẩm cần thay đổi theo mô hình kinh doanh. Đổi lại, doanh nghiệp cần người quyết định ưu tiên, nghiệm thu, quản lý dữ liệu, theo dõi lỗi và bố trí nguồn lực bảo trì sau phiên bản đầu tiên.
Không cần chọn một kiểu kiến trúc chỉ vì xu hướng. Hướng dẫn kiến trúc Azure đặt yêu cầu kinh doanh bên cạnh độ tin cậy, bảo mật, chi phí, vận hành và hiệu năng; tài liệu cũng lưu ý hệ thống phân tán cần tính đến lỗi, triển khai và giám sát. Gợi ý thiết kế: chọn cấu trúc mà đội ngũ có thể vận hành và thay đổi được. [1]
Phương án kết hợp cần ranh giới rõ
Doanh nghiệp có thể dùng sản phẩm sẵn có cho nghiệp vụ phổ biến và phát triển phần kết nối hoặc chức năng đặc thù. Gợi ý: xác định hệ thống giữ dữ liệu gốc, chiều đồng bộ, cách xử lý bản ghi trùng, trách nhiệm khi kết nối lỗi và phương án lấy dữ liệu ra. Hãy kiểm tra tài liệu API, giới hạn kỹ thuật và điều kiện sử dụng của sản phẩm định chọn.
Các thành phần tách rời có thể giao tiếp qua API hoặc thông điệp bất đồng bộ, nhưng trạng thái phân tán và thao tác song song cũng làm phát sinh việc phải xử lý. Gợi ý thiết kế: chỉ tách thêm dịch vụ khi lợi ích về vận hành hoặc khả năng thay đổi độc lập đủ rõ so với công sức duy trì. [1]
So sánh chi phí và khả năng thay đổi
Bảng chi phí nên tính cả mua hoặc phát triển, thuê bao, hạ tầng, cấu hình, tích hợp, chuyển dữ liệu, đào tạo, hỗ trợ và bảo trì. Theo hướng dẫn tối ưu chi phí của Microsoft, phương án tối ưu không nhất thiết là phương án rẻ nhất; quyết định kiến trúc cần cân nhắc chi phí cùng bảo mật, khả năng mở rộng, khả năng phục hồi và vận hành. [2]
Gợi ý: so sánh các phương án trong cùng một khoảng thời gian và cùng mức dịch vụ kỳ vọng. Tách khoản chắc chắn khỏi khoản phụ thuộc mức sử dụng hoặc chưa xác định, rồi đặt thời điểm đánh giá lại sau triển khai. Nhu cầu và chi phí có thể thay đổi; bảng so sánh ban đầu nên đủ rõ để cập nhật, không chỉ để phê duyệt một lần.