主题 4.0 — 技术架构、云与遗留系统

在医疗与照护领域,技术架构是一项提前数年做出的临床安全、安全性与公共资金决策:你所建立的平台与你留下的遗留系统,会悄悄决定在做出这些选择的人离开之后很久,照护是否还能保持安全、互联互通、可负担。

为什么这在医疗与照护领域很重要#

架构是你数字服务之下那一套长期存在的结构性选择:什么在哪里运行、组件如何连接、你自建还是购买,以及你从过去保留了什么继续存活。这些选择很少能被患者或临床医生看见,也很少让董事会感到兴奋。然而它们塑造着建立在其上的一切。一片架构良好的资产,能让你快速添加一项新服务、安全地共享数据,并在出问题时迅速恢复。一片架构糟糕的资产,会让每一次变更都缓慢,每一次集成都脆弱,每一次事故都更糟。

在医疗与照护领域,利害关系很高,因为这些系统举足轻重。当一个老化的患者管理系统崩溃时,救护车要改道,门诊要取消。当一个不受支持的操作系统被利用时,保密记录会被暴露,服务会停止——正如 NHS 在 2017 年所了解到的那样,当时 WannaCry 勒索软件攻击通过运行着已无法打补丁软件的机器传播。那次中断不是一次精妙的、有针对性的攻击;它是关键系统中累积的技术债的可预见后果。因此,架构决策就是安全决策,无论是否有人这样界定它们。

它们也是公平与信任决策。无法共享数据的遗留系统,让病情最复杂、涉及最多服务的患者,拥有最碎片化的记录。把你锁定在单一供应商身上的封闭平台,会消耗本可用于资助照护的资金。而公众合理地期望 NHS 运行在现代化、安全、维护良好的技术之上;这种期望与实际资产之间的差距,本身就是对信任的一种风险。

最后,这是大量公共资金被长期投入的地方。一个系统最昂贵的部分很少是它的采购价;而是随之而来的、长达十年的托管、授权、维护与最终替换。把架构当作"技术团队处理的事情"的领导者,正在把机构所做出的一些最大、最持久的财务承诺委托出去。本主题的写作目的,是让你能够在不需要成为工程师的情况下,让这些决策担负起责任。

核心概念#

企业架构是让机构的业务流程、信息、应用与技术保持一致、使其连贯地支持战略,而不是偶然生长的学科。它采取的是整个机构的视角:你需要哪些能力、哪些系统提供它们,以及缺口与重复存在于哪里。解决方案架构是更狭窄的、项目层面的学科,设计一项具体服务将如何被构建、如何融入更广泛的资产之中。两者都处于系统架构这个更宽泛理念之内——关于组件、接口与行为如何组合成一个运作整体的结构模型。领导者不需要亲自实践这些学科,但他们应当坚持要求它们存在,因为它们的缺失,正是资产变得无法管理的原因。

架构由架构原则来指引:一组简短的、商定的陈述——例如"复用优先于购买,购买优先于自建"或"按开放标准构建"——让一致的决策成为可能,而不必把每一个选择都上报升级。原则由一个设计权威机构轻度地强制执行:一个审查重大技术决策的小组。一个健康的设计权威机构是赋能的、而不是阻碍的;它的存在是为了防止可避免的伤害与重复,而不是为了拖慢团队或为了把关而把关。

云计算是通过互联网按需提供计算——服务器、存储、数据库、网络——而不是来自你自己建筑物中拥有的硬件。公有云由第三方提供商运营,由许多客户共享;私有云专属于一个机构;混合云结合了两者,常常把一些工作负载保留在既有基础设施上,同时把另一些迁移出去。包括英国在内的许多政府都采纳了"云优先"政策,意味着团队应当在其他选项之前先考虑公有云,并为不使用它提供理由。因为云是按用量计费、而不是一次性购买的,控制这笔支出已经成为一门独立的学科——FinOps,即把工程与财务结合起来,让团队对自己云端使用的实际成本拥有可见性与问责。在应用层面,软件即服务(SaaS)通过网络交付一个由供应商托管与维护的成品应用,因此你是配置它、而不是运行它。基础设施与托管——你的系统在物理上如何运行、运行在哪里——处于这一切之下,并日益承载着一项理应纳入决策的碳成本(见主题 8.5——可持续性与净零排放)。

