トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステム

医療・ケアでは、技術アーキテクチャは、何年も前に下される、臨床安全、セキュリティ、公費に関わる決定です。立ち上げるプラットフォームと、そのまま残すレガシーは、それらを選んだ人々が去ったずっと後も、ケアが安全で、つながり、手頃なものであり続けられるかを、静かに決めます。

医療・ケアにおいてなぜ重要か#

アーキテクチャとは、デジタルサービスの下にある、長寿の構造的な選択の集合です。何がどこで動き、部品がどうつながり、何を作り何を購入し、過去から何を生かし続けるか。これらの選択は、患者や臨床家にはめったに見えず、取締役会にとってもめったに刺激的ではありません。それでも、その上にあるすべてを形づくります。よく設計された環境は、新しいサービスを素早く追加し、データを安全に共有し、何かが壊れたときに速く回復できます。不出来に設計された環境は、あらゆる変更を遅くし、あらゆる連携を脆くし、あらゆるインシデントを悪化させます。

医療・ケアでは、システムが重大な結果を伴うため、利害は高いものです。老朽化した患者管理システムが倒れれば、救急車は迂回し、クリニックは中止されます。サポート切れのオペレーティングシステムが悪用されれば、機密記録が露出し、サービスが止まります。NHSは、2017年にWannaCryランサムウェア攻撃が、もはやパッチが提供されないソフトウェアを動かしているマシンを通じて広がったときに、それを学びました。その混乱は、巧妙で標的を絞った攻撃ではなく、重要なシステムに蓄積した技術的負債の、予測可能な帰結でした。したがって、アーキテクチャの決定は、誰がそう枠づけるかにかかわらず、安全の決定です。

それらは、公平性と信頼の決定でもあります。データを共有できないレガシーシステムは、最も複雑な患者、つまり多くのサービスに触れる人々に、最も断片化した記録を残します。単一のサプライヤーにロックインするクローズドなプラットフォームは、ケアの資金になりえたお金を流出させます。そして国民は、NHSが現代的で、安全で、よく保守された技術で動くことを当然期待しており、その期待と実際の環境とのギャップは、それ自体が信頼へのリスクです。

最後に、ここは、多額の公費が、非常に長い期間にわたってコミットされる場所です。システムの最も高価な部分は、その購入であることはまれで、それに続く10年間のホスティング、ライセンス、保守、そして最終的な置き換えです。アーキテクチャを「技術チームが扱うこと」として扱うリーダーは、組織が行う最大かつ最長の財務的コミットメントの一部を委任しています。本トピックは、エンジニアでなくても、それらの決定に説明責任を求められるよう書かれています。

中核概念#

エンタープライズアーキテクチャは、組織の業務プロセス、情報、アプリケーション、技術を、偶然に成長するのではなく、戦略を一貫して支えるよう整合させる規律です。組織全体の視点をとります。どのケイパビリティが必要で、どのシステムがそれを提供し、ギャップと重複はどこにあるか。ソリューションアーキテクチャは、特定のサービスがどう構築され、より広い環境にどう収まるかを設計する、より狭いプロジェクトレベルの規律です。どちらも、部品、インターフェース、振る舞いがどう組み合わさって動く全体になるかの構造モデルである、より広いシステムアーキテクチャの考え方の中にあります。リーダーは、これらの規律を実践する必要はありませんが、それらが存在することにこだわるべきです。その不在が、環境を管理不能にする仕方だからです。

アーキテクチャは、アーキテクチャ原則によって導かれます。「購入の前に再利用、構築の前に購入」や「オープン標準で構築する」のような、短く合意された一連の言明で、あらゆる選択がエスカレーションされなくても、一貫した決定を可能にします。原則は、設計権限者（デザインオーソリティ）、つまり重要な技術的決定をレビューする小さなグループによって、軽く徹底されます。健全なデザインオーソリティは、妨げるのではなく可能にします。避けられる害と重複を防ぐために存在し、チームを遅くしたり、それ自体のために門番を務めたりするためではありません。

