Dịch Vụ Phát Triển Phần Mềm Doanh Nghiệp: Bạn Mua Gì

Dịch vụ phát triển phần mềm doanh nghiệp, theo cách hầu hết agency dùng cụm này, là cùng công việc đó gắn con số lớn hơn. Vẫn đội đó, vẫn quy trình đó, hồ sơ chào hàng thêm bức tường logo, giá gấp ba. Bên mua biết vậy, nên bộ phận mua sắm học cách bỏ qua từ này và đọc phụ lục hợp đồng.

Bên dưới có một khác biệt thật, và nó không nằm ở quy mô công ty. Hãng bảo hiểm 40 người chạy được chương trình doanh nghiệp đúng nghĩa; nhà bán lẻ 12.000 người có thể đặt thứ thực chất chỉ là website. Cái tách hai bên là nghĩa vụ hệ thống áp lên bên xây: phải nói chuyện với bao nhiêu hệ thống, được ngừng bao lâu, ai chặn được phát hành, cơ quan quản lý nào quan tâm, và chuyện gì xảy ra nếu nhà cung cấp bỏ đi.

Phần sau định nghĩa nhóm này bằng chính các nghĩa vụ đó, để bên mua phân biệt nhà cung cấp gánh nổi chúng với bên chỉ dán trang bìa doanh nghiệp lên dự án thường.

Điều gì thật sự khiến một dự án phần mềm là doanh nghiệp? Không phải quy mô bên mua. Dự án là doanh nghiệp khi nó mang các ràng buộc dự án thường không có: bề mặt tích hợp rộng, nghĩa vụ hợp đồng về khả dụng và phục hồi, phơi nhiễm quy định, nhiều nhóm liên quan đều chặn được một lần phát hành, khối lượng dữ liệu phá vỡ thiết kế ngây thơ, và phải sống chung với hệ thống nay không ai hiểu. Chính các ràng buộc đó, không phải tính năng, quyết định kiến trúc và phần lớn chi phí.

Điều gì khiến một dự án là doanh nghiệp

Phép thử hữu ích là một danh sách ràng buộc, và dự án đủ tiêu chuẩn khi nó mang phần lớn chứ không phải một trong số đó. Áp dụng trung thực, nó loại bỏ nhiều thứ đang được bán như doanh nghiệp, và thu nhận những việc bị bán như dự án nhỏ rồi thất bại vì được ước lượng như dự án nhỏ.

Bề mặt tích hợp

Hãy đếm số hệ thống mà phần mềm mới phải trao đổi dữ liệu, rồi đếm số đội hoặc nhà cung cấp riêng biệt sở hữu chúng. Con số thứ hai mới dự báo chi phí. Ba tích hợp do một đội nội bộ sở hữu là hai tuần việc. Ba tích hợp do ba nhà cung cấp sở hữu, mỗi bên có cửa sổ thay đổi, lịch mở sandbox và bàn hỗ trợ riêng, là một quý.

Mỗi chủ sở hữu mang tới một lịch bạn không kiểm soát. Nhà cung cấp làm mới sandbox hằng tháng quyết định nhịp kiểm thử của bạn, và bên thanh toán mất sáu tuần chứng nhận quyết định ngày lên sóng. Với hơn mười đối tác, lịch tích hợp trở thành kế hoạch dự án, còn phát triển thì lấp vào các khe trống.

Nghĩa vụ về thời gian hoạt động

Phần mềm thường được kỳ vọng là chạy. Phần mềm doanh nghiệp có một con số gắn vào kỳ vọng đó, thường nằm trong hợp đồng kèm tín dụng dịch vụ. Con số này thay đổi kiến trúc trước tiên, vì một triển khai đơn thể không giữ nổi nó dù mã có tốt đến đâu.

Bước từ mục tiêu chấp nhận cửa sổ bảo trì sang mục tiêu không chấp nhận là dòng đắt nhất trong hầu hết ngân sách doanh nghiệp, và nó thường do những người chưa từng thấy cái giá ấy chốt. Bài viết của chúng tôi về SLA khả dụng có ý nghĩa nói về cách các con số này được viết, và cách chúng thường xuyên bị viết sai.

Các bên liên quan có quyền phủ quyết

Dự án thường có một chủ sản phẩm. Dự án doanh nghiệp có chủ sản phẩm, bộ phận an toàn thông tin, cán bộ bảo vệ dữ liệu, phụ trách mua sắm, đội hạ tầng sở hữu mạng, bàn dịch vụ sẽ thừa hưởng gánh nặng hỗ trợ, và thường có thêm người duyệt về lâm sàng, pháp lý hoặc tuân thủ.

Bất kỳ ai trong số đó cũng chặn được một lần phát hành, và không ai báo cáo cho người trả tiền. Vì vậy quyết định tốn thời gian trên lịch, không liên quan tới độ khó, và nhà cung cấp không tính điều đó vào kế hoạch sẽ trượt mọi mốc từ tháng thứ hai trở đi.

Những hệ thống không còn ai hiểu

Mọi hệ sinh thái doanh nghiệp đều chứa ít nhất một hệ thống mà hành vi của nó chỉ được ghi lại qua đầu ra. Người viết nó đã đi, và bản đặc tả, nếu còn, mô tả một phiên bản cũ hơn. Nó chạy, nó gánh nghiệp vụ, và ai cũng cho rằng sửa nó là không khôn ngoan.

Phần mềm mới phải sống chung với nó, nên trước hết phải có người xác lập nó thật sự làm gì. Đó là khảo cổ, không phải phát triển: đọc dữ liệu sản xuất, lần theo lời gọi, chạy thí nghiệm có kiểm soát trên một bản sao, và viết ra các quy tắc mà mã ngụ ý. Trên một hệ sinh thái lớn, đó là vài tuần việc, và là hạng mục hay bị xoá nhất khi thương thảo vì nó không tạo ra tính năng nhìn thấy được.

Xoá nó chỉ đẩy công việc sang khâu kiểm thử tích hợp, nơi những người đang sửa lỗi phát hiện ra nó dưới áp lực thời gian. Nhà cung cấp báo giá riêng cho khâu khảo sát và bảo vệ được khoản đó đang nói với bạn một điều thật về cách các chương trình này thất bại. Ghi chú của chúng tôi về hiện đại hoá hệ thống cũ, viết lại hay tái cấu trúc nói về những gì cuộc khảo cổ đó tìm thấy.