一个遗留系统是一个老化但仍被依赖的系统,难以变更,常常运行着不再获得安全补丁的不受支持软件。遗留系统会以技术债的形式累积——过去所做权宜选择的未来成本。少量债务是正常的,甚至是明智的;规模化的未被管理的债务,会变成一项安全与安保负债,因为最多人依赖的系统,变成了没有人敢触碰的系统。管理这一点是应用组合管理的工作:为每一个应用维护一份清晰的清单,记录其成本、状况与业务价值,这样你才能对资产进行合理化——退役、替换或整合系统——并安全地退役,而不是让旧东西悄悄继续运行。

现代资产是靠应用程序编程接口(API)维系在一起的:一个系统向另一个系统提供能力所通过的、明确定义的接口。设计良好的 API 让你能够组装平台——许多团队在其上构建的可复用服务——同时保持组件的松耦合与可替换性。这里一门有用的纪律是"最薄可行平台":只构建真正能减少他人工作量的共享能力,不多不少。支撑安全设计的是设计上的安全原则,即安全从一开始就被构建进去,而不是事后附加。而这一切的财务框架是总拥有成本(TCO):一个系统的全生命周期成本,而不是它的采购价——这是应当用来判断自建/购买/配置选择,以及供应商锁定风险的透镜。

最佳实践#

1. 商定一组简短的架构原则,并用它们来做决策。 写下少数几条清晰、易记的原则——复用优先于购买优先于自建、按开放标准构建、在合理的地方使用云、设计上的安全、为整条照护路径而设计——让团队通过应用它们自行做出大多数决策。原则只有在被真正用来说"是"与"不"时才有效,只有在数量少到能被记住时才有效。这与主题 1.1——运营模式与主题 1.2——数字战略与路线图规划直接相关,它们设定了这些原则所服务的方向。

2. 运行一个赋能、而不是阻碍的设计权威机构。 建立一个小型的、高级的、跨学科的小组,来审查重大技术决策——那些昂贵的、难以逆转的、影响许多服务的,或带有安全与安保风险的决策。给它一条快速、轻量的通道,这样常规选择就不会被拖着经过它,并让它对标一项服务标准:它应当帮助团队找到一个好答案,而不仅仅是拒绝。一个变成瓶颈的设计权威机构会被绕过,而影子架构比没有架构更糟糕。

3. 刻意地采纳云,逐项工作负载地进行,而不是把它当作一句口号。 把"云优先"当作一个需要被推理的默认选项,而不是把一切都搬走的指令。评估每一项工作负载的适用性、数据驻留、韧性、规模化后的成本,以及迁移所需的努力,并诚实地认识到,原封不动地把一个遗留应用直接搬迁上云,常常只是以更高的成本把问题搬了个地方。明确地权衡碳排放维度,因为你托管的地点与方式会影响排放(见主题 8.5——可持续性与净零排放),并为可移植性而设计,这样未来在提供商之间迁移依然是可能的。

4. 维护一份活的应用组合,把技术债当作一项具名风险来管理。 为每一个应用维护一份准确的清单,记录其业务负责人、成本、可支持性,以及它所承载的风险,并定期审查它。把技术债与不受支持的软件放上企业风险登记册,以对待临床或财务风险同等的严肃程度对待它,因为它本质上就是这样的风险。你看不到的东西,你就无法为之提供资金、排定优先级,或安全地退役,而从未被清点过的资产,恰恰就是那些会毫无预警地失效的资产。

5. 合理化资产,安全地退役。 主动退役重复的、过时的、生命周期已尽的系统,而不是让它们"以防万一"而继续存在,因为每一个存活的系统都是一个攻击面、一笔许可成本,以及一项维护负担。退役本身就是一个项目:依据明确的保留规则迁移或归档数据,确认没有什么还依赖这个系统,与用户沟通,并在关闭之前进行验证。做得好,合理化能释放资金并降低风险;做得草率,它会摧毁记录,或破坏一个没有人记录过的依赖关系。

