Kỹ nghệ phần mềm và nền tảng khu vực công

Vì sao điều này quan trọng đối với giá trị công

Gần như mọi dịch vụ công mà một công dân chạm đến ngày nay — đăng ký khai sinh, yêu cầu trợ cấp, nộp hóa đơn thuế, đặt lịch ra tòa — đều chạy trên phần mềm ở đâu đó đằng sau quầy hay màn hình. Phần mềm đó hiếm khi là một lần mua; nó trở thành một phần của hạ tầng thường trực của nhà nước, thường sống lâu hơn chính quyền đã đặt hàng nó, nhà cung cấp đã xây nó, và ngôn ngữ lập trình mà các kỹ sư của nó được đào tạo. Một cơ quan công không trải nghiệm phần mềm theo cách nó trải nghiệm một tòa nhà hay một con đường, nơi tình trạng của tài sản hiển thị; phần mềm xuống cấp một cách vô hình, và hóa đơn cho sự phân rã đó đến nhiều năm sau như một cuộc khẩn cấp.

Căng thẳng thúc đẩy chủ đề này mang tính cấu trúc. Phần mềm vốn lặp lại — yêu cầu trở nên rõ hơn khi người dùng tương tác với một hệ thống đang chạy, và thực hành kỹ nghệ tốt nhất là xây một thứ nhỏ, học và thích ứng. Chu kỳ mua sắm và trách nhiệm giải trình công (xem Chủ đề 3.7 — Mua sắm công và đặt hàng dịch vụ), ngược lại, được xây cho công trình vốn và hợp đồng quốc phòng: một đặc tả cố định, một lần trao thầu lớn duy nhất, các khoản thanh toán theo cột mốc, và một luận chứng kinh tế được ký duyệt nhiều năm trước khi việc cung cấp bắt đầu. Khi một cơ quan lập pháp hay kiểm toán viên kỳ vọng một hợp đồng giá cố định, phạm vi cố định và một nhóm kỹ nghệ cần đổi hướng sau lần phát hành đầu tiên, sự lệch hiện ra như phạm vi phình to, ngân sách vượt, hay một hệ thống được đặc tả đúng năm 2019 và lỗi thời khi nó ra mắt.

Các nền tảng mà thực hành kỹ nghệ của chủ đề này tồn tại để xây — hệ thống danh tính dùng chung, đường thanh toán, công cụ quản lý hồ sơ tái sử dụng qua các cơ quan — là đề tài của Chủ đề 5.1 (xem Chủ đề 5.1 — Chính phủ số và chuyển đổi số); chủ đề này nói về kỷ luật xây và mua phần mềm làm cho bất kỳ nền tảng nào như vậy, hay bất kỳ dịch vụ đơn lẻ nào, đáng tin cậy, thay thế được, và thuộc sở hữu của cơ quan công phụ thuộc vào nó thay vì của bất kỳ nhà cung cấp nào tình cờ viết nó trước.

Khái niệm cốt lõi

Quyết định xây hay mua là sự lựa chọn giữa đặt hàng phần mềm đặt riêng viết cho nhu cầu của một tổ chức và áp dụng phần mềm hàng hóa có thể cấu hình đã được xây cho một thị trường các bên mua tương tự. Mua thường rẻ hơn và ít rủi ro hơn cho một nhu cầu không thực sự đặc thù — bảng lương, email, quản lý hồ sơ chuẩn — trong khi xây chỉ được biện minh nơi yêu cầu đủ khác để không sản phẩm cấu hình được nào khớp, hoặc nơi năng lực tự nó là một tài sản chiến lược mà tổ chức cần sở hữu và phát triển.

Nợ kỹ thuật là một ẩn dụ, do kỹ sư phần mềm Ward Cunningham đặt ra năm 1992, cho chi phí tích lũy của việc chọn một cách thuận tiện để phát hành phần mềm bây giờ thay vì một cách kỹ lưỡng hơn lẽ ra tốn nhiều thời gian hơn. Nợ kỹ thuật, như nợ tài chính, không sai tự thân khi gánh — chính quan điểm của Cunningham là phát hành mã hoạt động nhanh rồi tái cấu trúc sau có thể là lựa chọn đúng — nhưng nợ không bao giờ được trả sinh lãi dưới dạng cung cấp chậm hơn, nhiều lỗi hơn và rủi ro tăng, và một cơ quan công không thấy được nợ của mình không thể quyết định nên trả nó hay để nó cộng dồn.