クラウドコンピューティングは、自分の建物にある所有するハードウェアからではなく、コンピューティング、つまりサーバー、ストレージ、データベース、ネットワークを、インターネットを通じたオンデマンドのサービスとして提供することです。パブリッククラウドは、サードパーティのプロバイダーが運営し、多くの顧客が共有します。プライベートクラウドは、一つの組織専用で、ハイブリッドクラウドは、両者を組み合わせ、多くは一部のワークロードを既存のインフラに残しながら、ほかを外へ移します。英国を含む多くの政府が、「クラウドファースト」の方針を採用しており、チームは、他の選択肢より前にパブリッククラウドを検討し、使わない場合は正当化すべきであることを意味します。クラウドは、一度購入するのではなく、消費量で請求されるため、その支出を管理することが独自の規律、つまり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. 自分たちの決定に責任を持つだけの社内のアーキテクチャ能力があるか。それとも、説明責任を問うべきサプライヤーに依存していないか。 アーキテクチャは、最大かつ最長のコミットメントが下される場所ですが、多くの組織は、それらを適切に下すのに必要な能力そのものを空洞化させ、評価されている製品のベンダーに、何が良いかを教えてもらっています。自分の側に、信頼できるエンタープライズとソリューションのアーキテクチャのスキルがあるか、デザインオーソリティが、チームを可能にするために人員配置されているのか、単に判を押すだけなのかを問ってください。重要で元に戻しにくい決定が、合意された原則に対して本当にテストされているのか、問題に最も近いサプライヤーに事実上委任されているのかを議論します。悪いアーキテクチャの推奨に異議を唱える独立した専門性がなければ、そもそもそれを見分けられるかを考えます。この能力を築き維持するコストを、その不在が生むロックインと手戻りの、はるかに大きなコストと比較してください。誠実な答えは、本当に自分たちが所有できる決定と、いま信用に基づいて取っている決定を区別します。

実践例：医療・ケアの事例#

ある急性期病院トラストの技術環境は、20年にわたり有機的に成長してきました。その中心には、ベンダーが18か月前にサポートを終えたオペレーティングシステムで動く、患者管理システムがあります。その周りには200を超えるアプリケーションがあり、その多くは部門ごとに購入され、いくつかは重複した役割を果たし、完全な一覧を持つ人は誰もいません。ヒヤリハット、つまり設計よりも運によって阻止されたランサムウェアの試みが、取締役会に、これまで一度も尋ねなかった問いを促します。私たちは正確に何を動かしていて、どれだけ危険に晒されているのか。

最高デジタル情報責任者は、単一の英雄的な「すべてを置き換える」プログラムを立ち上げたい本能に抵抗し、まず退屈な仕事を行います。トラストは、稼働中のアプリケーションポートフォリオを作ります。すべてのシステム、その事業上の所有者、サポートの可否、コスト、リスク。全体像は身の引き締まるものです。アプリケーションの5分の1がサポート切れのソフトウェアで動き、十数件が、ほかですでに利用可能なケイパビリティを重複させています。しかし初めて、それが見えるようになり、最悪のリスクへの露出は、取締役会が見られる企業のリスク登録簿に直行します。

そのインベントリから、トラストは、合意された少数のアーキテクチャ原則に導かれて、意図的な選択を行います。サポート切れの患者管理システムは置き換えが優先され、トラストが再びロックインされないよう、契約上のオープンAPIとデータ抽出の権利を伴う、設定可能な製品として調達されます。適したワークロードは、スローガンではなく一つずつ評価され、炭素と移植性がコストと並べて比較考量されたうえで、パブリッククラウドに移行します。小さなデザインオーソリティが、重要な決定をレビューし、日常のものは素早く通します。重複する12の部門のアプリケーションは3つに統合され、廃止されるシステムは、明確な保存ルールの下でのデータの移行、依存関係の確認、ユーザーへの通知を経て、それから初めて停止される形で、適切に廃止されます。