6. 优先选择开放标准、API 与松耦合的组件。 设计能力通过有文档记录的、有版本管理的 API 来暴露,这样一个组件就能在不重建它周围一切的情况下被替换。这是主题 4.3——互操作性与数据标准中所讨论互操作性的架构基础,也是你抵御锁定的主要防线。它比一个直接的、硬连线的连接前期成本略高,但在你第一次需要更换供应商或增加一项服务时,这笔投资会数倍偿还。

7. 构建最薄可行平台,不多不少。 当你为他人在其上构建而创建一个共享平台时,要抵制从第一天起就让它变得面面俱到的冲动。提供真正能为团队消除工作量的、最小的可复用能力,证明它被使用,并依据真实需求来增长它。过度构建的平台会变成它自身的遗留系统——昂贵、僵化、招人怨恨——而一个精简、运行良好的平台会赢得采纳,并随需求演进。

8. 让安全架构与设计上的安全不容商量。 从第一张草图起就把安全思维纳入设计,而不是作为一道发布前的关卡:最小化攻击面、应用最小权限、对网络进行分段,并假设组件会被探测。在医疗与照护领域,这与临床安全和信息治理密不可分(主题 1.6——临床安全与风险管理;主题 1.7——信息治理、数据保护与网络安全),因为一次泄露既是数据伤害,当它让系统停止运作时,也是一起患者安全事件。不受支持、无法打补丁的软件,是你默认在做出的一项安全决策——因此要刻意地做出它,配有缓解措施,或者干脆不这样做。

9. 依据总拥有成本、而不是标价来决定自建、购买或配置。 对于每一项能力,对照自建定制、购买产品,与配置一个既有平台的全生命周期成本——托管、授权、集成、支持、升级与最终退出——而不是初始价格来进行比较。对大宗商品式需求偏向购买或配置,把自建保留给真正具有差异化价值的地方,并权衡每个选项所造成的锁定。与商务同事一起梳理这个问题(主题 6.3——采购与商务),因为确保开放接口与退出权最便宜的时机,是在你签约之前。

10. 把云端支出当作一门共享的工程与财务学科(FinOps)来对待。 通过把云资源标记给负责人,让团队清楚地看到自己服务的成本,依据真实使用情况调整实例规模,并关闭闲置或过度配置的资源,而不是月复一月地为它们付费。让运行一项服务的团队对其运行成本负责,这样最有能力减少浪费的人,正是能看到账单的人。没有这项纪律的按量付费云,会悄悄消耗本应资助照护的预算,而这种漂移很少被注意到,直到一张发票逼出这个问题。

11. 把成本当作一项头等非功能性要求来架构,与碳排放及韧性相权衡。 像对待性能、安全性与可用性那样对待成本:一种你刻意为之设计、在构建之前估算、并随使用增长而审查的属性。明确地权衡它与碳排放(见主题 8.5——可持续性与净零排放)以及韧性,因为这三者往往同步变化——但绝不要为了追求最低账单而牺牲安全性、可恢复性,或患者结果。正确的答案是依然满足你临床安全与韧性义务的最低成本,而不是孤立地选择最便宜的选项。

与团队讨论的问题#

1. 我们哪些关键系统如今是不受支持或无法打补丁的?如果其中一个被攻击或失效,我们实际的暴露程度是什么? 从临床与运营服务真正离不开的系统出发,具体确定哪些运行着不再获得安全更新或供应商支持的软件。追问如果每一个被勒索软件攻击或干脆停止运作,会对患者、员工、数据造成什么影响,恢复需要多久。区分那些你已经有意识地接受了风险、并有缓解措施到位的系统,与那些其脆弱性从未被评估过的系统。考虑这种暴露是否在企业风险登记册上可见,还是被埋没在一份没有任何董事会看过的电子表格里。反思 WannaCry:那次伤害并非来自高深的技术,而是来自关键系统中已知、未被处理的债务。如果你无法用证据回答这个问题,这个缺口本身就是你最紧迫的发现,因为你无法为一项你没有说出名字的风险提供资金。