Hệ thống di sản là một công nghệ, ứng dụng hay nền tảng cũ vẫn đang được dùng dù đã lỗi thời, thường vì việc thay thế đắt hoặc vì không ai còn lại trong tổ chức hiểu đầy đủ nó làm gì. Các hệ thống di sản đặc biệt dai dẳng trong chính phủ: các hệ thống thuế, trợ cấp và bảo hiểm xã hội cốt lõi viết từ nhiều thập kỷ trước bằng các ngôn ngữ như COBOL — Ngôn ngữ Hướng Kinh doanh Chung, thiết kế năm 1960 cho tính toán hành chính — vẫn xử lý giao dịch cho hàng triệu công dân, vì các hệ thống hoạt động và tri thức thể chế cần để cho chúng nghỉ hưu an toàn thường đã nghỉ hưu trước.

Hiện đại hóa phần mềm là thuật ngữ chung cho việc chuyển đổi, viết lại hay di chuyển một hệ thống di sản sang một kiến trúc, ngôn ngữ hay nền tảng hiện tại. Hiện đại hóa phần mềm trải từ viết lại hoàn toàn đến các phương án thận trọng hơn như lưu trữ lại cùng mã trên hạ tầng hiện đại, và sự lựa chọn giữa chúng là quyết định quản lý rủi ro cũng nhiều như kỹ thuật.

Khuôn mẫu cây sung bóp cổ là một cách tiếp cận hiện đại hóa gia tăng, đặt tên theo một loại dây leo mọc quanh cây chủ và dần thay thế nó, trong đó chức năng mới được xây cạnh một hệ thống di sản và lưu lượng được chuyển hướng sang nó từng mảnh một, thay vì thay cả hệ thống trong một lần chuyển đổi. Khuôn mẫu cây sung bóp cổ quan trọng vì nó cho phép mỗi bước gia tăng được kiểm nghiệm, đảo ngược hay tạm dừng mà không hạ cả dịch vụ — ngược với một sự thay thế bùng nổ, nơi hệ thống cũ bị tắt và hệ thống mới được bật trong một khoảnh khắc duy nhất mà không có đường quay lại nếu có gì sai.

Khóa chặt nhà cung cấp xảy ra khi một khách hàng trở nên phụ thuộc vào công nghệ độc quyền, định dạng dữ liệu hay điều khoản hợp đồng của một nhà cung cấp đến mức việc chuyển sang nhà cung cấp khác mang chi phí hay rủi ro cấm đoán. Khóa chặt nhà cung cấp là một mối nguy đặc biệt trong phần mềm khu vực công vì người mua là khách hàng lặp lại với khả năng thực tế hạn chế để bỏ đi khỏi một hệ thống chạy một dịch vụ trọng yếu, làm yếu vị thế đàm phán của nó ở mọi lần gia hạn sau.

Phần mềm tự do và nguồn mở là phần mềm được phân phối theo một giấy phép trao cho người dùng tự do sử dụng, nghiên cứu, sửa đổi và phân phối lại mã nguồn. Phần mềm tự do và nguồn mở làm nền tảng cho một chính sách mặc định nguồn mở, theo đó một cơ quan công mặc định công bố mã nguồn mà nó đặt hàng trừ khi một lý do cụ thể — nhạy cảm an ninh, quyền của bên thứ ba — biện minh cho việc giữ lại; lý do thường được tóm tắt là "tiền công, mã công": phần mềm được trả một lần bằng tiền công không cần được trả lại, ở một khu vực pháp lý khác, bởi một cơ quan công khác giải quyết cùng vấn đề.

Hàng hóa công số là phần mềm, dữ liệu hay nội dung mở, được phát hành dưới một giấy phép mở, được thiết kế để giúp đáp ứng một mục tiêu phát triển hay quản trị công thay vì tạo ra lợi nhuận thương mại. Hàng hóa công số đóng khung lại việc phát hành nguồn mở của một chính phủ như một phần của hạ tầng dùng chung rộng hơn mà các chính phủ và tổ chức xã hội dân sự khác có thể tận dụng trực tiếp, không chỉ một cử chỉ minh bạch nội bộ.

Phát triển phần mềm linh hoạt là thuật ngữ bao trùm cho các cách tiếp cận lặp để xây phần mềm ưu tiên phần mềm hoạt động, cung cấp thường xuyên, và ứng phó với thay đổi hơn là theo một kế hoạch cố định thỏa thuận trước. Phát triển phần mềm linh hoạt đối lập với mô hình thác nước, một cách tiếp cận tuần tự trong đó yêu cầu, thiết kế, xây dựng và kiểm thử mỗi cái hoàn thành đầy đủ trước khi cái tiếp theo bắt đầu; sức hấp dẫn của mô hình thác nước với các cơ quan công luôn là các cột mốc của nó ánh xạ gọn vào một hợp đồng giá cố định và chu kỳ ngân sách hằng năm, đó là lý do rất nhiều luật mua sắm vẫn giả định nó, ngay cả khi việc cung cấp thực sự linh hoạt.