Mua sắm chiếm một nửa công việc

Phần lớn dân kỹ thuật ước lượng thiếu phần này ba lần. Trong một hợp đồng doanh nghiệp đúng nghĩa, công việc giữa cuộc trò chuyện đầu tiên và dòng mã đầu tiên kéo dài hơn phần bàn giao đầu tiên, và ngốn thời gian của người cấp cao ở cả hai phía.

Từ ngày 24 tháng 2 năm 2025, khu vực công tại Anh vận hành theo Procurement Act 2023, và nhà cung cấp dự thầu hợp đồng công phải đăng ký trên nền tảng số trung tâm trong dịch vụ Find a Tender mở rộng. Mua sắm khu vực tư không có cửa vào duy nhất tương đương, và nghịch lý là điều đó làm nó chậm hơn, vì mỗi bên mua tự phát minh một quy trình.

Bảng câu hỏi bảo mật

Bạn sẽ nhận một bảng tính. Nó hỏi về vòng đời phát triển, kiểm soát truy cập, nhịp vá lỗi, nhà thầu phụ, nơi lưu trú dữ liệu, thời gian ứng cứu sự cố và việc thẩm tra lý lịch. Bên mua lớn gửi vài trăm câu, còn một ngân hàng hay một NHS trust còn gửi nhiều hơn.

Câu hỏi không khó, nhưng chỉ trả lời được nếu câu trả lời đã tồn tại dưới dạng chính sách. Nhà cung cấp lần đầu ráp chúng lại ngay trong lúc dự thầu mất bốn đến sáu tuần và trả lời sai vài câu. Bên đã làm rồi trả lời trong vài ngày từ một thư viện câu trả lời được duy trì. Đó là lý do chính đáng để ưu tiên họ.

Đăng ký nhà cung cấp, bảo hiểm và thẩm định tài chính

Việc đăng ký tách khỏi hồ sơ thầu và thường chạy song song. Bạn sẽ phải chứng minh bảo hiểm trách nhiệm nghề nghiệp và trách nhiệm mạng ở mức bên mua quy định, bảo hiểm trách nhiệm chủ sử dụng lao động, đôi khi cả trách nhiệm sản phẩm. Bên mua doanh nghiệp thường đòi hạn mức mà một công ty tư vấn nhỏ không có sẵn, và nâng mức bảo hiểm giữa chừng thì mất thời gian.

Tiếp theo là thẩm định tài chính. Bên mua rút báo cáo tài chính đã nộp, chấm điểm tín dụng, và với hợp đồng lớn thì đòi báo cáo quản trị hoặc bảo lãnh công ty mẹ. Nhà cung cấp có bảng cân đối không đỡ nổi giá trị hợp đồng sẽ bị loại bất kể năng lực kỹ thuật, và đó là lý do các công ty nhỏ giỏi nghề thua những gói thầu vốn hợp với họ.

Vì sao chu kỳ bán hàng dài hơn phần bàn giao đầu tiên

Đặt hai dòng thời gian cạnh nhau là thấy hình dạng của vấn đề. Sàng lọc, làm rõ yêu cầu, rà soát bảo mật, đàm phán pháp lý, chứng minh bảo hiểm và đăng ký thường chiếm bốn đến chín tháng trên hợp đồng vài trăm nghìn GBP. Phần phần mềm hữu ích đầu tiên, khi đã bắt tay vào việc, có thể mất mười tuần.

Ước lượng viết ở đầu chu kỳ đó đã cũ khi ký, và nhà cung cấp giữ giá cố định suốt quãng ấy hoặc đang đệm rất dày hoặc định cãi nhau về phạm vi sau này. Giả định công nghệ cũng già đi: phiên bản còn hiện hành lúc dự thầu có thể đã hết hỗ trợ lúc khởi động.

Hãy ghi ngày cho mọi ước lượng, nêu rõ giả định, và thoả thuận một bước lập lại đường cơ sở khi ký thay vì giả vờ con số vẫn còn giá trị. Bên mua khăng khăng giữ con số ban đầu đang mua một dây chuyền yêu cầu thay đổi. Hướng dẫn của chúng tôi về cách viết RFP phần mềm nhận được báo giá hữu ích nói rõ tài liệu đó cần có gì.

Sản phẩm bàn giao thật sự là yêu cầu phi chức năng

Danh sách tính năng dễ viết và hiếm khi quyết định điều gì. Yêu cầu phi chức năng mới quyết định kiến trúc, hoá đơn hạ tầng, quy mô đội và độ dài chu kỳ kiểm thử, vậy mà trong hầu hết chương trình doanh nghiệp chúng chỉ dài hai đoạn trong một tài liệu có danh sách tính năng bốn mươi trang.

Sự mất cân đối đó là dấu hiệu đáng tin nhất báo trước vượt tiến độ. Nhà cung cấp dành buổi hội thảo đầu tiên cho khả dụng, phục hồi, độ trễ, thông lượng, khả năng kiểm toán và thời hạn lưu trữ không phải đang câu giờ: sáu con số ấy loại bỏ phần lớn lựa chọn kiến trúc, và chốt muộn nghĩa là xây lại.

Hãy viết chúng thành phát biểu kiểm chứng được, có số và có điều kiện. “Hệ thống phải có tính sẵn sàng cao” không phải yêu cầu. “Dịch vụ đặt hàng phải duy trì khả dụng 99,9% hằng tháng đo tại bộ cân bằng tải, trừ một cửa sổ hai giờ báo trước năm ngày làm việc” mới là, vì một bài kiểm thử có thể đánh trượt nó.

Điểm phục hồi và thời gian phục hồi, nói cho dễ hiểu