2. 我们在哪些地方被锁定了?离开我们最大的平台真正需要花费多少代价? 许多机构只有在尝试变更一个封闭系统时才发现它的真实代价。梳理离开你最大的临床或企业平台实际需要什么:你能否以一种可用的、标准的形式提取你的数据,需要解开哪些专有接口,你的合同关于所有权与退出说了什么。考虑"云"是否已经悄悄变成了另一种形式的锁定,数据与工具已经与一个提供商深度纠缠,以至于离开变得不切实际。把这与替代方案的开放性,以及任何你本可以复用的国家平台相权衡。这不是在为频繁更换供应商辩护;而是关于在你下一次谈判之前理解你的筹码,不让一个供应商的路线图悄悄变成你唯一的选择。

3. 我们在维护与合理化既有资产上的投入是否足够,还是只投入在新的、可见的事物上? 新系统吸引资金与关注;打补丁、升级、整合与安全退役这些不光鲜的工作很少能得到关注,而这恰恰是债务累积的方式。追问你的数字预算中,有多大比例真正用于让既有资产保持安全与最新,与用于构建新事物相比,以及是否有人刻意地拥有这种平衡。讨论退役是否曾经获得过恰当的资源配置,还是旧系统仅仅因为关闭它不是任何人的工作而一直存在。考虑机构内重复做同样事情的应用,以及整合它们需要什么。想一想在董事会层面,谁对整个资产的健康、而不仅仅是单个项目负责。一个只资助新事物的机构,是在向自己未来的安全借款,而偿还总是在最糟糕的时刻到期。

4. 我们是否真的知道自己的云成本、谁拥有那张账单,以及支出是否受到控制? 按量付费的云会悄悄消耗本应资助照护的预算,而这种漂移很少被注意到,直到一张发票逼出这个问题。追问云资源是否被标记给拥有它们的团队与服务,是否有人依据真实使用情况调整实例规模,以及闲置或过度配置的资源是否曾经被关闭。讨论运行一项服务的人是否看到并对其运行成本负责,还是云支出作为一条没有人能分解的、无法解释的单一条目落在一个中央预算里。考虑成本是否被当作一项头等非功能性要求来对待——在构建之前估算、随使用增长而审查——还是只在事后才被发现。要诚实地面对工程自主权与财务控制之间的张力,以及权衡成本与碳排放及韧性、而不是仅仅追逐最低账单。一个诚实的答案会说出谁掌握着 FinOps 这门纪律,并展示它确实有效的证据,而不是假设云更便宜是因为它更现代。

5. 当我们需要一项新能力时,我们如何决定自建、购买,还是配置我们已经拥有的东西——依据是什么? 自建定制的本能,或购买演示效果最好的产品,常常在任何人比较过全生命周期成本之前就已经获胜。梳理你最近几项重大选择实际上是如何做出的:托管、授权、集成、支持、升级与最终退出是否被权衡过,还是只考虑了初始价格。追问你是否把自建保留给真正具有差异化价值的地方、默认为大宗商品需求购买或配置,还是定制构建因为某个团队偏好它而悄悄激增。考虑这些决策的房间里有谁——商务与临床同事,而不仅仅是工程师——以及每个选项所造成的锁定是否在签约之前被评估、而不是之后才被发现。反思你的架构原则("复用优先于购买,购买优先于自建")是否真正约束了这些选择,还是被悄悄忽视了。一个诚实的答案能够指出真实的决策,在这些决策中,总拥有成本、而不是标价,改变了结果。

6. 我们是否拥有能够支撑自己决策的内部架构能力,还是依赖于我们本应对其负责的供应商? 架构是最大、最持久承诺被做出的地方,然而许多机构已经掏空了做出这些决策所需的正是这种能力,依赖那些产品正在被评估的供应商来告诉他们什么才是好的。追问你自己这边是否拥有可信的企业与解决方案架构技能,以及你的设计权威机构是配置了人手来赋能团队,还是仅仅走个过场。讨论重大的、难以逆转的决策是否真正对照商定的原则进行了检验,还是被实际上委托给了最接近这个问题的那家供应商。考虑如果你没有独立的专长来质疑,你要如何才能识别出一个糟糕的架构建议。权衡构建并保留这种能力的成本,与它缺失所产生的锁定与返工这一大得多的成本。一个诚实的答案会区分你真正能够拥有的决策,与你目前凭信任接受的决策。