これらのどれも、見出しにはなりません。しかし18か月後、トラストは自分たちが何を動かしているかを知っており、最も危険な負債は、願うのではなく資金の付いた計画で返済されており、新しい共有ケア記録の連携は、置き換えたシステムがオープンAPIを提供しているため、数週間で提供されます。ヒヤリハットが、トラストがアーキテクチャに管理されるのではなく、管理し始める瞬間になったのです。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップには、レガシーがほとんどないという贅沢があり、それを猛烈に守るべきです。最初からクラウドネイティブで構築し、オープンなAPIを提供し、セキュア・バイ・デザインを、後のコストではなく中核的な機能として扱います。慎重なNHSの購入者が、あなたのセキュリティアーキテクチャとデータ抽出の条件を、綿密に精査するからです。自前の実用最小限のプラットフォームを、本当に薄く保ち、まだ持っていない規模のために作り込みすぎる誘惑に抵抗してください。身動きを封じる技術的負債を蓄積する最も速い道は、投資家のプレッシャーの下で便宜的なコードを出荷し、決して返済しないことなので、どんな負債を負うかについて、意図的で目に見える選択をしてください。逆説的ですが、顧客がデータを取り出して去れるよう設計することこそが、顧客を留める信頼を得ます。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニック、スタートアップ段階を過ぎた小規模なヘルステックのサプライヤーは、大きなトラストと同じ義務を、その何分の一かの資源で負っており、専任のIT能力はほとんどありません。ここでのアーキテクチャは、主に、うまく買う規律です。ホスティング、パッチ適用、セキュリティを、自分では人員を配置できない形でサプライヤーが担ってくれる、評判のよいSaaSを優先し、署名の前に、データ抽出と撤退の権利について契約を読んでください。ロックインは、交渉力がないときに最も強く噛みつくからです。頼っている少数のシステムの簡単なインベントリを保ち、どれがまだサポートされているかを知ってください。小さな環境でも、診療所を止める、パッチの当たっていないマシンが隠れていることがあるからです。セキュリティをゼロから評価しようとするのではなく、サプライヤーが、Data Security and Protection Toolkitのような認められた標準を満たすことを求めます。資金が乏しいとき、請求書を避けるために、古いサポート切れのシステムを動かし続けたくなりますが、それは、なりゆきではなく意図的に下すべき安全の決定です。

大企業#

大規模なトラストやサプライヤーは、数十年にわたり蓄積したシステムを抱えており、単純にやり直すことはできません。現実的な戦略は、規律ある進化です。稼働中のポートフォリオを維持し、残さなければならないものの前に、オープンなAPIベースの層を置き、最も危険な負債を、時折のパニックではなく、資金の付いた優先順位づけされた計画で返済します。デザインオーソリティを、デリバリーを妨げるから恐れられるのではなく、可能にするから尊重される形で運営し、技術的負債を、名前付きの所有者を置いた、取締役会レベルの常設のリスクにしてください。更新のたびにロックインに備え、廃止を、後回しではなく、資源を与えられた本物の仕事として扱います。これは、トピック5.4 — Enterprise Resource Planning (ERP)で中核となる業務プラットフォームを統べる、再利用とオープンなインターフェースの規律と同じものです。

政府#

国や地域の機関は、セクター全体が動く条件を定め、そのアーキテクチャの選択は外へ波及します。政府にできる最も価値のあることは、オープン標準を義務づけ、地域の組織が一度だけ構築すればよいよう、再利用可能な国のプラットフォームを提供し、あらゆる場所で床を引き上げる、クラウド、セキュリティ、持続可能性への期待を定めることです。決定的に、政府は、レガシーの是正、用語の保守、廃止の支援といった、どの単一の組織も単独では資金を出さないが、全員が依存する地味な国の仕事に、資金を出さなければなりません。広く再利用される、固く徹底された、十分に良い標準は、理論的に優れているが一貫性なく実装される標準に勝ります。この管理の役割は、トピック9.1 — 地方政府・中央政府との協働と、トピック9.0 — パートナー組織との協働でパートナーがどう協働するかに結びつきます。

