Chủ đề 4.0 — Kiến trúc kỹ thuật, đám mây và hệ thống cũ

Trong y tế và chăm sóc, kiến trúc kỹ thuật là một quyết định về an toàn lâm sàng, bảo mật và tiền công được đưa ra trước nhiều năm: các nền tảng bạn dựng lên và hệ thống cũ bạn để lại lặng lẽ quyết định liệu việc chăm sóc có thể an toàn, liền mạch và vừa túi tiền rất lâu sau khi những người đã chọn chúng chuyển đi.

Vì sao điều này quan trọng trong y tế và chăm sóc#

Kiến trúc là tập hợp các lựa chọn cấu trúc sống lâu bên dưới các dịch vụ số của bạn: cái gì chạy ở đâu, các thành phần kết nối ra sao, bạn xây hay mua gì, và bạn giữ sống cái gì từ quá khứ. Những lựa chọn này hiếm khi hiện ra với bệnh nhân hay bác sĩ, và hiếm khi gây hứng thú cho hội đồng quản trị. Thế nhưng chúng định hình mọi thứ nằm phía trên. Một kiến trúc tốt cho phép bạn thêm một dịch vụ mới nhanh, chia sẻ dữ liệu an toàn, và phục hồi nhanh khi có gì hỏng. Một kiến trúc tồi khiến mọi thay đổi chậm, mọi tích hợp mong manh, và mọi sự cố tệ hơn.

Trong y tế và chăm sóc rủi ro cao vì các hệ thống có hệ quả lớn. Khi một hệ thống quản lý bệnh nhân già cỗi sụp đổ, xe cứu thương chuyển hướng và các phòng khám bị hủy. Khi một hệ điều hành không được hỗ trợ bị khai thác, hồ sơ bí mật bị phơi bày và dịch vụ dừng — như NHS đã học năm 2017 khi cuộc tấn công mã độc tống tiền WannaCry lan qua các máy chạy phần mềm không còn có thể vá. Sự gián đoạn đó không phải một cuộc tấn công thông minh, có mục tiêu; đó là hệ quả có thể đoán trước của nợ kỹ thuật tích tụ trong các hệ thống then chốt. Các quyết định kiến trúc do đó là các quyết định an toàn, dù có ai định khung chúng như vậy hay không.

Chúng cũng là các quyết định về công bằng và niềm tin. Các hệ thống cũ không thể chia sẻ dữ liệu để lại những bệnh nhân phức tạp nhất — những người chạm đến nhiều dịch vụ — với hồ sơ phân mảnh nhất. Các nền tảng đóng nhốt bạn vào một nhà cung cấp duy nhất rút cạn tiền lẽ ra có thể tài trợ chăm sóc. Và công chúng chính đáng kỳ vọng NHS chạy trên công nghệ hiện đại, an toàn, được bảo trì tốt; khoảng cách giữa kỳ vọng đó và hệ thống thực tế tự nó là một rủi ro đối với niềm tin.

Cuối cùng, đây là nơi rất nhiều tiền công được cam kết trong một thời gian rất dài. Phần đắt nhất của một hệ thống hiếm khi là việc mua nó; đó là thập kỷ lưu trữ, cấp phép, bảo trì và thay thế cuối cùng theo sau. Các nhà lãnh đạo xem kiến trúc là "việc nhóm kỹ thuật lo" đang ủy quyền một số cam kết tài chính lớn nhất và lâu nhất mà tổ chức đưa ra. Chủ đề này được viết để bạn có thể buộc các quyết định đó giải trình mà không cần là một kỹ sư.

Các khái niệm cốt lõi#

Kiến trúc doanh nghiệp là ngành căn chỉnh các quy trình kinh doanh, thông tin, ứng dụng và công nghệ của một tổ chức để chúng hỗ trợ chiến lược một cách mạch lạc thay vì lớn lên ngẫu nhiên. Nó nhìn toàn tổ chức: cần những năng lực nào, hệ thống nào cung cấp chúng, và khoảng trống cùng sự trùng lặp nằm ở đâu. Kiến trúc giải pháp là ngành hẹp hơn, ở cấp dự án, thiết kế cách một dịch vụ cụ thể sẽ được xây và khớp vào hệ thống rộng hơn. Cả hai nằm trong ý niệm rộng hơn về kiến trúc hệ thống — mô hình cấu trúc về cách các thành phần, giao diện và hành vi kết hợp thành một tổng thể hoạt động. Các nhà lãnh đạo không cần thực hành các ngành này, nhưng nên khăng khăng rằng chúng tồn tại, vì sự vắng mặt của chúng là cách các hệ thống trở nên không thể quản lý.

Kiến trúc được dẫn dắt bởi các nguyên tắc kiến trúc: một tập ngắn, đã thỏa thuận các phát biểu — như "tái sử dụng trước khi mua, mua trước khi xây" hay "xây theo chuẩn mở" — làm cho các quyết định nhất quán khả thi mà không cần mọi lựa chọn bị đẩy lên cấp trên. Các nguyên tắc được thực thi, nhẹ nhàng, bởi một cơ quan thiết kế (design authority): một nhóm nhỏ rà soát các quyết định kỹ thuật đáng kể. Phiên bản lành mạnh của một cơ quan thiết kế tạo điều kiện thay vì chặn; nó tồn tại để ngăn tác hại và trùng lặp có thể tránh được, không phải để làm chậm các nhóm hay gác cổng vì chính nó.