Hai trong số các con số đó đẩy chi phí hơn mọi tính năng, và thường được nhắc bởi những người đã tráo nghĩa của chúng. Mục tiêu điểm phục hồi (RPO) là bạn chấp nhận mất bao nhiêu dữ liệu: RPO một giờ nghĩa là bạn chấp nhận tối đa một giờ giao dịch biến mất sau thảm hoạ, và cơ chế sao lưu hoặc nhân bản phải bảo đảm không tệ hơn thế. Mục tiêu thời gian phục hồi (RTO) là bạn chấp nhận ngừng bao lâu, nên RTO bốn giờ nghĩa là dịch vụ phục vụ lưu lượng trở lại trong vòng bốn giờ kể từ khi sự cố bắt đầu.

Cả hai con số dịch thẳng thành kiến trúc. AWS nêu bốn chiến lược lớn trong hướng dẫn khôi phục thảm hoạ: sao lưu và khôi phục, pilot light, warm standby, và đa vùng active/active. Chúng chạy từ rẻ và chậm tới đắt và gần như tức thì, và lựa chọn được quyết định thay bạn ngay khi hai mục tiêu được chốt.

Đừng chốt các con số quyết liệt chỉ vì chúng nghe có trách nhiệm. RPO bằng không cùng RTO tính bằng phút nghĩa là nhân bản liên tục và một môi trường sống thứ hai, tăng gấp đôi hoá đơn hạ tầng. Bài của chúng tôi về khôi phục thảm hoạ cho đội phần mềm nhỏ cho thấy các bậc rẻ hơn mua được gì.

Số học về khả dụng và thứ một SLA thật sự mua được

Tỷ lệ khả dụng giấu ý nghĩa sau dấu thập phân. Trong tháng 30 ngày, 99,9% cho phép khoảng 43 phút ngừng, 99,95% khoảng 22 phút, và 99,99% khoảng 4 phút. Đó là toàn bộ ngân sách của cả tháng, gồm cả triển khai, gia hạn chứng chỉ và lần chuyển đổi cơ sở dữ liệu lâu hơn dự tính.

Bốn phút mỗi tháng là điều một đội triển khai trong giờ hành chính và gọi một kỹ sư không làm nổi. Nó cần dự phòng ở mọi tầng, tự động chuyển đổi, triển khai không ngắt lưu lượng, và một người còn thức lúc ba giờ sáng. Hạng mục cuối thường đắt hơn hạ tầng và gần như không bao giờ có trong ngân sách gốc. Hãy chốt cả điểm đo trong hợp đồng, vì khả dụng đọc tại bộ cân bằng tải và khả dụng đọc từ telemetry người dùng thật có thể lệch một bậc trong cùng một sự cố.

Độ trễ, thông lượng và tải chưa ai đo

Mục tiêu độ trễ cần một phân vị và một phạm vi, vì trung bình che mất các thất bại. Mục tiêu “200 mili giây ở phân vị 95 cho endpoint thanh toán dưới 400 yêu cầu mỗi giây” là kiểm chứng được. Mục tiêu “nhanh” thì không, và trung bình cũng vậy, vì trung bình 200 mili giây vẫn tương thích với việc một trong hai mươi người dùng chờ bốn giây.

Thông lượng cần đỉnh, không phải trung bình. Bán lẻ tính theo thứ Sáu trước Giáng sinh, hệ thống lương theo ngày làm việc cuối tháng, dịch vụ công theo hạn ghi trong thư đã gửi. Tính theo trung bình năm là cách một đợt ra mắt hỏng ngay giờ cao điểm đầu tiên. Hãy lấy đỉnh từ log hệ thống hiện có, nơi tỷ lệ mười trên một là chuyện thường, vì tỷ lệ đó quyết định thiết kế có cần hàng đợi hay không.

Khả năng kiểm toán và thời hạn lưu trữ

Bên mua chịu quản lý, và ngày càng nhiều bên không chịu quản lý, cần trả lời ai đã đổi gì và khi nào, sau nhiều năm. Đó là yêu cầu thiết kế chứ không phải cấu hình log: hệ thống ghi đè bản ghi không trả lời được, và câu trả lời phải sống đúng bằng thời hạn chính sách lưu trữ quy định.

Hãy chốt sớm ba điều. Sự kiện nào cần kiểm toán, thường là thay đổi trạng thái của bản ghi có ý nghĩa pháp lý hoặc tài chính chứ không phải mọi yêu cầu HTTP. Mỗi loại bản ghi giữ bao lâu, một câu hỏi pháp lý kèm ràng buộc bảo vệ dữ liệu, vì giữ dữ liệu cá nhân lâu hơn mức cần thiết tự nó đã là vi phạm. Và ai được đọc dấu vết đó, vì một nhật ký kiểm toán mà quản trị viên sửa được thì chẳng chứng minh điều gì. Quyền lưu trữ và quyền xoá va nhau ở đây, và căng thẳng ấy được giải trong lược đồ dữ liệu chứ không phải trong chính sách.

Những chứng nhận bên mua sẽ hỏi

Có ba thứ xuất hiện lặp đi lặp lại, chúng liên tục bị lẫn lộn, và chúng chứng minh những điều khác nhau. Nhà cung cấp không giải thích được khác biệt thì không nắm giữ chúng.

Cyber Essentials và Cyber Essentials Plus

Cyber Essentials là mức nền do chính phủ Anh hậu thuẫn, do NCSC xây dựng và cung cấp qua IASME với tư cách đối tác triển khai chính thức. Nó bao gồm năm kiểm soát kỹ thuật: tường lửa, cấu hình an toàn, quản lý cập nhật bảo mật, kiểm soát truy cập người dùng và chống mã độc. Mức cơ bản là bảng tự đánh giá được rà soát độc lập, và NCSC niêm yết giá từ GBP 320 cộng VAT tuỳ quy mô tổ chức.

Cyber Essentials Plus là chính năm kiểm soát đó nhưng được kiểm toán kỹ thuật độc lập xác minh thay vì chỉ khai báo. Đơn vị đánh giá quét lỗ hổng nội bộ và bên ngoài, rồi kiểm tra mẫu thiết bị người dùng, cổng internet và máy chủ hướng ra internet. Cuộc kiểm toán Plus phải hoàn tất trong ba tháng kể từ chứng nhận cơ bản, và cả hai chứng nhận có hiệu lực mười hai tháng.