实践中:一个医疗与照护案例#

一家急症医院信托机构的技术资产已经有机地生长了二十年。它的核心是一个运行在一个供应商十八个月前就停止支持的操作系统上的患者管理系统;围绕着它的是两百多个应用,许多是按部门采购的,有几个做着重叠的工作,没有人掌握一份完整的清单。一次未遂事件——一次勒索软件尝试与其说被设计挡住,不如说是被运气挡住——促使董事会问出了一个它从未问过的问题:我们究竟在运行什么,我们的暴露程度有多大?

首席数字信息官抵制住了启动一个单一的、英雄式的"替换一切"项目的本能,先做了枯燥的工作。该信托机构构建了一份活的应用组合:每一个系统、它的业务负责人、它的可支持性、它的成本,以及它的风险。这幅图景令人警醒——五分之一的应用运行在不受支持的软件上,还有十几项重复的能力已经在别处存在——但这是第一次它变得可见,最严重的暴露被直接放上了企业风险登记册,董事会能够看到它们。

从这份清单出发,该信托机构在少数几条商定的架构原则指引下做出了刻意的选择。不受支持的患者管理系统被优先安排替换,作为一个可配置的产品被采购,附带合同性的开放 API 与数据提取权利,这样该信托机构就不会再次被锁定。合适的工作负载被迁移到公有云,逐一评估,而不是套用口号,碳排放与可移植性与成本一并被权衡。一个小型设计权威机构审查重大决策,并快速批准常规决策。十二个重叠的部门应用被整合为三个,退役的系统被妥善退役——数据依明确的保留规则迁移、依赖关系被检查、用户被告知,然后才被关闭。

这一切都没有登上头条。但十八个月后,该信托机构知道自己在运行什么,它最危险的债务正依据一份获得资助的计划被偿还,而不是被寄希望于消失,一次新的共享照护记录集成在数周内就完成了交付,因为替换系统暴露了开放的 API。这次未遂事件,成为了该信托机构开始管理自己架构、而不是被它所管理的那一刻。

行业视角#

初创企业#

一家数字医疗初创企业拥有几乎没有遗留系统的奢侈,应当坚决地保护这一点。从一开始就采用云原生构建,暴露开放 API,把设计上的安全当作核心功能、而不是后期成本来对待,因为审慎的 NHS 买家会仔细审视你的安全架构与数据提取条款。让你自己的最薄可行平台真正保持精简,抵制为你尚不具备的规模而过度设计的诱惑。你积累致命技术债最快的路径,是在投资者压力下发布权宜的代码、却从不偿还它,因此要对你所承担的债务做出刻意、可见的选择。矛盾的是,设计得让客户能够提取自己的数据并离开,正是赢得让他们留下的信任的关键。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院、一家单一场所的诊所,或一家已过初创阶段的小型健康科技供应商——承担着与大型信托机构同样的职责,却只有零头的资源,通常没有任何专门的 IT 能力。这里的架构主要是善于采购的学科:偏向信誉良好的软件即服务,让供应商承担你自己无法配置人手去处理的托管、打补丁与安全工作,并在签约前仔细阅读合同中关于数据提取与退出权利的条款,因为当你没有筹码时,锁定咬得最痛。为你所依赖的少数几个系统保持一份简单的清单,知道哪些依然受支持,因为即使一片小型资产也可能藏着一台会让诊所停摆的未打补丁机器。坚持要求供应商满足诸如数据安全与保护工具包这样公认的标准,而不是试图从零开始评估安全性。当现金紧张时,诱惑是让一个旧的、不受支持的系统继续运行以避免一笔账单,但这是一项你应当刻意做出、而不是随波逐流的安全决策。

大型企业#

一家大型信托机构或供应商承载着数十年累积的系统,无法简单地从头开始。现实的策略是有纪律的演进:维护一份活的组合,在必须保留的东西前面加上开放的、基于 API 的层,并依据一份获得资助的、有优先级的计划,而不是靠偶尔的恐慌,来偿还最危险的债务。运行一个因为赋能交付而受到尊重、而不是因为阻碍交付而被畏惧的设计权威机构,并让技术债成为一项由具名负责人负责的、常设的董事会级别风险。在每一次续约时都要警惕锁定,并把退役当作真实的、有资源支持的工作,而不是事后补充。这与主题 5.4——企业资源规划(ERP)中治理核心运营平台的复用与开放接口纪律是同一套。