Điện toán đám mây là việc cung cấp năng lực tính toán — máy chủ, lưu trữ, cơ sở dữ liệu, mạng — như một dịch vụ theo yêu cầu qua Internet, thay vì từ phần cứng bạn sở hữu trong tòa nhà của mình. Đám mây công cộng do một nhà cung cấp bên thứ ba vận hành và chia sẻ giữa nhiều khách hàng; đám mây riêng dành riêng cho một tổ chức; đám mây lai kết hợp hai loại, thường giữ một số tải công việc trên hạ tầng hiện có trong khi chuyển những cái khác ra ngoài. Nhiều chính phủ, kể cả của Vương quốc Anh, đã áp dụng chính sách "đám mây trước", nghĩa là các nhóm nên cân nhắc đám mây công cộng trước các lựa chọn khác và biện minh khi không dùng. Vì đám mây được tính theo mức tiêu thụ thay vì mua một lần, kiểm soát chi tiêu đó đã trở thành một kỷ luật riêng — FinOps, thực hành đưa kỹ thuật và tài chính lại với nhau để các nhóm có khả năng quan sát, và trách nhiệm giải trình về, việc sử dụng đám mây thực sự tốn bao nhiêu. Ở tầng ứng dụng, phần mềm như một dịch vụ (SaaS) cung cấp một ứng dụng hoàn chỉnh qua web do nhà cung cấp lưu trữ và bảo trì, nên bạn cấu hình thay vì vận hành nó. Hạ tầng và lưu trữ — nơi và cách các hệ thống của bạn chạy về mặt vật lý — nằm bên dưới tất cả điều này, và ngày càng mang một cái giá carbon thuộc về quyết định (xem Chủ đề 8.5 — Bền vững và phát thải ròng bằng không).

Một hệ thống cũ là một hệ thống già cỗi nhưng vẫn được dựa vào, khó thay đổi, thường chạy phần mềm không được hỗ trợ mà các bản vá bảo mật không còn được phát hành. Hệ thống cũ tích tụ thành nợ kỹ thuật — cái giá tương lai của những lựa chọn tạm bợ trong quá khứ. Một ít nợ là bình thường và thậm chí hợp lý; nợ không được quản lý ở quy mô lớn trở thành trách nhiệm an toàn và bảo mật, vì các hệ thống mà hầu hết mọi người phụ thuộc trở thành những hệ thống không ai dám chạm vào. Quản lý điều này là công việc của quản lý danh mục ứng dụng: giữ một bản kiểm kê rõ ràng về mọi ứng dụng, chi phí, tình trạng và giá trị kinh doanh của nó, để bạn có thể hợp lý hóa hệ thống — cho nghỉ hưu, thay thế hoặc hợp nhất các hệ thống — và cho nghỉ hưu an toàn thay vì để cái cũ lặng lẽ chạy.

Các hệ thống hiện đại được giữ với nhau bởi giao diện lập trình ứng dụng (API): các giao diện xác định qua đó một hệ thống cung cấp một năng lực cho hệ thống khác. API được thiết kế tốt cho phép bạn lắp ráp các nền tảng — dịch vụ tái sử dụng mà nhiều nhóm xây trên đó — trong khi giữ các thành phần ghép lỏng và thay thế được. Một kỷ luật hữu ích ở đây là "nền tảng khả thi mỏng nhất": chỉ xây năng lực dùng chung thực sự giảm công việc của người khác, và không hơn. Nền tảng của thiết kế an toàn là an toàn theo thiết kế, nguyên tắc rằng bảo mật được xây vào từ đầu thay vì gắn thêm về sau. Và khung tài chính cho tất cả là tổng chi phí sở hữu (TCO): toàn bộ chi phí suốt vòng đời của một hệ thống, không phải giá mua — lăng kính qua đó lựa chọn xây/mua/cấu hình, và rủi ro bị khóa chặt vào nhà cung cấp, nên được đánh giá.

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

1. Thống nhất một tập ngắn các nguyên tắc kiến trúc và dùng chúng để quyết định. Viết ra một nhúm nguyên tắc rõ ràng, dễ nhớ — tái sử dụng trước khi mua trước khi xây, xây theo chuẩn mở, đám mây nơi hợp lý, an toàn theo thiết kế, thiết kế cho toàn bộ lộ trình chăm sóc — và để các nhóm đưa ra hầu hết quyết định bằng cách áp dụng chúng. Các nguyên tắc chỉ hiệu quả nếu thực sự được dùng để nói có và không, và chỉ nếu đủ ít để nhớ. Điều này nối trực tiếp với Chủ đề 1.1 — Mô hình vận hành và Chủ đề 1.2 — Chiến lược số và lộ trình, vốn đặt hướng mà các nguyên tắc phục vụ.