Một sản phẩm khả thi tối thiểu là phiên bản nhỏ nhất của một dịch vụ có thể được phát hành cho người dùng thực để kiểm nghiệm xem nó có hoạt động không và học cần xây gì tiếp theo. Khái niệm sản phẩm khả thi tối thiểu, được điều chỉnh thành các sách hướng dẫn dịch vụ số của khu vực công, cho một nhóm lặp một cách bảo vệ được để cho một nhà tài trợ hay kiểm toán viên thấy một thứ thực, hoạt động từ rất lâu trước khi phạm vi đầy đủ hoàn thành — miễn là quy trình trách nhiệm giải trình chấp nhận một bản phát hành thực sự tối thiểu thay vì coi nó là sản phẩm hoàn thiện dưới tên khác.

Thực hành tốt nhất

1. Mặc định mua cho các nhu cầu không đặc thù, và dành xây cho điều thực sự đặc thù. Bảng lương, email và nhu cầu quản lý hồ sơ chung hiếm khi đủ khác bất kỳ tổ chức nào khác để biện minh phần mềm đặt riêng; chỉ xây nơi yêu cầu, quy mô hay nhu cầu sở hữu và phát triển năng lực qua nhiều thập kỷ thực sự khác với điều thị trường đề nghị.
2. Làm cho nợ kỹ thuật hiển thị trước khi quyết định gánh bao nhiêu. Duy trì một sổ đăng ký các lối tắt đã biết, sửa chữa bị hoãn và phụ thuộc không được hỗ trợ cho mọi hệ thống đang chạy, được xem xét theo chu kỳ cố định, để gánh nợ thêm một năm là một đánh đổi có chủ ý thay vì không ai nhìn.
3. Không bao giờ lên kế hoạch một lần chuyển đổi duy nhất, không thể đảo ngược làm con đường duy nhất rời khỏi một hệ thống di sản trọng yếu. Ưu tiên các cách tiếp cận gia tăng như khuôn mẫu cây sung bóp cổ cho phép mỗi mảnh được kiểm nghiệm, đảo ngược và triển khai dần; một sự thay thế bùng nổ của một hệ thống mà hàng triệu người phụ thuộc tập trung nhiều năm rủi ro vào một cuối tuần duy nhất không có đường quay lại nếu có gì thất bại.
4. Coi mã nguồn tổ chức của bạn trả tiền để viết là một tài sản nó sở hữu, không phải một dịch vụ nó thuê. Thương lượng ký quỹ mã nguồn hoặc quyền sở hữu hoàn toàn tại thời điểm ký hợp đồng, không phải sau khi một tranh chấp đã bắt đầu, vì một nhà cung cấp nắm bản sao duy nhất của mã dịch vụ trọng yếu của bạn là khóa chặt nhà cung cấp theo thiết kế.
5. Công bố mã nguồn là mở theo mặc định, và yêu cầu một biện minh cụ thể để giữ lại. Một chính sách mặc định nguồn mở, áp dụng nhất quán, biến phần mềm đặt riêng của mỗi cơ quan thành một tài sản chung liên chính phủ thay vì một chi phí một lần, và cho các chuyên gia bên ngoài tìm ra lỗ hổng an ninh mà một nhóm nội bộ một mình sẽ bỏ lỡ.
6. Viết hợp đồng phần mềm làm cho việc cung cấp lặp là hợp pháp, không chỉ khả thi về mặt kỹ thuật. Một hợp đồng chỉ trả theo một đặc tả cố định thỏa thuận lúc ký buộc một nhóm chọn giữa thực hành linh hoạt trung thực và tuân thủ hợp đồng; hãy dùng các cổng tài trợ theo giai đoạn gắn với phần mềm hoạt động đã chứng minh thay vì một cột mốc ở cuối.
7. Tài trợ hiện đại hóa như một chương trình liên tục, không phải một dự án vốn một lần. Một hệ thống di sản được hiện đại hóa một lần rồi để lại hai mươi năm nữa tích lũy cùng rủi ro nó bắt đầu; hãy lập ngân sách cho sự đổi mới liên tục, gia tăng như một cơ quan đường bộ lập ngân sách cho lát lại mặt đường, không phải một sự thay thế lớn mỗi thế hệ.
8. Chọn chuẩn mở và định dạng dữ liệu di động ngay cả khi mua phần mềm thương mại. Yêu cầu hệ thống của nhà cung cấp lưu và xuất dữ liệu ở các định dạng mở, có tài liệu giữ chi phí chuyển đổi thấp ngay cả nơi bản thân phần mềm là độc quyền, và thường là biện pháp bảo vệ khả thi gần hạn hơn chống khóa chặt so với việc khăng khăng mọi hệ thống phải là nguồn mở.
9. Xây một sản phẩm khả thi tối thiểu và cho người dùng thực xem trước khi cam kết phạm vi đầy đủ. Phát hành một phiên bản thực sự tối thiểu, rồi lặp theo điều học được, bắt các giả định sai khi chúng còn rẻ để sửa, thay vì sau khi một hệ thống quy mô đầy đủ đã được xây đối chiếu với chúng.
10. Giữ năng lực kỹ nghệ nội bộ đủ để là một người mua thông minh, ngay cả nơi việc cung cấp được thuê ngoài. Một cơ quan công đã làm rỗng chuyên môn kỹ thuật không thể đánh giá đề xuất của nhà cung cấp, phát hiện các dấu hiệu cảnh báo sớm của một dự án gặp rắc rối, hay đàm phán thoát khỏi khóa chặt, bất kể quy tắc mua sắm của nó nói gì trên giấy.
11. Cho hồ sơ rủi ro của một hệ thống di sản nghỉ hưu trước giao diện người dùng của nó. Ưu tiên thay các ngôn ngữ không được hỗ trợ, hạ tầng chưa vá và tích hợp không có tài liệu — những thất bại gây ngừng hoạt động và rò rỉ — trước hiện đại hóa hình ảnh mang rủi ro vận hành thấp hơn nhiều.
12. Đo sức khỏe cung cấp bằng các chỉ số kỹ nghệ, không chỉ chênh lệch ngân sách và tiến độ. Tần suất triển khai, tỷ lệ lỗi và tuổi của mục nợ kỹ thuật chưa xử lý lâu nhất nói với một hội đồng quản trị nhiều hơn về việc một chương trình có thành công không so với việc nó hiện có đúng ngân sách không, thường là chỉ số cuối cùng dịch chuyển.