よくある失敗パターン#

• 見えない環境。 正確なインベントリなしに何百ものアプリケーションを動かし、リスクへの露出が不明で、重複が気づかれず、脆さの最初の兆候が、停止か侵害になる。
• 取締役会から隠された負債。 サポート切れのソフトウェアと技術的負債を、名前付きの企業リスクではなく技術的な脚注として保ち、失敗するまで資金が出ない。
• スローガンとしてのクラウド。 原則として、変更のないレガシーをパブリッククラウドへリフト・アンド・シフトし、より高いコストで問題を移す、あるいはデータとツールを一つのプロバイダーに深く絡めて、新たなロックインになる。
• ボトルネックとしてのデザインオーソリティ。 アーキテクチャのガバナンスが、チームが迂回する遅い関門になり、何もないよりも悪い、文書化されていない影のアーキテクチャを生む。
• 設定すべきところで構築する。 コモディティなニーズに、総所有コストではなく定価に基づいて特注の構築を選び、予算を組んでいなかった10年分の保守を引き継ぐ。
• 決して廃止しない。 時代遅れのシステムを「念のため」動かし続け、その一つ一つが、攻撃面、ライセンスのコスト、誰も所有しない保守の負担になる。
• 後付けのセキュリティ。 セキュリティを設計への入力ではなくローンチ前の関門として扱い、誰かが評価するずっと前に、攻撃面が決まってしまう。
• 既定でのロックイン。 オープンなインターフェースやデータ抽出の権利なしにプラットフォームに署名し、離れようとして初めて罠の代償を発見する。

成熟度モデル#

チェックリスト#

• 稼働中のアプリケーションポートフォリオが、すべてのシステムの所有者、コスト、サポートの可否、リスクを記録し、定期的にレビューされている。
• サポート切れでパッチの当てられない重要システムが特定され、技術的な表計算ではなく、企業のリスク登録簿に載っている。
• 短く合意されたアーキテクチャ原則が、決定を下し正当化するために実際に使われている。
• デザインオーソリティが、重要で元に戻しにくい決定をレビューし、日常のものは素早く通し、妨げるのではなく可能にしている。
• クラウドの採用が、データの所在、レジリエンス、コスト、移植性、炭素を比較考量して、ワークロードごとに評価されている。
• 技術的負債に名前付きの所有者と資金の付いた是正計画があり、時折の火消しだけではない。
• 重複し時代遅れのシステムが合理化され、廃止に、データの移行、保存、依存関係の確認の資源が割り当てられている。
• 新しいケイパビリティが、オープンでバージョン管理されたAPIを提供し、その周りを作り直さずに部品を置き換えられる。
• セキュリティが、最初から、つまり最小の攻撃面、最小権限、分割を備えて設計され、ローンチ前に付け足されていない。
• 構築/購入/設定の決定が、総所有コストとロックインに基づいて下され、署名前に撤退とデータ抽出の権利が確保されている。

主要な情報源#

• NHS England — クラウド戦略、技術標準、Data Security and Protection Toolkit。
• National Cyber Security Centre (NCSC) — 安全な設計の原則とクラウドセキュリティのガイダンス。
• 英国政府（GDS/CDDO）— Technology Code of Practiceとクラウドファーストの方針。
• National Audit Office — NHSのレガシーシステム、WannaCry攻撃、IT主導のプログラムについての報告書。
• The Open Group — エンタープライズアーキテクチャのフレームワークTOGAF。
• Government Digital Service — 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