Cơ chế này quan trọng về thương mại chứ không chỉ kỹ thuật. PPN 014, có hiệu lực từ ngày 24 tháng 2 năm 2025 với các bộ trung ương, cơ quan trực thuộc, tổ chức công ngoài bộ và các đơn vị NHS, yêu cầu chứng nhận khi nhà cung cấp xử lý thông tin cá nhân của công dân, của công chức, hoặc hệ thống ICT xử lý dữ liệu ở mức OFFICIAL.

ISO/IEC 27001

ISO/IEC 27001 là tiêu chuẩn quốc tế cho hệ thống quản lý an toàn thông tin, do ISO và IEC ban hành. Bản hiện hành là ISO/IEC 27001:2022, với Sửa đổi 1 năm 2024 bổ sung nội dung về hành động khí hậu vào các điều khoản bối cảnh, theo một thay đổi áp dụng cho toàn bộ tiêu chuẩn hệ thống quản lý của ISO.

Đây là tiêu chuẩn hệ thống quản lý, và đó chính là chỗ bên mua đọc sai. Nó không quy định một bộ kiểm soát cố định mà mọi tổ chức được chứng nhận đều đã triển khai. Nó yêu cầu tổ chức xác định phạm vi, đánh giá rủi ro, chọn kiểm soát, và chạy một chu trình rà soát và cải tiến có tài liệu. Chứng nhận do tổ chức chứng nhận được công nhận cấp sau khi kiểm toán, không phải do chính ISO cấp.

Vậy câu hỏi hữu ích không bao giờ là nhà cung cấp có nó hay không, mà là tuyên bố phạm vi trên chứng chỉ bao phủ những gì. Một phạm vi giới hạn ở chức năng trụ sở chẳng nói gì về đội đang giữ mã nguồn và thông tin đăng nhập môi trường sản xuất của bạn. Hãy xin chứng chỉ và đọc phần phạm vi.

SOC 2

SOC 2 là của Mỹ và khác về bản chất. AICPA định nghĩa nó là “một báo cáo về các kiểm soát tại một tổ chức dịch vụ liên quan tới bảo mật, khả dụng, tính toàn vẹn xử lý, tính bảo mật hoặc quyền riêng tư”, thực hiện theo tiêu chí dịch vụ tin cậy của họ. Đó là báo cáo chứng thực do một hãng kiểm toán lập, không phải chứng chỉ, và không có điểm đạt hay logo để trưng.

Khác biệt đáng kể là loại báo cáo. Báo cáo Type 1 mô tả các kiểm soát và đánh giá chúng có được thiết kế phù hợp tại một thời điểm hay không. Báo cáo Type 2 kiểm tra chúng có vận hành hiệu quả suốt một giai đoạn hay không, thường là sáu hoặc mười hai tháng. Type 1 là một tấm ảnh, Type 2 là một cuốn phim, và bên mua chấp nhận Type 1 như tương đương đang nhận ít hơn nhiều so với họ nghĩ.

Hãy đọc báo cáo, đừng đọc trang bìa. Mục ngoại lệ, nơi kiểm toán viên ghi lại các kiểm soát không vận hành đúng như mô tả, mới mang thông tin, và đó là phần nhà cung cấp mong bạn bỏ qua.

Điều không chứng nhận nào chứng minh được

Không cái nào trong ba cái chứng nhận rằng phần mềm của bạn an toàn. Cyber Essentials bao phủ mức nền về vệ sinh hạ tầng. ISO 27001 bao phủ việc tổ chức có quản lý an toàn như một quy trình hay không. SOC 2 bao phủ việc các kiểm soát đã tuyên bố có vận hành trong một giai đoạn hay không. Cả ba đều nói về nhà cung cấp, không phải sản phẩm.

An toàn ứng dụng là một ngành riêng với bằng chứng riêng. Hãy hỏi báo cáo kiểm thử xâm nhập gần nhất và tình trạng khắc phục thay vì bức tường logo, rồi xem ai làm và trên phạm vi nào. Đó là thực chất phía sau dịch vụ kiểm thử xâm nhập của chúng tôi.

Mức phơi nhiễm quy định theo ngành

Quy định là chỗ lời khuyên doanh nghiệp chung chung trở nên không an toàn. Phần sau chỉ nêu các nghĩa vụ kiểm chứng được và dừng trước tư vấn pháp lý, thứ bạn nên lấy từ một cố vấn có chuyên môn.

UK GDPR, áp dụng cho gần như tất cả

Nếu hệ thống chạm tới dữ liệu cá nhân, Điều 32 của UK GDPR áp dụng cho cả bên kiểm soát lẫn bên xử lý. Nó đòi các biện pháp kỹ thuật và tổ chức phù hợp, và nêu tên bốn biện pháp: giả danh hoá và mã hoá; bảo mật, toàn vẹn, khả dụng và khả năng chống chịu liên tục của hệ thống xử lý; khả năng khôi phục kịp thời khả dụng và quyền truy cập dữ liệu cá nhân sau sự cố; và một quy trình kiểm tra, đánh giá định kỳ hiệu quả của các biện pháp đó.

Hãy đọc lại biện pháp thứ ba, vì nó biến khôi phục thảm hoạ thành nghĩa vụ bảo vệ dữ liệu chứ không phải một sở thích vận hành. Hướng dẫn của ICO về an toàn dữ liệu chỉ tới Cyber Essentials như một mức nền hữu ích, đồng thời nói thẳng rằng đó chỉ là bộ kiểm soát cơ bản và sẽ không xử lý mọi hoàn cảnh của mọi tổ chức hay mọi rủi ro của mọi hoạt động xử lý.

Tài chính và y tế, ngắn gọn và thận trọng

Trong dịch vụ tài chính, cơ chế khả năng chống chịu vận hành của FCA buộc các công ty thuộc phạm vi phải xác định dịch vụ nghiệp vụ quan trọng, đặt ngưỡng chịu đựng tác động cho chúng, và giữ được trong ngưỡng đó khi gián đoạn nghiêm trọng nhưng có thể xảy ra. Giai đoạn chuyển tiếp kết thúc ngày 31 tháng 3 năm 2025, nên nghĩa vụ này đang có hiệu lực và định hình những gì nhà cung cấp cho các công ty đó phải chứng minh.