Câu hỏi thảo luận với đội ngũ của bạn

Chúng ta có thực sự biết mình đang gánh bao nhiêu nợ kỹ thuật, từng hệ thống một không? Hầu hết các cơ quan công có thể nêu ngân sách vốn của năm nhưng không thể nêu, với bất kỳ sự tự tin nào, bao nhiêu phần của hệ sinh thái phần mềm của họ chạy trên các thành phần không được hỗ trợ, logic không có tài liệu, hay mã mà không ai còn lại trong biên chế hiểu đầy đủ. Hãy dùng câu hỏi này để yêu cầu từng chủ hệ thống trong phòng ước tính, một cách trung thực, họ tự tin đến đâu rằng nhóm của họ có thể thay đổi hệ thống trọng yếu nhất một cách an toàn mà không làm hỏng điều gì không ai lường trước. Hãy thảo luận cần gì để biến các ước tính đó thành một sổ đăng ký thực sự, được xem xét theo chu kỳ cố định, thay vì tri thức truyền miệng rời đi khi một kỹ sư then chốt rời đi. Cũng hãy cân nhắc ai hiện quyết định mức nợ nào chấp nhận được để gánh, và quyết định đó là có chủ ý hay theo mặc định.

Nếu hệ thống di sản trọng yếu nhất của chúng ta cần được thay thế bắt đầu từ hôm nay, chúng ta sẽ lên kế hoạch một lần chuyển đổi bùng nổ hay một cuộc di chuyển gia tăng — và vì sao? Bản năng thay thế một hệ thống cũ cùng một lúc thường do chu kỳ ngân sách và sự tiện lợi quản lý chương trình thúc đẩy hơn là tất yếu kỹ thuật, và nó tập trung rủi ro khổng lồ vào một khoảnh khắc duy nhất. Hãy dùng câu hỏi này để đi qua, cụ thể, một cuộc di chuyển gia tăng kiểu cây sung bóp cổ của hệ thống di sản trọng yếu nhất của bạn thực sự trông ra sao, từng mảnh một. Hãy thảo luận điều gì đang ngăn bạn chọn con đường đó hôm nay — tài trợ xây quanh một ngày ra mắt duy nhất, một quy trình quản trị muốn một cột mốc gọn gàng, hay một ràng buộc kỹ thuật thực sự khiến di chuyển gia tăng bất khả với hệ thống này.