政府机构#

国家与区域机构设定了整个行业运作的条件,它们的架构选择会向外波及。政府能做的最有价值的事情,是强制要求开放标准、提供可复用的国家平台以便地方机构只需构建一次,并设定能够在各处提高底线的云、安全与可持续性期望。至关重要的是,政府必须为那些不光彩的国家级工作——遗留系统整改、术语维护、退役支持——提供资金,因为没有哪个单一机构会独自为此出资,但每个人都依赖它。一个被坚定强制执行、被广泛复用的"足够好"的标准,胜过一个理论上更优、却被不一致地实施的标准。这种管理者角色,与主题 9.1——与地方及中央政府合作,以及主题 9.0——与合作伙伴组织协作中合作伙伴如何协作相关联。

常见失败模式#

• 不可见的资产。 运行着数百个应用,却没有准确的清单,因此暴露程度未知,重复未被注意到,脆弱性的第一个迹象是一次中断或一次泄露。
• 对董事会隐藏的债务。 把不受支持的软件与技术债当作一个技术脚注、而不是一项具名的企业风险来对待,因此它直到失效之前从未获得资助。
• 把云当作口号。 出于原则,把未经改变的遗留系统原封不动地搬迁上公有云,以更高的成本把问题搬了个地方,或把数据与工具与一个提供商纠缠得太深,以至于变成一种新的锁定。
• 设计权威机构变成瓶颈。 让架构治理变成一道团队会绕过的缓慢关卡,产生比没有架构更糟糕的、未经记录的影子架构。
• 该配置时却自建。 为大宗商品需求选择定制构建,依据标价而不是总拥有成本,继承了一个你没有预算的、长达十年的维护负担。
• 从不退役。 让过时的系统"以防万一"而继续运行,每一个都是一个没有人负责的攻击面、许可成本与维护负担。
• 安全性事后附加。 把安全性当作一道发布前的关卡、而不是一项设计输入来对待,导致攻击面早在任何人评估它之前就已经形成。
• 默认的锁定。 签约没有开放接口或数据提取权利的平台,直到你尝试离开时才发现这个陷阱的代价。

成熟度模型#

检查清单#

• 一份活的应用组合记录了每个系统的负责人、成本、可支持性与风险,并被定期审查。
• 不受支持与无法打补丁的关键系统被识别,并列在企业风险登记册上,而不是一份技术电子表格里。
• 一组简短的、商定的架构原则被真正用来做出并证明决策的合理性。
• 一个设计权威机构审查重大的、难以逆转的决策,并快速批准常规决策,发挥赋能而不是阻碍的作用。
• 云的采纳逐项工作负载地被评估,权衡驻留、韧性、成本、可移植性与碳排放。
• 技术债有一位具名负责人与一份获得资助的整改计划,而不仅仅是偶尔的救火。
• 重复与过时的系统被合理化,退役配备了数据迁移、保留与依赖关系检查方面的资源。
• 新能力暴露开放的、有版本管理的 API,让组件能够在不重建其周围环境的情况下被替换。
• 安全性从一开始就被设计进去——最小攻击面、最小权限、分段——而不是在发布前才附加上去。
• 自建/购买/配置的决策依据总拥有成本与锁定情况来做出,退出与数据提取权利在签约前就已确保。

关键来源#

• NHS England ——云战略、技术标准与数据安全与保护工具包。
• 国家网络安全中心(NCSC)——安全设计原则与云安全指导。
• 英国政府(GDS/CDDO)——技术实践准则与云优先政策。
• 国家审计署 ——关于 NHS 遗留系统、WannaCry 攻击,以及 IT 支持项目的报告。
• The Open Group ——TOGAF,企业架构框架。
• 政府数字服务 ——GOV.UK 服务手册与设计社区中的"最薄可行平台"概念。

参考文献#

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