Trong y tế và chăm sóc, một hệ thống CNTT y tế chạm tới các chuẩn quản lý rủi ro lâm sàng của NHS England: DCB0129 cho bên sản xuất và DCB0160 cho tổ chức triển khai. Cả hai đang được rà soát ở cấp quốc gia, với một đợt tham vấn công khai chạy từ ngày 29 tháng 6 năm 2026 đến ngày 11 tháng 9 năm 2026, nên hãy xác nhận trạng thái hiện tại trước khi dựa vào bất kỳ bản tóm tắt nào, kể cả bài này.

Nếu ngành của bạn không có tên ở đây, hãy xử lý nghĩa vụ theo cách tổng quát: xác định cơ quan quản lý, đọc yêu cầu do chính cơ quan đó công bố, và buộc nhà cung cấp chứng minh theo các yêu cầu ấy thay vì một câu chuyện bảo đảm chung chung.

Tiền đi vào kiến trúc tích hợp

Chi phí doanh nghiệp dồn vào các mối nối giữa các hệ thống, không phải bên trong chúng. Tính năng thường đã rõ. Chỗ tiến độ biến mất là làm cho sáu hệ thống có mô hình dữ liệu khác nhau và cách hiểu về khách hàng khác nhau đồng thuận với nhau.

Điểm nối điểm hay một broker

Điểm nối điểm là mặc định vì tích hợp đầu tiên thật sự đơn giản hơn khi làm vậy. Cái giá mang tính tổ hợp: với n hệ thống nói chuyện trực tiếp, số kết nối tiến tới n bình phương, mỗi kết nối có logic thử lại, thông tin đăng nhập và giám sát riêng. Ở bốn hệ thống thì ổn. Ở mười lăm thì không bảo trì nổi.

Một broker hay bus sự kiện đảo ngược đường cong đó. Nó thêm một thành phần, một gánh nặng vận hành và một điểm hỏng đơn lẻ phải thiết kế để né, và nó hoàn vốn quanh bên tham gia thứ sáu hoặc thứ tám. Sai lầm xảy ra theo cả hai chiều: hệ nhỏ mua nền tảng tích hợp không cần, hệ lớn trì hoãn đến khi mạng lưới đã vôi hoá.

Đồng bộ hay hướng sự kiện

Lời gọi đồng bộ dễ suy luận và ghép cứng khả dụng. Nếu dịch vụ của bạn gọi bốn hệ thống nội tuyến và mỗi hệ thống chạy 99,9% thời gian, trần của chính bạn khoảng 99,6% trước khi bạn viết ra một lỗi nào. Mỗi phụ thuộc đồng bộ là một phần khả dụng của bạn giao cho đội vận hành của người khác.

Thiết kế hướng sự kiện gỡ chỗ ghép đó ra, đổi lại là nhất quán cuối cùng và gỡ lỗi khó hơn nhiều. Hãy giữ lời gọi đồng bộ cho đường đi mà người dùng đang chờ và câu trả lời cũ là không chấp nhận được, còn lại chuyển hết sang sự kiện. Hãy quyết theo từng tương tác chứ không phải như một quy ước chung.

Tính lũy đẳng, phát lại và đối soát

Hệ phân tán gửi thông điệp nhiều hơn một lần và thỉnh thoảng làm mất, nên mọi đường ghi vượt qua ranh giới đều phải an toàn khi lặp lại. Cách làm đã được thiết lập là khoá lũy đẳng do máy khách sinh ra. Cách Stripe triển khai lưu mã trạng thái và nội dung của yêu cầu đầu tiên cho một khoá, trả về cùng kết quả khi thử lại, dọn khoá sau ít nhất 24 giờ, và báo lỗi nếu cùng khoá đó tới với tham số khác.

Phát lại là nửa vận hành của cùng ý tưởng. Sau khi một hệ thống hạ nguồn ngừng hoạt động sáu giờ, ai đó phải đẩy các thông điệp bị bỏ lỡ qua, và việc đó chỉ an toàn nếu bên tiêu thụ có tính lũy đẳng và thông điệp đã được giữ lại. Hãy thiết kế cửa sổ lưu giữ và cơ chế phát lại song song với luồng chính, vì gắn thêm về sau nghĩa là sửa mọi bên tiêu thụ.

Đối soát hay bị coi là việc phụ và không nên thế. Đó là một tác vụ theo lịch so sánh trạng thái của hai hệ thống lẽ ra phải khớp nhau, báo cáo khác biệt rồi hoặc tự sửa hoặc chuyển cho người xử lý. Không có nó, một sai lệch âm thầm so với hệ thống tài chính sẽ do kiểm toán viên tìm ra vài tháng sau. Hãy đưa nó vào ngân sách như một sản phẩm bàn giao hạng nhất có người phụ trách và có kênh cảnh báo, không phải một script ai đó viết vào phút cuối.

Sống chung với hệ thống cũ và mẫu Strangler Fig

Thay thế toàn bộ một hệ thống đang chạy là lựa chọn rủi ro nhất hiện có, và nó được chọn nhiều hơn mức đáng lẽ. Cách thay thế tăng dần được Microsoft ghi lại là mẫu Strangler Fig: đặt một facade trước hệ thống cũ, định tuyến yêu cầu qua nó, và chuyển từng phần chức năng sang cho tới khi hệ thống cũ không còn lưu lượng và có thể tắt.

Mỗi phần tăng dần đều có giá trị độc lập và đảo ngược được độc lập: nếu lát thứ ba hỏng, bạn định tuyến nó trở lại. Microsoft nói rõ chỗ nó không áp dụng, tức là khi không chặn được yêu cầu tới backend, khi không sửa được mã nguồn cũ, hoặc khi hệ thống nhỏ tới mức thay hẳn thì dễ hơn.