Ai thực sự sở hữu mã nguồn của phần mềm mà tổ chức chúng ta đã trả tiền để xây, và chúng ta có thể chứng minh không? Nhiều cơ quan công chỉ phát hiện, khi một quan hệ với nhà cung cấp trở nên chua chát, rằng hợp đồng chưa bao giờ bảo đảm quyền sở hữu hay ký quỹ rõ ràng đối với mã mà các dịch vụ trọng yếu của họ phụ thuộc vào. Hãy dùng câu hỏi này để lấy các hợp đồng của ba hệ thống đặt riêng quan trọng nhất của bạn và kiểm tra, cụ thể, mỗi hợp đồng nói gì về quyền sở hữu mã, ký quỹ và quyền mang mã sang nhà cung cấp khác. Hãy thảo luận điều gì sẽ xảy ra ngày mai nếu nhà cung cấp chính của bạn cho bất kỳ hệ thống nào trong ba hệ thống đó phá sản hay từ chối tiếp tục quan hệ.

Chúng ta đang mặc định theo phần mềm đóng, độc quyền vì thói quen ở đâu, khi một cách tiếp cận mặc định nguồn mở sẽ phục vụ chúng ta tốt như hoặc tốt hơn? Các chính sách mặc định nguồn mở tồn tại chính vì hầu hết các cơ quan công giải quyết các vấn đề chồng chéo một cách độc lập, mỗi cơ quan trả đầy đủ chi phí của phần mềm mà một cơ quan khác đã xây và lẽ ra có thể chia sẻ. Hãy dùng câu hỏi này để xác định một hệ thống đang được xây hay đặc tả và hỏi liệu một hệ thống tương đương đã tồn tại như phần mềm nguồn mở ở nơi khác trong chính phủ chưa, hay hệ thống bạn đang xây có thể hữu ích được phát hành cho người khác tái sử dụng không. Hãy thảo luận rào cản cụ thể nào — lo ngại an ninh, thói quen mua sắm, thiếu một chính sách rõ ràng — thực sự đang ngăn việc tái sử dụng đó, thay vì giả định nó không liên quan ở đây.

Quy trình mua sắm và trách nhiệm giải trình của chúng ta có thực sự cho phép cung cấp linh hoạt trung thực, hay chỉ gắn nhãn lại các cột mốc thác nước thành sprint? Thường gặp một nhóm chạy các nghi thức danh nghĩa là linh hoạt trong khi vẫn được tài trợ, quản trị và báo cáo đối chiếu với một đặc tả cố định thỏa thuận lúc ký hợp đồng, điều tái tạo mọi kiểu thất bại của thác nước dưới một nhãn linh hoạt. Hãy dùng câu hỏi này để lần theo một chương trình số đang sống từ luận chứng kinh tế của nó qua báo cáo quản trị hiện tại và hỏi liệu cấu trúc tài trợ có chịu được việc chương trình đổi hướng dựa trên điều một bản phát hành sớm thực sự dạy nó không. Hãy thảo luận điều gì cần thay đổi trong cách chương trình được tài trợ và báo cáo để cung cấp lặp là thật chứ không phải hình thức (xem Chủ đề 3.7 — Mua sắm công và đặt hàng dịch vụ).

Chúng ta có đủ năng lực kỹ nghệ nội bộ để là một người mua thông minh các hệ thống mà chúng ta phụ thuộc nhiều nhất không? Một tổ chức đã thuê ngoài toàn bộ phán đoán kỹ thuật của mình, không chỉ năng lực cung cấp, không thể biết đề xuất của nhà cung cấp có vững không, một dự án có lặng lẽ đi đến rắc rối không, hay giá công bằng cho công việc là bao nhiêu. Hãy dùng câu hỏi này để hỏi bao nhiêu người trong tổ chức bạn có thể xem xét đáng tin một đề xuất kiến trúc kỹ thuật cho hệ thống quan trọng nhất của bạn, và con số đó đã thay đổi thế nào trong năm năm qua. Hãy thảo luận cần gì để xây lại năng lực đó nơi nó đã xói mòn, và tổ chức bạn mất gì, về vị thế đàm phán cũng nhiều như rủi ro cung cấp, mỗi năm mà nó đi qua mà không có.

Trong thực tiễn: một ví dụ về giá trị công

Một chính quyền khu vực hư cấu — chỉ để minh họa, không mô tả bất kỳ khu vực pháp lý có thật nào — chạy các yêu cầu trợ cấp thất nghiệp của mình qua một hệ thống được viết lần đầu hơn ba mươi năm trước, do một số ít kỹ sư ngày càng giảm duy trì, những người hiểu ngôn ngữ lập trình gốc của nó. Khối lượng yêu cầu đã tăng vượt xa điều các nhà thiết kế hệ thống lường trước, các đợt xử lý ban đêm ngày càng không hoàn thành trước khi giao dịch buổi sáng bắt đầu, và ban lãnh đạo công nghệ của cơ quan cảnh báo rằng một sự cố ngừng hoạt động ngoài kế hoạch ảnh hưởng đến thanh toán trợ cấp nay là vấn đề khi nào, không phải liệu có.