2. Vận hành một cơ quan thiết kế tạo điều kiện thay vì chặn. Thiết lập một nhóm nhỏ, cấp cao, đa ngành để rà soát các quyết định kỹ thuật đáng kể — những quyết định đắt, khó đảo ngược, ảnh hưởng nhiều dịch vụ, hoặc mang rủi ro an toàn và bảo mật. Trao cho nó một đường nhanh, gọn nhẹ để các lựa chọn thường lệ không bị kéo qua nó, và buộc nó theo một chuẩn dịch vụ: nó nên giúp các nhóm tìm một câu trả lời tốt, không chỉ từ chối. Một cơ quan thiết kế trở thành điểm nghẽn sẽ bị đi vòng, và kiến trúc bóng còn tệ hơn không có.

3. Áp dụng đám mây có chủ đích, từng tải công việc một, không phải như khẩu hiệu. Xem "đám mây trước" là một mặc định để lập luận, không phải mệnh lệnh chuyển mọi thứ. Đánh giá từng tải công việc về sự phù hợp, nơi lưu trữ dữ liệu, khả năng chống chịu, chi phí ở quy mô lớn, và công sức di chuyển, và trung thực rằng nhấc-và-đặt một ứng dụng cũ không đổi thường chỉ chuyển vấn đề với chi phí cao hơn. Cân nhắc rõ ràng chiều kích carbon, vì nơi và cách bạn lưu trữ ảnh hưởng đến phát thải (xem Chủ đề 8.5 — Bền vững và phát thải ròng bằng không), và thiết kế để di động sao cho một lần chuyển giữa các nhà cung cấp trong tương lai vẫn khả thi.

4. Duy trì một danh mục ứng dụng sống và quản lý nợ kỹ thuật như một rủi ro có tên. Giữ một bản kiểm kê chính xác về mọi ứng dụng, người sở hữu kinh doanh, chi phí, khả năng được hỗ trợ và rủi ro nó mang, và rà soát thường xuyên. Đưa nợ kỹ thuật và phần mềm không được hỗ trợ vào sổ đăng ký rủi ro doanh nghiệp với sự nghiêm túc như rủi ro lâm sàng hay tài chính, vì đó chính là điều nó là. Cái bạn không thấy được, bạn không thể tài trợ, ưu tiên hay cho nghỉ hưu an toàn, và các hệ thống chưa bao giờ được kiểm kê chính là những hệ thống thất bại không báo trước.

5. Hợp lý hóa hệ thống và cho nghỉ hưu an toàn. Chủ động cho nghỉ hưu các hệ thống trùng lặp, lỗi thời và hết vòng đời thay vì để chúng nấn ná "phòng khi", vì mỗi hệ thống đang chạy là một bề mặt tấn công, một chi phí cấp phép và một gánh nặng bảo trì. Cho nghỉ hưu là một dự án riêng: di chuyển hoặc lưu trữ dữ liệu theo quy tắc lưu giữ rõ ràng, xác nhận không còn gì phụ thuộc vào hệ thống, truyền thông với người dùng, và xác minh trước khi tắt. Làm tốt, hợp lý hóa giải phóng tiền và giảm rủi ro; làm cẩu thả, nó phá hủy hồ sơ hoặc làm hỏng một phụ thuộc không ai ghi chép.

6. Ưu tiên chuẩn mở, API và các thành phần ghép lỏng. Thiết kế sao cho các năng lực được phơi bày qua API được ghi chép, có phiên bản, để một thành phần có thể được thay thế mà không phải xây lại mọi thứ xung quanh. Đây là nền tảng kiến trúc cho khả năng tương tác được thảo luận ở Chủ đề 4.3 — Khả năng tương tác và chuẩn dữ liệu, và là tuyến phòng thủ chính của bạn chống bị khóa chặt. Nó tốn nhiều hơn một chút lúc đầu so với một kết nối mã hóa cứng trực tiếp, và hoàn lại nhiều lần ngay lần đầu bạn cần đổi nhà cung cấp hoặc thêm dịch vụ.

7. Xây nền tảng khả thi mỏng nhất, và không hơn. Khi bạn tạo một nền tảng dùng chung cho người khác xây trên đó, hãy cưỡng lại sự thôi thúc làm nó toàn diện từ ngày đầu. Cung cấp năng lực tái sử dụng nhỏ nhất thực sự loại bỏ công việc cho các nhóm, chứng minh nó được dùng, và mở rộng nó để đáp ứng nhu cầu thực. Các nền tảng xây quá mức trở thành hệ thống cũ của chính chúng — đắt, cứng nhắc và bị oán — trong khi một nền tảng mỏng, vận hành tốt giành được sự chấp nhận và tiến hóa theo nhu cầu.

8. Biến kiến trúc bảo mật và an toàn theo thiết kế thành không thể thương lượng. Đưa tư duy bảo mật vào thiết kế từ bản phác thảo đầu tiên, không phải như một cổng trước khi ra mắt: tối thiểu hóa bề mặt tấn công, áp dụng đặc quyền tối thiểu, phân đoạn mạng, và giả định các thành phần sẽ bị thăm dò. Trong y tế và chăm sóc điều này không thể tách rời khỏi an toàn lâm sàng và quản trị thông tin (Chủ đề 1.6 — An toàn lâm sàng và quản lý rủi ro; Chủ đề 1.7 — Quản trị thông tin, bảo vệ dữ liệu và an ninh mạng), vì một vụ vi phạm vừa là tác hại dữ liệu vừa, khi nó dừng hệ thống, là một sự kiện an toàn bệnh nhân. Phần mềm không được hỗ trợ, không thể vá là một quyết định bảo mật bạn đang đưa ra theo mặc định — nên hãy đưa ra nó một cách có chủ đích, với các biện pháp giảm thiểu, hoặc không làm.