Hai chi tiết quyết định nó có chạy hay không. Facade không được thành nút thắt hay điểm hỏng đơn lẻ, nên nó cần đúng mức kỹ thuật khả dụng như các dịch vụ phía sau. Và các lời gọi liên hệ thống trong giai đoạn chuyển tiếp cần một lớp chống hư hỏng, để ngữ nghĩa cũ không rò sang thiết kế mới. Dữ liệu khó hơn lưu lượng: chuyển bảng của một miền ra ngoài nghĩa là một lần nạp ban đầu, một luồng bắt biến đổi dữ liệu, một giai đoạn kiểm chứng ghi vào cả hai kho rồi so sánh, và chỉ sau đó mới chuyển đổi, với khả năng quay lui cho tới khi các đối tượng cũ bị xoá.

Kiểm thử ở quy mô doanh nghiệp

Kiểm thử trong một chương trình doanh nghiệp là bài toán hậu cần không kém bài toán kỹ thuật, và là nơi các kế hoạch lạc quan chết.

Các môi trường

Bạn sẽ cần nhiều hơn mức đã dự trù: môi trường phát triển, một môi trường tích hợp nối vào sandbox của đối tác, một môi trường hiệu năng đủ gần sản xuất để các con số có nghĩa, một môi trường nghiệm thu đủ ổn định cho những người phi kỹ thuật đang bận, và môi trường sản xuất. Mỗi cái có chi phí hạ tầng, quy trình làm mới và người phụ trách. Cái luôn bị cắt là môi trường hiệu năng, và bỏ nó nghĩa là kiểm thử tải trên sản xuất.

Dữ liệu kiểm thử và bài toán dữ liệu cá nhân

Hệ thống doanh nghiệp cần dữ liệu thực tế để kiểm thử, và dữ liệu thực tế chính là dữ liệu sản xuất, thứ chứa thông tin cá nhân. Sao chép nó sang môi trường kiểm thử là hoạt động xử lý theo UK GDPR, và các nghĩa vụ theo Điều 32 đi theo nó sang đó, gồm cả kiểm soát truy cập lẫn an toàn của môi trường đang chứa nó.

Hai câu trả lời bảo vệ được là ẩn danh hoá, thứ phải không thể đảo ngược mới đưa dữ liệu ra ngoài phạm vi quy định, và giả danh hoá, thứ giảm rủi ro nhưng vẫn nằm trong phạm vi. Cả hai đều cần công sức kỹ thuật để giữ hình dạng thống kê khiến dữ liệu còn hữu dụng, và cần một quy trình có tài liệu. Khôi phục cơ sở dữ liệu sản xuất vào một môi trường kiểm thử dùng chung là chuyện phổ biến, phi pháp trong nhiều cấu hình, và đúng là thứ mà một cuộc đánh giá nhà cung cấp được thiết kế để lộ ra.

Kiểm thử hiệu năng

Kiểm thử hiệu năng trả lời câu hỏi hệ thống có đạt các con số thông lượng và độ trễ đã chốt trước đó hay không, nên nó chỉ tồn tại được nếu những con số ấy đã được viết ra. Hãy kiểm thử hồ sơ đỉnh thay vì trung bình, và tính cả hình dạng của đỉnh, vì tăng dần trong mười phút và nhảy bậc trong một giây kích hoạt các kiểu hỏng khác nhau.

Hãy chạy nó trên khối lượng dữ liệu cỡ sản xuất. Một truy vấn tức thì trên 10.000 hàng và không dùng nổi trên 40 triệu hàng là lỗi hiệu năng phổ biến nhất trong phần mềm doanh nghiệp, và nó vô hình trên tập dữ liệu nhỏ.

Kiểm thử chấp nhận với những người còn việc khác

Kiểm thử chấp nhận người dùng được xếp thành một cửa sổ hai tuần và là giai đoạn vượt hạn đáng tin cậy nhất, vì người kiểm thử chính là chuyên gia nghiệp vụ và nghiệp vụ vẫn cần họ. Họ sẽ cho bạn vài giờ mỗi tuần, và quỹ thời gian của họ sụp xuống vào cuối tháng.

Hãy nêu tên người kiểm thử trong hợp đồng, chốt số giờ mỗi tuần, viết kịch bản tình huống trước thay vì bảo người ta tự mò, và chạy phân loại lỗi như một buổi làm việc chung chứ không phải một hàng đợi ticket. Nhà cung cấp báo hai tuần nghiệm thu mà không có người tham gia đích danh thì chưa từng chạy một đợt nào.

Mô hình bàn giao và quản trị

Hình dạng đội hiệu quả là nhỏ và ổn định chứ không lớn và luân chuyển: một trưởng nhóm kỹ thuật sở hữu kiến trúc cho cả chương trình, ba đến sáu kỹ sư, một trưởng nhóm bàn giao lo lịch với đối tác, cùng quyền dùng chung một kỹ sư chất lượng và một chuyên gia hạ tầng. Thêm người giữa chừng làm chương trình chậm lại một cách đáng tin cậy, vì ràng buộc là ngữ cảnh chứ không phải số tay.

Hãy viết ra quyền quyết định trước sprint đầu tiên. Nêu tên một người duyệt thay đổi phạm vi, một người duyệt đánh đổi kiến trúc, và một người nghiệm thu bản phát hành. Nếu đó là ba cái tên, quyết định mất vài ngày. Nếu là ba hội đồng, quyết định mất vài tuần và kế hoạch chỉ là hư cấu.

Nhịp họp điều hành giữ cho một chương trình dài trung thực: rà soát bàn giao hai tuần một lần với nhóm làm việc, họp điều hành hằng tháng với người giữ ngân sách và người có quyền phủ quyết trong cùng một phòng, và báo cáo trạng thái bằng văn bản so với đường cơ sở gốc chứ không phải bản sửa của tháng trước. Nhà cung cấp có trạng thái xanh vĩnh viễn không quản trị rủi ro, họ đang giấu nó.

Mô hình thương mại và ai gánh rủi ro

Bốn mô hình bao gần hết, mỗi mô hình đặt rủi ro một chỗ khác. Câu hỏi không phải cái nào tốt nhất, mà bên nào hợp hơn để gánh phần bất định trước mặt.

Tính công và vật tư hợp với việc thật sự bất định: khảo sát, khảo cổ hệ thống cũ, hay tích hợp với đối tác tài liệu kém. Bên mua gánh rủi ro và được toàn quyền linh hoạt, đổi lại cần lòng tin và một tốc độ tiêu ngân sách được theo dõi.