Bản năng đầu tiên của cơ quan là một phản ứng thông thường cho một vấn đề có vẻ cấp bách: đặt hàng một hợp đồng lớn duy nhất để thay thế toàn bộ hệ thống bằng một nền tảng hiện đại, đặc tả đầy đủ từ đầu, cung cấp theo một tiến độ hai năm cố định với một cuối tuần chuyển đổi ở cuối. Một cuộc xem xét trước triển khai do ủy ban kiểm toán của cơ quan đặt hàng nêu một câu hỏi khó trước khi hợp đồng được ký: điều gì sẽ xảy ra với thanh toán trợ cấp cho vài trăm nghìn người yêu cầu nếu hệ thống mới có một lỗi chưa phát hiện trong tuần đầu tiên vận hành sống, quy mô đầy đủ, khi hệ thống cũ đã bị ngừng hoạt động và không có đường quay lại.

Cơ quan đổi hướng. Nó giữ hệ thống di sản chạy như hệ thống ghi nhận và bắt đầu xây chức năng tiếp nhận yêu cầu và đánh giá đủ điều kiện mới cạnh nó, dùng cách tiếp cận cây sung bóp cổ: mỗi mô-đun mới được phát hành đầu tiên cho một tỷ lệ phần trăm nhỏ các yêu cầu mới, được xác minh đối chiếu với đầu ra song song của hệ thống cũ, và chỉ mở rộng khi kết quả của nó khớp. Trong vòng mười tám tháng, đa số yêu cầu mới chạy qua các thành phần hiện đại trong khi hệ thống gốc xử lý một danh mục tồn dư ngày càng thu nhỏ, với khả năng chuyển bất kỳ hồ sơ đơn lẻ nào trở lại đường cũ nếu có gì trông sai. Cơ quan cũng yêu cầu, trong mọi hợp đồng mới ban hành cho công việc này, rằng mã nguồn thuộc sở hữu của cơ quan và được công bố là nguồn mở khi việc xem xét an ninh hoàn tất, để các chính quyền khu vực khác đối mặt cùng vấn đề mainframe già cỗi có thể điều chỉnh các thành phần thay vì lặp lại cùng sự xây dựng từ con số không.

Việc thay thế đầy đủ các chức năng tồn dư cuối cùng của hệ thống di sản mất gần bốn năm — trên giấy dài hơn kế hoạch bùng nổ hai năm ban đầu hứa. Nhưng không người yêu cầu nào từng trải qua một sự cố ngừng hoạt động ngoài kế hoạch trong quá trình chuyển đổi, mỗi bước gia tăng đủ nhỏ để đảo ngược trong vòng vài giờ khi một lỗi được tìm thấy, và hai chính quyền khu vực láng giềng bắt đầu điều chỉnh mã đánh giá đủ điều kiện đã công bố của cơ quan cho hệ thống của riêng họ trong năm đầu tiên sau khi phát hành.

Bốn góc nhìn theo khu vực

Chính quyền địa phương

Chính quyền địa phương thường chạy một số lượng lớn các hệ thống nhỏ hơn, rời rạc thay vì một số ít nền tảng quy mô quốc gia, nghĩa là nợ kỹ thuật tích lũy qua nhiều ứng dụng được mua sắm riêng, bảo trì riêng thay vì trong một hệ thống hàng đầu hiển thị. Chính quyền địa phương thường có ít năng lực kỹ nghệ nội bộ nhất trong mọi cấp chính phủ, khiến luận cứ để mua phần mềm hàng hóa có thể cấu hình hơn là xây đặt riêng đặc biệt mạnh, và khiến các nền tảng khu vực hay quốc gia dùng chung — đề tài của Chủ đề 5.1 (xem Chủ đề 5.1 — Chính phủ số và chuyển đổi số) — là một con đường có giá trị đặc biệt cao để tránh mỗi chính quyền riêng xây lại cùng năng lực.

Chính phủ quốc gia

Chính phủ quốc gia là nơi các hệ thống di sản lâu đời nhất và có hệ quả nhất thường nằm — thuế cốt lõi, bảo hiểm xã hội và quản lý trợ cấp — vì chúng thường là một trong những nỗ lực tin học hóa quy mô lớn đầu tiên trong chính phủ và nay mang rủi ro cao nhất cho bất kỳ thất bại hiện đại hóa nào. Chính phủ quốc gia thường có năng lực thương mại và kỹ nghệ chuyên môn để chạy một chương trình hiện đại hóa gia tăng thực sự và thương lượng quyền sở hữu mã thực vào hợp đồng của mình, và thường là cấp chính phủ ở vị trí tốt nhất để đặt một chính sách mặc định nguồn mở với đủ quy mô đằng sau để khiến việc tái sử dụng liên chính phủ thực sự xảy ra.

