Phạm vi và độ rõ của yêu cầu
Một chức năng có thể trông đơn giản trên giao diện nhưng bao gồm nhiều quy tắc phía sau: phân quyền, kiểm tra dữ liệu, thông báo, lịch sử thay đổi và xử lý ngoại lệ. Chi phí thường tăng khi số vai trò, luồng nghiệp vụ và trường hợp đặc biệt tăng. Yêu cầu chưa rõ còn tạo thêm thời gian phân tích, làm lại thiết kế và kiểm thử sau khi phát triển.
Gợi ý: chia yêu cầu thành ba nhóm gồm bắt buộc để vận hành, cần có trong giai đoạn gần và có thể bổ sung sau. Mỗi chức năng nên có điều kiện hoàn thành cụ thể. Ví dụ: thay vì ghi “quản lý đơn hàng”, hãy xác định ai được tạo, sửa, hủy, trạng thái nào được chuyển tiếp và dữ liệu nào cần lưu lịch sử.
Mức chất lượng doanh nghiệp cần
Ứng dụng cần phục vụ ít người trong giờ hành chính sẽ có bài toán khác hệ thống phải hoạt động liên tục, chịu tải biến động hoặc xử lý dữ liệu nhạy cảm. Tài liệu kiến trúc Microsoft xem độ tin cậy, bảo mật, chi phí, vận hành và hiệu năng là các khía cạnh cần được cân nhắc cùng yêu cầu kinh doanh. Nâng một khía cạnh thường kéo theo đánh đổi ở khía cạnh khác. [2]
Gợi ý: mô tả yêu cầu phi chức năng bằng tình huống có thể kiểm tra, chẳng hạn số người dùng đồng thời dự kiến, thời gian phản hồi chấp nhận được, cách khôi phục khi lỗi và phạm vi nhật ký cần lưu. Không nên dùng các từ tuyệt đối như “không bao giờ gián đoạn” hoặc “an toàn hoàn toàn” nếu chưa xác định cơ chế đo và ngân sách tương ứng.
Kiến trúc và lựa chọn công nghệ
Kiến trúc nguyên khối, nhiều dịch vụ tách biệt hay mô hình xử lý bất đồng bộ tạo ra mức độ phức tạp khác nhau. Theo hướng dẫn của Microsoft, ứng dụng đám mây không bắt buộc phải dùng microservices; phong cách kiến trúc cần phù hợp mục tiêu và đặc điểm tải. Các lựa chọn về tài nguyên tính toán, kho dữ liệu và nhắn tin cũng ảnh hưởng trực tiếp đến thiết kế. [2]
Gợi ý: ưu tiên kiến trúc đơn giản nhất vẫn đáp ứng được quy mô, khả năng bảo trì và kế hoạch mở rộng đã biết. Công nghệ mới chỉ nên được chọn khi giải quyết một ràng buộc rõ ràng. Việc tách quá nhiều thành phần từ đầu có thể làm tăng công sức triển khai, giám sát, xử lý lỗi liên dịch vụ và phối hợp giữa các nhóm.
Tích hợp, dữ liệu và nền tảng sử dụng
Kết nối với hệ thống kế toán, thanh toán, đăng nhập doanh nghiệp hoặc thiết bị chuyên dụng thường cần khảo sát API, định dạng dữ liệu, quyền truy cập và cách xử lý khi dịch vụ ngoài bị gián đoạn. Di chuyển dữ liệu cũ còn phụ thuộc chất lượng dữ liệu, quy tắc đối chiếu và yêu cầu kiểm tra sau chuyển đổi. Phát triển đồng thời cho web, iOS và Android cũng làm tăng phạm vi thiết kế và kiểm thử.
Gợi ý: lập danh sách từng tích hợp, đơn vị sở hữu, tài liệu kỹ thuật hiện có, môi trường thử nghiệm và dữ liệu mẫu. Với dữ liệu cũ, nên thử chuyển một tập nhỏ trước khi ước lượng toàn bộ. Cách làm này giúp tách chi phí phát triển chức năng mới khỏi chi phí làm sạch dữ liệu hoặc xử lý hạn chế của hệ thống bên ngoài.
Vận hành và thay đổi sau phát hành
Ngân sách không kết thúc khi ứng dụng được đưa vào sử dụng. Hạ tầng, giám sát, sao lưu, hỗ trợ người dùng, cập nhật phụ thuộc và điều chỉnh theo tải đều tạo chi phí tiếp diễn. Microsoft lưu ý rằng tối ưu chi phí không đồng nghĩa với chọn phương án rẻ nhất; cần theo dõi mức sử dụng và đánh giá lại kiến trúc, yêu cầu cùng hiệu quả đầu tư theo thời gian. [1]
Gợi ý: tách dự toán thành chi phí xây dựng ban đầu, chi phí vận hành định kỳ và ngân sách thay đổi. Khi so sánh phương án tự xây với mua sản phẩm có sẵn, hãy tính cả phí sử dụng, cấu hình, tích hợp, đào tạo và công sức vận hành. Đồng thời thống nhất cách tiếp nhận lỗi, ưu tiên cải tiến và phê duyệt phần việc ngoài phạm vi để ngân sách dễ kiểm soát. [1]