Tính công có trần thêm mức giới hạn và thường là dung hoà hợp lý, cũng là cách chúng tôi tổ chức phần lớn dịch vụ phát triển phần mềm. Nhà cung cấp hấp thụ phần vượt trần, bên mua chỉ trả phần đã dùng, cả hai giữ phạm vi trung thực. Mức trần nên có dự phòng 15% đến 25%, vì bên chốt trần đúng bằng chi phí kỳ vọng thì hoặc nhầm hoặc đang tính một yêu cầu thay đổi.

Giá cố định chỉ chạy được khi phạm vi thật sự cố định, mà trong chương trình doanh nghiệp điều đó đúng với một phần tăng dần, không phải toàn bộ. Các phần giá cố định dài sáu đến mười tuần, mỗi phần chốt phạm vi sau khi phần trước hạ cánh, cho bạn chắc chắn về ngân sách mà không phải giả vờ ai đó đặc tả nổi mười tám tháng từ đầu.

Dịch vụ vận hành là hình dạng đúng khi hệ thống đã sống: phí hằng tháng gồm hỗ trợ, vá lỗi, giám sát và một hạn mức thay đổi xác định, tính theo phần trăm chi phí xây dựng mỗi năm chứ không theo đầu người. Bản mô tả dịch vụ phải nêu rõ thời gian phản hồi và đường leo thang.

Dịch vụ phát triển phần mềm doanh nghiệp: điều gì đẩy chi phí

Các yếu tố chi phí xếp theo mức ảnh hưởng

Thứ tự này làm người ta ngạc nhiên, vì tính năng đứng cuối. Đầu tiên là bề mặt tích hợp, cụ thể là số chủ sở hữu bên ngoài chứ không phải số endpoint. Thứ hai là các mục tiêu phi chức năng, vì bước từ một dịch vụ có thể nhận cửa sổ bảo trì sang một dịch vụ không thể sẽ đổi mọi tầng của thiết kế.

Thứ ba là gánh nặng bảo đảm và quy định: thời gian dự thầu, sản xuất bằng chứng, hỗ trợ kiểm toán, và một quy trình phát hành chậm hơn suốt vòng đời hợp đồng. Thứ tư là di trú dữ liệu và đối soát, luôn bị ước lượng thiếu vì cái khó nằm ở chất lượng dữ liệu cũ chứ không ở khối lượng. Thứ năm là số nhóm liên quan, thứ ấn định độ trễ ra quyết định. Thứ sáu là số môi trường. Phạm vi tính năng đứng thứ bảy, và nó thường là thứ duy nhất có trong ngân sách gốc.

Khoảng giá tham khảo tại Anh

Các khoảng dưới đây là ước lượng nội bộ từ các hợp đồng tại Anh, thể hiện dưới dạng chi phí năm đầu gồm khảo sát, xây dựng, kiểm thử và lên sóng, nhưng không gồm thời gian nhân sự của bên mua. Chúng mang tính tham khảo chứ không phải báo giá, và khoảng rộng vì các yếu tố nói trên làm chúng dịch chuyển.

Nói không cần bảng: một dịch vụ đơn với hai hoặc ba tích hợp, người dùng nội bộ và mục tiêu 99,5% rơi vào khoảng GBP 120.000 đến GBP 250.000 trong năm đầu. Một hệ thống cấp phòng ban hướng khách hàng với năm đến tám tích hợp ở 99,9% là GBP 300.000 đến GBP 700.000. Một nền tảng lõi thay hệ thống cũ, với mười đến hai mươi tích hợp và mục tiêu 99,95%, là GBP 900.000 đến GBP 2,5 triệu. Một chương trình chịu quản lý đa pháp nhân ở 99,99% khởi điểm quanh GBP 2,5 triệu và đi lên.

Chi phí vận hành không có trong ngân sách

Hãy cộng thêm chi phí vận hành hằng năm, khoản này rơi vào 15% đến 25% chi phí xây dựng mỗi năm khi đã tính hỗ trợ, hosting, vá lỗi, việc bảo mật và một hạn mức thay đổi vừa phải. Ngân sách cấp tiền cho xây dựng mà không cấp cho vận hành tạo ra một hệ thống xuống cấp thấy rõ trong năm thứ hai, và phần phân tích của chúng tôi về chi phí bảo trì phần mềm chỉ ra khoản tiền ấy đi đâu.

Rời đi và tính liên tục

Một nhà cung cấp bạn không rời được là rủi ro nằm trên bảng cân đối, và là điều khoản hay bị đẩy tới cuối cuộc đàm phán, lúc không ai còn để ý. Bốn thứ khiến việc rời đi khả thi.

Mã nguồn và lịch sử của nó thuộc về kho bên mua sở hữu hoặc tiếp nhận được khi báo trước, kèm pipeline build và định nghĩa hạ tầng. Mã không có pipeline build nó là kho lưu trữ, không phải tài sản đang chạy.

Tài liệu phải đủ để một bên thứ ba đủ năng lực vận hành hệ thống: kiến trúc, hợp đồng tích hợp, runbook cho các kiểu hỏng đã thật sự xảy ra, và danh mục thông tin đăng nhập. Bài của chúng tôi về tài liệu kỹ thuật thật sự được đọc nói về thứ sống sót qua bàn giao.

Ký gửi mã nguồn lo tình huống nhà cung cấp sụp đổ, không phải rời đi, bằng cách gửi mã cho bên thứ ba, giải phóng theo điều kiện đã định. Nó đáng có khi nhà cung cấp nhỏ so với giá trị hợp đồng, và đáng đọc kỹ, vì bản ký gửi không kiểm chứng sẽ giải phóng mã không build được. Chúng tôi đã xét khi nào nó chính đáng trong ký gửi mã nguồn, thật ra ai cần nó.

Cuối cùng, hãy định giá phần bàn giao trong hợp đồng. Số ngày chuyển giao tri thức đã nêu rõ, theo đơn giá đã thoả thuận và kích hoạt khi báo trước, biến một cuộc cãi vã thành một hoá đơn. Kỷ luật đó cũng áp dụng cho nhà cung cấp của nhà cung cấp, trong ghi chú của chúng tôi về an toàn chuỗi cung ứng phần mềm.