Khu vực xã hội và phi lợi nhuận

Các tổ chức phi lợi nhuận và từ thiện hiếm khi tự xây các nền tảng đặt riêng lớn, nhưng họ thường ở phía nhận phần mềm do một nhà tài trợ chính phủ đặt hàng hay bắt buộc — một cổng báo cáo, một hệ thống quản lý hồ sơ mà một khoản tài trợ hay hợp đồng yêu cầu họ dùng — với ít ảnh hưởng đến thiết kế, nợ kỹ thuật hay nhà cung cấp của nó. Một tổ chức khu vực xã hội phụ thuộc vào một hệ thống do chính phủ bắt buộc thừa hưởng các kiểu thất bại của hệ thống đó mà không thừa hưởng đòn bẩy nào để sửa chúng, đó là thêm một lý do các quan hệ tài trợ dựa trên kết quả cần tính đến gánh nặng vận hành của công nghệ bắt buộc (xem Chủ đề 3.7 — Mua sắm công và đặt hàng dịch vụ), không chỉ thước đo kết quả.

Đa phương và quốc tế

Các tổ chức đa phương và cơ quan phát triển ngày càng quảng bá phần mềm xây cho hành chính công của một quốc gia như một hàng hóa công số tái sử dụng được mà các quốc gia khác có thể điều chỉnh, thay vì mỗi chính phủ đặt hàng một hệ thống tương đương từ một nhà cung cấp tư nhân với đầy đủ chi phí. Rủi ro đặc trưng ở đây là một hàng hóa công số xây cho bối cảnh pháp lý và hành chính của một quốc gia có thể được áp dụng ở nơi khác với quá ít điều chỉnh, nhập các giả định — về danh tính, đủ điều kiện hay quy trình — thực sự không chuyển giao; lời hứa về hạ tầng mở, dùng chung là thật, nhưng chỉ nơi năng lực điều chỉnh địa phương thực sự đi kèm mã.

Các kiểu thất bại thường gặp

Lần chuyển đổi bùng nổ thất bại khi ra mắt. Một hệ thống di sản trọng yếu được thay thế trong một lần chuyển đổi duy nhất, không thể đảo ngược sau nhiều năm phát triển mà không có tiếp xúc sản xuất sống, và một lỗi chỉ xuất hiện ở quy mô thực hay trong một trường hợp biên mà không ai kiểm thử nổi lên vào ngày đầu của vận hành toàn diện, không có cách quay lại hệ thống cũ vì nó đã bị ngừng hoạt động. Cái giá được đo bằng thanh toán bị lỡ, dịch vụ bị từ chối hoặc sự cố ngừng hoạt động ảnh hưởng đến chính những công dân mà hệ thống tồn tại để phục vụ, vào lúc tồi tệ nhất có thể — khoảnh khắc mọi người đang dựa vào việc thay thế hoạt động.

Tích lũy nợ kỹ thuật im lặng. Áp lực thời hạn liên tục thắng lập luận chống lại thời gian cần để sửa các lối tắt đã biết, và mỗi lần hoãn đều bảo vệ được riêng lẻ, cho đến khi nợ tích lũy khiến ngay cả một thay đổi nhỏ cũng đắt và rủi ro không cân xứng. Cái giá hiện ra nhiều năm sau như một hệ thống không ai có thể sửa đổi an toàn, một lực lượng lao động đã lặng lẽ thôi cố thử bất cứ điều gì ngoài các bản vá khẩn cấp nhất, và một chương trình hiện đại hóa cuối cùng lớn và đắt hơn nhiều so với sự đổi mới liên tục, nhỏ hơn lẽ ra.

Khóa chặt nhà cung cấp bị nhầm là ổn định. Một cơ quan công gia hạn hợp đồng của cùng nhà cung cấp lặp đi lặp lại vì chuyển đổi trông quá gây gián đoạn để thử, mà không bao giờ kiểm nghiệm chi phí chuyển đổi thực sự sẽ là bao nhiêu hay thương lượng quyền sở hữu mã và định dạng dữ liệu mở sẽ giữ các chi phí đó quản lý được. Cái giá là một vị thế đàm phán yếu vĩnh viễn về giá và điều khoản, chỉ được phát hiện khi chất lượng dịch vụ của nhà cung cấp giảm hoặc giá của nó tăng và cơ quan công thấy mình không có phương án thay thế đáng tin.