9. Quyết định xây, mua hay cấu hình dựa trên tổng chi phí sở hữu, không phải giá niêm yết. Với mỗi năng lực, so sánh xây riêng, mua một sản phẩm và cấu hình một nền tảng hiện có trên toàn bộ chi phí suốt vòng đời của chúng — lưu trữ, cấp phép, tích hợp, hỗ trợ, nâng cấp và rút lui cuối cùng — không phải giá ban đầu. Ưu tiên mua hoặc cấu hình cho các nhu cầu thông dụng và dành việc xây cho sự khác biệt thực sự, và cân nhắc sự khóa chặt mà mỗi lựa chọn tạo ra. Làm việc này cùng đồng nghiệp thương mại (Chủ đề 6.3 — Mua sắm và thương mại), vì thời điểm rẻ nhất để bảo đảm các giao diện mở và quyền rút lui là trước khi bạn ký.

10. Xem chi tiêu đám mây như một kỷ luật chung giữa kỹ thuật và tài chính (FinOps). Trao cho các nhóm khả năng quan sát rõ ràng về dịch vụ của họ tốn bao nhiêu bằng cách gắn thẻ tài nguyên đám mây cho người sở hữu, điều chỉnh kích cỡ các instance theo mức sử dụng thực, và tắt các tài nguyên nhàn rỗi hay cấp quá mức thay vì trả cho chúng tháng này qua tháng khác. Làm cho các nhóm vận hành một dịch vụ chịu trách nhiệm về chi phí chạy nó, để những người có vị trí tốt nhất để giảm lãng phí là những người thấy hóa đơn. Đám mây trả-theo-dùng không có kỷ luật này lặng lẽ tiêu thụ ngân sách lẽ ra tài trợ chăm sóc, và sự trôi hiếm khi được chú ý cho đến khi một hóa đơn buộc đặt câu hỏi.

11. Thiết kế kiến trúc theo chi phí như một yêu cầu phi chức năng hạng nhất, cân nhắc với carbon và khả năng chống chịu. Đối xử với chi phí như bạn đối xử với hiệu năng, bảo mật và tính sẵn sàng: một thuộc tính bạn thiết kế một cách có chủ đích, ước lượng trước khi xây, và rà soát khi sử dụng tăng. Cân nhắc nó rõ ràng với carbon (xem Chủ đề 8.5 — Bền vững và phát thải ròng bằng không) và với khả năng chống chịu, vì ba thứ này thường cùng dịch chuyển — nhưng đừng bao giờ đuổi theo hóa đơn thấp nhất với cái giá là an toàn, khả năng phục hồi hay kết quả bệnh nhân. Câu trả lời đúng là chi phí thấp nhất vẫn đáp ứng các nghĩa vụ an toàn lâm sàng và chống chịu của bạn, không phải lựa chọn rẻ nhất tách biệt.

Câu hỏi để thảo luận với nhóm của bạn#

1. Những hệ thống then chốt nào của chúng ta hiện không được hỗ trợ hoặc không thể vá, và mức phơi bày thực sự của chúng ta là gì nếu một cái bị tấn công hoặc thất bại? Hãy bắt đầu từ các hệ thống mà các dịch vụ lâm sàng và vận hành thực sự không thể hoạt động nếu thiếu, và xác lập cụ thể cái nào chạy phần mềm không còn nhận cập nhật bảo mật hay hỗ trợ của nhà cung cấp. Hỏi điều gì sẽ xảy ra — với bệnh nhân, nhân viên, dữ liệu — nếu mỗi cái bị mã độc tống tiền tấn công hay đơn giản là dừng, và việc phục hồi sẽ mất bao lâu. Phân biệt các hệ thống bạn đã chủ động chấp nhận rủi ro, với các biện pháp giảm thiểu tại chỗ, với những hệ thống mà sự mong manh chưa ai đánh giá. Hãy cân nhắc liệu mức phơi bày này có hiển thị trên sổ đăng ký rủi ro doanh nghiệp hay bị chôn trong một bảng tính mà hội đồng chưa bao giờ thấy. Hãy suy ngẫm về WannaCry: tác hại không đến từ sự tinh vi mà từ nợ đã biết, chưa được giải quyết trong các hệ thống then chốt. Nếu bạn không thể trả lời điều này bằng bằng chứng, chính khoảng trống đó là phát hiện khẩn cấp nhất của bạn, vì bạn không thể tài trợ một rủi ro bạn chưa gọi tên.