Đánh giá năng lực doanh nghiệp của nhà cung cấp trong một buổi họp

Năm câu hỏi làm rõ phần lớn chuyện này trong một giờ, và sự do dự nói lên nhiều như câu trả lời.

Hãy hỏi họ đã bàn giao theo những mục tiêu khả dụng và phục hồi nào, và khả dụng được đo ra sao. Nhà cung cấp từng gánh nghĩa vụ 99,95% sẽ tự nêu điểm đo và cơ chế trực mà không cần nhắc. Bên chưa từng gánh sẽ nói chung chung về dự phòng.

Hãy xin xem tuyên bố phạm vi trên chứng chỉ ISO 27001 của họ, hoặc mục ngoại lệ trong báo cáo SOC 2 Type 2. Cả hai là đề nghị bình thường với nhà cung cấp thật sự có chúng, và khó xử với bên chỉ có một cái logo. Rồi hỏi họ đã xử lý một sai lệch đối soát trên sản xuất ra sao, câu này không ai trả lời được bằng lý thuyết.

Hãy hỏi ba chương trình gần nhất của họ vượt bao nhiêu và vì sao. Ai cũng vượt, phần có thông tin là họ có biết con số đó hay không. Rồi hỏi quy trình rời đi của họ trông ra sao, tính bằng ngày và bằng sản phẩm bàn giao. Nhà cung cấp đã viết ra điều đó là bên chờ được đánh giá theo nó.

Điều này để lại gì cho bên mua

Từ doanh nghiệp nên mô tả nghĩa vụ chứ không phải một khung giá. Khi bề mặt tích hợp, các mục tiêu khả dụng và phục hồi, mức phơi nhiễm quy định và điều khoản rời đi đã được viết ra, danh sách rút gọn tự sắp xếp, vì phần lớn nhà cung cấp không chứng minh được theo bốn điểm ấy.

Mecanik làm việc với hình dạng hợp đồng này qua dịch vụ phát triển phần mềm của chúng tôi, còn phía bảo đảm thì qua dịch vụ kiểm thử xâm nhập. Nếu bạn đang lắp ráp yêu cầu chứ chưa lắp danh sách rút gọn, checklist thẩm định kỹ thuật là điểm khởi đầu hợp lý, và các con số phi chức năng đáng được tranh luận trước tiên.

Câu hỏi thường gặp

Thế nào là phát triển phần mềm doanh nghiệp? Doanh nghiệp được định nghĩa bằng ràng buộc chứ không bằng quy mô bên mua. Một dự án đủ tiêu chuẩn khi nó có bề mặt tích hợp rộng do nhiều bên sở hữu, nghĩa vụ hợp đồng về khả dụng và phục hồi, phơi nhiễm quy định, nhiều nhóm liên quan đều chặn được một lần phát hành, khối lượng dữ liệu phá vỡ thiết kế ngây thơ, và yêu cầu sống chung với hệ thống cũ mà không ai hiểu trọn vẹn. Một công ty lớn có thể đặt một dự án bình thường, còn một công ty nhỏ chịu quản lý có thể đặt một dự án doanh nghiệp đúng nghĩa.

Một chương trình phát triển phần mềm doanh nghiệp tại Anh tốn bao nhiêu? Theo ước lượng nội bộ từ các hợp đồng tại Anh, một dịch vụ đơn với hai hoặc ba tích hợp và mục tiêu khả dụng 99,5% là GBP 120.000 đến GBP 250.000 trong năm đầu. Một hệ thống cấp phòng ban hướng khách hàng ở 99,9% là GBP 300.000 đến GBP 700.000. Một nền tảng lõi thay hệ thống cũ là GBP 900.000 đến GBP 2,5 triệu. Hãy cộng thêm 15% đến 25% chi phí xây dựng mỗi năm cho vận hành và hỗ trợ.

Nhà cung cấp doanh nghiệp có cần ISO 27001, Cyber Essentials hay SOC 2? Chúng chứng minh những điều khác nhau. Cyber Essentials là mức nền do chính phủ Anh hậu thuẫn gồm năm kiểm soát kỹ thuật, có bậc Plus được kiểm toán kỹ thuật độc lập xác minh và được PPN 014 yêu cầu cho nhiều hợp đồng khu vực công. ISO/IEC 27001:2022 chứng nhận một hệ thống quản lý an toàn thông tin, nên tuyên bố phạm vi trên chứng chỉ quan trọng hơn bản thân chứng chỉ. SOC 2 là báo cáo chứng thực của Mỹ do một hãng kiểm toán lập, và chỉ Type 2 mới kiểm tra các kiểm soát có vận hành suốt một giai đoạn hay không.

Mục tiêu điểm phục hồi và mục tiêu thời gian phục hồi là gì? Mục tiêu điểm phục hồi (RPO) là bạn chấp nhận mất bao nhiêu dữ liệu sau thảm hoạ, nên RPO một giờ nghĩa là tối đa một giờ giao dịch có thể biến mất. Mục tiêu thời gian phục hồi (RTO) là bạn chấp nhận ngừng phục vụ bao lâu, nên RTO bốn giờ nghĩa là dịch vụ phải phục vụ lưu lượng trở lại trong vòng bốn giờ. Cả hai đẩy kiến trúc và chi phí hơn mọi tính năng, vì chúng chọn giữa sao lưu và khôi phục, pilot light, warm standby và đa vùng active/active.

Hợp đồng phần mềm doanh nghiệp cần viết gì về việc rời đi? Bốn thứ. Quyền sở hữu hoặc quyền truy cập chuyển giao được với kho mã nguồn, pipeline build và các định nghĩa hạ tầng. Tài liệu đủ để một bên thứ ba đủ năng lực vận hành hệ thống, gồm runbook và danh mục thông tin đăng nhập. Ký gửi mã nguồn khi nhà cung cấp nhỏ so với giá trị hợp đồng, và là bản ký gửi đã được kiểm chứng chứ không phải chưa kiểm chứng. Và một điều khoản bàn giao đã định giá, nêu số ngày chuyển giao tri thức cùng đơn giá, để việc rời đi là một hoá đơn chứ không phải một tranh chấp.