Linh hoạt hình thức. Một nhóm cung cấp áp dụng các nghi thức linh hoạt — họp đứng, sprint, tồn đọng — trong khi cấu trúc hợp đồng, tài trợ và quản trị nền tảng vẫn giả định một đặc tả cố định và một cột mốc đi/dừng duy nhất, nên nhóm báo cáo vận tốc sprint trong khi thực tế cung cấp theo một kế hoạch thác nước bên dưới. Cái giá là không lợi ích thực sự nào của linh hoạt hiện thực hóa — phản hồi sớm của người dùng thay đổi hướng, rủi ro nổi lên sớm — trong khi vẻ ngoài của thực hành hiện đại làm sự cứng nhắc nền tảng khó thấy hơn và khó thách thức hơn với các cơ quan giám sát.

Chính sách nguồn mở không có kế hoạch duy trì. Một cơ quan công công bố mã nguồn để thỏa mãn một chính sách mặc định nguồn mở nhưng coi việc phát hành là một bước tuân thủ một lần, không cấp nguồn lực để xem xét các đóng góp bên ngoài, vá lỗ hổng hay duy trì tài liệu. Cái giá là một kho lưu trữ đã công bố trông mở nhưng hoạt động như một ngõ cụt không được duy trì, làm hại niềm tin vào chương trình mặc định nguồn mở rộng hơn nhiều hơn việc không bao giờ công bố.

Mô hình trưởng thành

Danh mục kiểm tra

• Kiểm kê nợ kỹ thuật của mọi hệ thống trọng yếu và xem xét sổ đăng ký theo chu kỳ cố định.
• Áp dụng một khung xây-hay-mua có tài liệu trước khi cam kết bất kỳ phần mềm mới đáng kể nào.
• Với bất kỳ sự thay thế hệ thống di sản nào, mặc định theo phương pháp di chuyển gia tăng và yêu cầu một biện minh tường minh cho chuyển đổi bùng nổ.
• Xác nhận điều khoản sở hữu mã nguồn hoặc ký quỹ trong mọi hợp đồng phần mềm trước khi ký.
• Công bố mã nguồn theo chính sách mặc định nguồn mở, với quy trình ngoại lệ có tài liệu.
• Cấp nguồn lực bảo trì liên tục cho mọi kho lưu trữ được công bố theo chính sách đó, không chỉ lần phát hành ban đầu.
• Yêu cầu định dạng dữ liệu mở, có tài liệu ngay cả nơi phần mềm nền tảng là độc quyền.
• Cấu trúc các cổng tài trợ quanh phần mềm hoạt động đã chứng minh thay vì một cột mốc đặc tả cố định duy nhất.
• Xây và kiểm nghiệm một sản phẩm khả thi tối thiểu với người dùng thực trước khi cam kết phạm vi đầy đủ.
• Theo dõi tần suất triển khai, tỷ lệ lỗi và nợ kỹ thuật chưa giải quyết như các chỉ số quản trị thường trực.
• Đánh giá năng lực kỹ nghệ nội bộ đối chiếu với điều cần để là một người mua thông minh, và khép các khoảng trống đã xác định.
• Ưu tiên hạ tầng không được hỗ trợ và tích hợp không có tài liệu trước hiện đại hóa hình ảnh.

Nguồn chính

• Tiêu chuẩn Dịch vụ GOV.UK, Dịch vụ Số của Chính phủ, Vương quốc Anh — một chuẩn dịch vụ số quốc gia yêu cầu cung cấp lặp, lấy người dùng làm trung tâm và chuẩn mở cho các dịch vụ công.
• Văn phòng Quản lý và Ngân sách, Federal Source Code Policy (M-16-21), Hoa Kỳ — chính sách liên bang yêu cầu các cơ quan cân nhắc tái sử dụng và phát hành nguồn mở cho phần mềm chính phủ phát triển đặt riêng.
• Free Software Foundation Europe, chiến dịch Public Money, Public Code — lý do, phát triển cho khán giả châu Âu, để phát hành mã nguồn phần mềm được tài trợ công dưới các giấy phép phần mềm tự do và nguồn mở.
• Ward Cunningham, "The WyCash Portfolio Management System" (báo cáo kinh nghiệm OOPSLA 1992) — phát biểu gốc của ẩn dụ nợ kỹ thuật.
• Digital Public Goods Alliance — một sáng kiến nhiều bên liên quan duy trì các chuẩn và một sổ đăng ký cho phần mềm, dữ liệu và nội dung mở được thiết kế để phục vụ các mục tiêu phát triển công.

Tài liệu tham khảo

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/