2. Chúng ta bị khóa chặt ở đâu, và rời nền tảng lớn nhất của mình thực sự sẽ tốn chúng ta bao nhiêu? Nhiều tổ chức chỉ khám phá cái giá thực của một hệ thống đóng khi họ cố thay đổi nó. Hãy đi qua điều thực sự cần để chuyển khỏi nền tảng lâm sàng hay doanh nghiệp lớn nhất của bạn: liệu bạn có thể trích xuất dữ liệu ở dạng dùng được, chuẩn không, các giao diện độc quyền nào sẽ phải gỡ, và hợp đồng của bạn nói gì về quyền sở hữu và rút lui. Hãy cân nhắc liệu "đám mây" có lặng lẽ trở thành một kiểu khóa chặt khác, với dữ liệu và công cụ vướng chặt vào một nhà cung cấp đến mức rời đi là không thực tế. Cân nhắc điều này với độ mở của các phương án thay thế và bất kỳ nền tảng quốc gia nào bạn có thể tái sử dụng thay vì. Đây không phải lập luận cho việc đổi nhà cung cấp liên tục; đó là về việc hiểu đòn bẩy của bạn trước lần đàm phán tới, và không để lộ trình của một nhà cung cấp lặng lẽ trở thành lựa chọn duy nhất của bạn.

3. Chúng ta có đang đầu tư đủ vào việc bảo trì và hợp lý hóa những gì đã có, hay chỉ vào cái mới và hữu hình? Các hệ thống mới thu hút kinh phí và sự chú ý; công việc kém hào nhoáng của vá, nâng cấp, hợp nhất và cho nghỉ hưu an toàn hiếm khi được vậy, chính xác là cách nợ tích tụ. Hỏi tỷ lệ ngân sách số của bạn thực sự dành cho việc giữ hệ thống hiện có an toàn và cập nhật so với xây cái mới, và có ai sở hữu sự cân bằng đó một cách có chủ đích không. Hãy thảo luận liệu việc cho nghỉ hưu có bao giờ được cấp nguồn lực đúng mức, hay các hệ thống cũ chỉ đơn giản nấn ná vì tắt chúng không phải việc của ai. Hãy cân nhắc các ứng dụng trùng lặp làm cùng một việc trong tổ chức, và điều cần để hợp nhất chúng. Hãy nghĩ ai, ở cấp hội đồng quản trị, chịu trách nhiệm về sức khỏe của toàn bộ hệ thống thay vì các dự án riêng lẻ. Một tổ chức chỉ tài trợ cái mới đang vay đối lại an toàn tương lai của chính mình, và việc hoàn trả luôn đến hạn vào lúc tệ nhất.

4. Chúng ta có thực sự biết đám mây của mình tốn bao nhiêu, ai sở hữu hóa đơn đó, và chi tiêu có được kiểm soát không? Đám mây trả-theo-dùng có thể lặng lẽ tiêu thụ ngân sách lẽ ra tài trợ chăm sóc, và sự trôi hiếm khi được chú ý cho đến khi một hóa đơn buộc đặt câu hỏi. Hỏi liệu tài nguyên đám mây có được gắn thẻ cho các nhóm và dịch vụ sở hữu chúng không, có ai điều chỉnh kích cỡ instance theo mức sử dụng thực không, và các tài nguyên nhàn rỗi hay cấp quá mức có bao giờ bị tắt không. Hãy thảo luận liệu những người vận hành một dịch vụ có thấy và chịu trách nhiệm về chi phí chạy nó không, hay chi tiêu đám mây đáp xuống như một dòng không giải thích được duy nhất trong ngân sách trung tâm mà không ai phân tách được. Hãy cân nhắc liệu chi phí có được xem là yêu cầu phi chức năng hạng nhất — được ước lượng trước khi bạn xây và rà soát khi sử dụng tăng — hay chỉ được khám phá sau sự việc. Hãy trung thực về căng thẳng giữa quyền tự chủ kỹ thuật và kiểm soát tài chính, và về việc cân nhắc chi phí với carbon và khả năng chống chịu thay vì đơn giản đuổi theo hóa đơn thấp nhất. Một câu trả lời trung thực gọi tên ai nắm kỷ luật FinOps và cho thấy bằng chứng nó đang hiệu quả, thay vì cho rằng đám mây rẻ hơn vì nó hiện đại.

5. Khi chúng ta cần một năng lực mới, chúng ta quyết định giữa xây, mua và cấu hình thứ đã có như thế nào — và dựa trên cơ sở nào? Bản năng xây riêng, hoặc mua sản phẩm có bản demo tốt nhất, thường thắng trước khi ai đó so sánh toàn bộ chi phí suốt vòng đời. Hãy đi qua cách vài lựa chọn đáng kể gần nhất của bạn thực sự được đưa ra: liệu lưu trữ, cấp phép, tích hợp, hỗ trợ, nâng cấp và rút lui cuối cùng có được cân nhắc, hay chỉ giá ban đầu. Hỏi liệu bạn có dành việc xây cho sự khác biệt thực sự và mặc định mua hoặc cấu hình cho nhu cầu thông dụng không, hay các bản dựng đặt riêng lặng lẽ sinh sôi vì một nhóm thích chúng. Hãy cân nhắc ai ở trong phòng cho các quyết định này — đồng nghiệp thương mại và lâm sàng cũng như kỹ sư — và liệu sự khóa chặt mà mỗi lựa chọn tạo ra có được đánh giá trước khi ký hay chỉ được khám phá sau. Hãy suy ngẫm liệu các nguyên tắc kiến trúc của bạn ("tái sử dụng trước khi mua, mua trước khi xây") có thực sự ràng buộc các lựa chọn này hay bị lặng lẽ bỏ qua. Một câu trả lời trung thực có thể chỉ ra các quyết định thực mà tổng chi phí sở hữu, không phải giá niêm yết, đã thay đổi kết quả.

6. Chúng ta có năng lực kiến trúc nội bộ để nắm giữ các quyết định của chính mình, hay chúng ta phụ thuộc vào chính các nhà cung cấp mà chúng ta đáng ra phải buộc giải trình? Kiến trúc là nơi những cam kết lớn nhất và lâu nhất được đưa ra, thế nhưng nhiều tổ chức đã làm rỗng chính năng lực cần để đưa ra chúng tốt, dựa vào các nhà cung cấp có sản phẩm đang được đánh giá để cho họ biết thế nào là tốt. Hỏi liệu bạn có kỹ năng kiến trúc doanh nghiệp và giải pháp đáng tin ở phía mình không, và cơ quan thiết kế của bạn được bố trí để tạo điều kiện cho các nhóm hay chỉ đóng dấu cao su. Hãy thảo luận liệu các quyết định đáng kể, khó đảo ngược có thực sự được kiểm thử theo các nguyên tắc đã thỏa thuận hay thực chất được ủy quyền cho nhà cung cấp nào gần vấn đề nhất. Hãy cân nhắc bạn sẽ nhận ra một khuyến nghị kiến trúc tồi bằng cách nào nếu bạn không có chuyên môn độc lập để thách thức nó. Cân nhắc cái giá của việc xây dựng và giữ năng lực này với cái giá lớn hơn nhiều của sự khóa chặt và làm lại mà sự vắng mặt của nó tạo ra. Một câu trả lời trung thực phân biệt các quyết định bạn thực sự có thể sở hữu với những quyết định bạn hiện đang tin theo.

Trong thực tế: một ví dụ về y tế và chăm sóc#

Hệ thống kỹ thuật của một bệnh viện cấp cứu đã lớn lên hữu cơ suốt hai thập kỷ. Ở trung tâm là một hệ thống quản lý bệnh nhân chạy trên một hệ điều hành mà nhà cung cấp đã ngừng hỗ trợ mười tám tháng trước; quanh nó là hơn hai trăm ứng dụng, nhiều cái được mua theo khoa, vài cái làm công việc chồng chéo, và không ai nắm một danh sách đầy đủ. Một suýt xảy ra — một nỗ lực mã độc tống tiền bị chặn nhờ may hơn là thiết kế — khiến hội đồng đặt một câu hỏi chưa bao giờ hỏi: chính xác chúng ta đang chạy gì, và chúng ta đang bị phơi bày ra sao?

Giám đốc thông tin số cưỡng lại bản năng khởi động một chương trình "thay thế mọi thứ" duy nhất, anh hùng, và làm trước công việc tẻ nhạt. Quỹ xây một danh mục ứng dụng sống: mọi hệ thống, người sở hữu kinh doanh, khả năng được hỗ trợ, chi phí và rủi ro của nó. Bức tranh thật đáng lo — một phần năm ứng dụng chạy phần mềm không được hỗ trợ, và một chục cái trùng lặp các năng lực đã có ở nơi khác — nhưng lần đầu tiên nó hữu hình, và những phơi bày tệ nhất đi thẳng vào sổ đăng ký rủi ro doanh nghiệp nơi hội đồng có thể thấy chúng.

Từ bản kiểm kê đó quỹ đưa ra các lựa chọn có chủ đích dẫn dắt bởi một nhúm nguyên tắc kiến trúc đã thỏa thuận. Hệ thống quản lý bệnh nhân không được hỗ trợ được ưu tiên thay thế, được mua sắm như một sản phẩm có thể cấu hình với các quyền API mở và trích xuất dữ liệu theo hợp đồng để quỹ không bị khóa chặt lần nữa. Các tải công việc phù hợp chuyển sang đám mây công cộng, được đánh giá từng cái một thay vì theo khẩu hiệu, với carbon và tính di động được cân nhắc cạnh chi phí. Một cơ quan thiết kế nhỏ rà soát các quyết định đáng kể và thông qua nhanh các quyết định thường lệ. Mười hai ứng dụng khoa chồng chéo được hợp nhất còn ba, và các hệ thống đã nghỉ hưu được cho nghỉ hưu đúng cách — dữ liệu được di chuyển theo quy tắc lưu giữ rõ ràng, các phụ thuộc được kiểm tra, người dùng được thông báo, và chỉ sau đó mới tắt.

Không điều nào trong số này lên tiêu đề. Nhưng mười tám tháng sau, quỹ biết mình chạy gì, món nợ nguy hiểm nhất của nó đang được trả theo một kế hoạch được tài trợ thay vì hy vọng nó tự biến mất, và một tích hợp hồ sơ chăm sóc dùng chung mới được giao trong vài tuần vì các hệ thống thay thế phơi bày API mở. Suýt xảy ra đó trở thành khoảnh khắc quỹ bắt đầu quản lý kiến trúc của mình thay vì bị nó quản lý.

Góc nhìn theo khu vực#

Công ty khởi nghiệp#

Một công ty khởi nghiệp y tế số có thứ xa xỉ là ít hệ thống cũ và nên bảo vệ nó quyết liệt. Hãy xây gốc-đám-mây ngay từ đầu, phơi bày API mở, và xem an toàn theo thiết kế là một tính năng cốt lõi chứ không phải chi phí về sau, vì những người mua NHS thận trọng sẽ soi kỹ kiến trúc bảo mật và điều khoản trích xuất dữ liệu của bạn. Giữ nền tảng khả thi mỏng nhất của riêng bạn thực sự mỏng, cưỡng lại cám dỗ thiết kế quá mức cho quy mô bạn chưa có. Con đường nhanh nhất để tích lũy nợ kỹ thuật tàn phá là giao mã tạm bợ dưới áp lực nhà đầu tư rồi không bao giờ trả, nên hãy đưa ra các lựa chọn có chủ đích, hữu hình về nợ nào bạn gánh. Nghịch lý là thiết kế để một khách hàng có thể trích xuất dữ liệu của họ và rời đi chính là điều giành được niềm tin giữ họ lại.

Doanh nghiệp nhỏ#

Một nhà cung cấp nhỏ đã thành lập — một phòng khám bác sĩ gia đình, một hiệu thuốc cộng đồng, một nhà dưỡng lão, một phòng khám đơn lẻ, hoặc một nhà cung cấp công nghệ y tế nhỏ đã qua giai đoạn khởi nghiệp — mang cùng nghĩa vụ như một bệnh viện lớn nhưng với một phần nhỏ nguồn lực và hiếm khi có năng lực CNTT chuyên trách. Ở đây kiến trúc phần lớn là kỷ luật mua tốt: ưu tiên phần mềm như một dịch vụ uy tín để nhà cung cấp gánh việc lưu trữ, vá lỗi và bảo mật mà bạn không thể bố trí nhân sự, và đọc hợp đồng để tìm quyền trích xuất dữ liệu và rút lui trước khi ký, vì sự khóa chặt cắn đau nhất khi bạn không có đòn bẩy. Giữ một bản kiểm kê đơn giản về nhúm hệ thống bạn phụ thuộc và biết cái nào còn được hỗ trợ, vì ngay cả một hệ thống nhỏ cũng có thể che giấu một máy chưa vá làm dừng phòng khám. Khăng khăng nhà cung cấp đáp ứng các chuẩn được công nhận như Bộ công cụ Bảo mật và Bảo vệ Dữ liệu thay vì cố đánh giá bảo mật từ đầu. Khi tiền mặt eo hẹp, cám dỗ là giữ một hệ thống cũ, không được hỗ trợ chạy để tránh một hóa đơn, nhưng đó là một quyết định an toàn bạn nên đưa ra có chủ đích, không phải theo sự trôi.

Doanh nghiệp lớn#

Một bệnh viện lớn hoặc nhà cung ứng lớn mang hàng thập kỷ hệ thống tích lũy và không thể đơn giản làm lại từ đầu. Chiến lược thực tế là tiến hóa có kỷ luật: duy trì một danh mục sống, đặt các lớp mở, dựa trên API trước những gì phải ở lại, và trả món nợ nguy hiểm nhất theo một kế hoạch được tài trợ, ưu tiên thay vì trong những cơn hoảng loạn thỉnh thoảng. Vận hành một cơ quan thiết kế được kính trọng vì nó tạo điều kiện cho việc triển khai, không bị sợ vì nó chặn, và biến nợ kỹ thuật thành rủi ro thường trực cấp hội đồng quản trị với một người sở hữu có tên. Đề phòng sự khóa chặt ở mỗi lần gia hạn, và xem cho nghỉ hưu là công việc thực, được cấp nguồn lực chứ không phải điều nghĩ sau. Đây là cùng kỷ luật tái sử dụng và giao diện mở chi phối các nền tảng vận hành cốt lõi trong Chủ đề 5.4 — Hoạch định nguồn lực doanh nghiệp (ERP).

Chính phủ#

Các cơ quan quốc gia và khu vực đặt ra các điều kiện mà cả ngành vận hành trong đó, và các lựa chọn kiến trúc của họ lan ra bên ngoài. Những điều giá trị nhất chính phủ có thể làm là bắt buộc chuẩn mở, cung cấp các nền tảng quốc gia tái sử dụng được để các tổ chức địa phương xây một lần, và đặt các kỳ vọng về đám mây, bảo mật và bền vững nâng mức sàn ở khắp nơi. Quan trọng là chính phủ phải tài trợ công việc quốc gia kém hào nhoáng — khắc phục hệ thống cũ, bảo trì thuật ngữ, hỗ trợ cho nghỉ hưu — mà không tổ chức đơn lẻ nào sẽ tài trợ một mình nhưng mọi người đều phụ thuộc. Một chuẩn đủ tốt được thực thi vững chắc và tái sử dụng rộng rãi thắng một chuẩn vượt trội về lý thuyết được triển khai không nhất quán. Vai trò quản lý này nối với Chủ đề 9.1 — Làm việc với chính quyền địa phương và quốc gia và với cách các đối tác hợp tác trong Chủ đề 9.0 — Hợp tác với các tổ chức đối tác.

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

• Hệ thống vô hình. Chạy hàng trăm ứng dụng không có bản kiểm kê chính xác, nên mức phơi bày không rõ, sự trùng lặp không được chú ý, và dấu hiệu đầu tiên của sự mong manh là một sự cố ngừng hoạt động hoặc vi phạm.
• Nợ bị giấu khỏi hội đồng. Giữ phần mềm không được hỗ trợ và nợ kỹ thuật như một chú thích kỹ thuật thay vì một rủi ro doanh nghiệp có tên, nên nó không bao giờ được tài trợ cho đến khi thất bại.
• Đám mây như khẩu hiệu. Nhấc-và-đặt hệ thống cũ không đổi lên đám mây công cộng theo nguyên tắc, chuyển vấn đề với chi phí cao hơn, hoặc vướng dữ liệu và công cụ sâu vào một nhà cung cấp đến mức nó trở thành một sự khóa chặt mới.
• Cơ quan thiết kế như điểm nghẽn. Để quản trị kiến trúc trở thành một cổng chậm mà các nhóm đi vòng, tạo ra kiến trúc bóng không được ghi chép còn tệ hơn không có.
• Xây khi lẽ ra nên cấu hình. Chọn bản dựng riêng cho nhu cầu thông dụng, dựa trên giá niêm yết thay vì tổng chi phí sở hữu, và thừa hưởng một thập kỷ bảo trì bạn chưa lập ngân sách.
• Không bao giờ cho nghỉ hưu. Để các hệ thống lỗi thời chạy "phòng khi", mỗi cái là một bề mặt tấn công, một chi phí cấp phép và một sự rút cạn bảo trì không ai sở hữu.
• Bảo mật gắn thêm. Xem bảo mật là cổng trước khi ra mắt thay vì đầu vào thiết kế, nên bề mặt tấn công được đặt từ rất lâu trước khi ai đánh giá nó.
• Khóa chặt theo mặc định. Ký các nền tảng không có giao diện mở hay quyền trích xuất dữ liệu, và chỉ khám phá cái giá của cái bẫy khi bạn cố rời đi.

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

Danh sách kiểm tra#

• Một danh mục ứng dụng sống ghi lại người sở hữu, chi phí, khả năng được hỗ trợ và rủi ro của mọi hệ thống, và được rà soát thường xuyên.
• Các hệ thống then chốt không được hỗ trợ và không thể vá được xác định và nằm trên sổ đăng ký rủi ro doanh nghiệp, không phải trong một bảng tính kỹ thuật.
• Một tập ngắn các nguyên tắc kiến trúc đã thỏa thuận thực sự được dùng để đưa ra và biện minh các quyết định.
• Một cơ quan thiết kế rà soát các quyết định đáng kể, khó đảo ngược và thông qua nhanh các quyết định thường lệ, tạo điều kiện thay vì chặn.
• Việc áp dụng đám mây được đánh giá từng tải công việc, cân nhắc nơi lưu trữ dữ liệu, khả năng chống chịu, chi phí, tính di động và carbon.
• Nợ kỹ thuật có một người sở hữu có tên và một kế hoạch khắc phục được tài trợ, không chỉ chữa cháy thỉnh thoảng.
• Các hệ thống trùng lặp và lỗi thời được hợp lý hóa, và việc cho nghỉ hưu được cấp nguồn lực với di chuyển dữ liệu, lưu giữ và kiểm tra phụ thuộc.
• Các năng lực mới phơi bày API mở, có phiên bản để các thành phần có thể được thay thế mà không phải xây lại xung quanh.
• Bảo mật được thiết kế vào từ đầu — bề mặt tấn công tối thiểu, đặc quyền tối thiểu, phân đoạn — không gắn thêm trước khi ra mắt.
• Các quyết định xây/mua/cấu hình dựa trên tổng chi phí sở hữu và sự khóa chặt, với quyền rút lui và trích xuất dữ liệu được bảo đảm trước khi ký.

Nguồn chính#

• NHS England — chiến lược đám mây, chuẩn công nghệ và Bộ công cụ Bảo mật và Bảo vệ Dữ liệu.
• Trung tâm An ninh Mạng Quốc gia (NCSC) — các nguyên tắc thiết kế an toàn và hướng dẫn bảo mật đám mây.
• Chính phủ Vương quốc Anh (GDS/CDDO) — Technology Code of Practice và chính sách đám mây trước.
• Văn phòng Kiểm toán Quốc gia — các báo cáo về hệ thống cũ của NHS, cuộc tấn công WannaCry và các chương trình hỗ trợ bởi CNTT.
• The Open Group — TOGAF, khung kiến trúc doanh nghiệp.
• Dịch vụ Số của Chính phủ — khái niệm "nền tảng khả thi mỏng nhất" trong sổ tay dịch vụ GOV.UK và cộng đồng thiết kế.

Tài liệu tham khảo#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual