過去二十年の大半において、エンタープライズのデリバリーで希少な資源は、そもそも構築できる能力そのものでした。チームは遅く、環境は手作業で、リリースは一大イベントでした。当時のアーキテクチャの労力は、デリバリーの障害を取り除くことに注がれました。モノリスの分解、クラウドの採用、継続的インテグレーションへの移行、そしてチームが自らのサービスを端から端まで所有する自律性の付与です。その取り組みはおおむね成功しました。今日において希少な資源は、もはや構築できる能力ではありません。それは一貫して構築する能力であり、数十の自律したチームが生み出すものが、寄せ集めではなく一つのシステムとして組み合わさるようにすることなのです。

この転換が重要なのは、コストの所在が移動したからです。一つのチームが遅く構築していたとき、そのコストは局所的で目に見えるものでした。四十のチームが速く、かつ発散的に構築するとき、そのコストはシステム全体に及び、かつ先送りされます。それは統合税として、機能の重複として、セキュリティ例外として、そしてアイデンティティやオブザーバビリティといった共有関心事を、あらゆるサービスに手作業で触れずには変更できないという形で表面化します。こうしたものはいずれも、個々のチームのボード上には現れません。それはチームとチームの間の空間に蓄積されます。そしてそこは、まさにどのチームも責任を負わない場所なのです。

二つの力がこの状況を先鋭化させました。第一は組織的なものです。デリバリーを拡大する手法として広まったチーム・オブ・チームズのモデルは、中央調整者を意図的に排除します。自律性こそがその狙いであり、守るに値するものです。第二は技術的なものです。クラウドとプラットフォームの経済性は標準化を強く報奨します。なぜなら、皆が従うパターンは一度だけ自動化し、セキュアにし、運用できるのに対し、個別最適な選択は永遠に抱え続けなければならないからです。良質なデフォルトを供給できない組織は、コストなしに自律性を得ることはできません。得られるのは発散であり、その代償はその後の四半期ごとに支払われるのです。

リファレンスアーキテクチャは、しばしば単一の成果物、たいていは一枚の図として扱われます。しかしそれは、抽象度と拘束の仕方において異なるアーキテクチャ資産のスペクトラム上の一点として捉えるほうが有用です。このスペクトラム全体を理解することこそが、組織が特定の意思決定に対して、毎回文書に手を伸ばすのではなく、適切な道具を選べるようにするのです。

最も抽象的な端に位置するのが原則です。これは、なぜ組織がある種の解を別のものより好むのかを説明する、恒久的な意図の表明です。自己運用のインフラよりもマネージドサービスを優先せよ、といった原則は、何を構築すべきかを誰にも指示しませんが、許容される答えの空間を制約します。原則の下位に位置するのがパターンです。これは、繰り返し生じる問題に対する、名前を持ち再利用可能な解であり、チームがそのパターンの適用場面を認識し適応させられるだけの文脈とともに記述されます。パターンは強制ではなく、デフォルトとして提供される、蓄積された経験なのです。

リファレンスアーキテクチャは、より大きな構成物です。それは、イベント駆動の統合バックボーンや標準的な顧客向けWebアプリケーションといった、問題領域全体を解決する、意見を持ったパターン、技術、インターフェースの配置です。それは構造については規範的である一方、実装は開かれたままにします。標準は、独立した実装が相互運用できるようにする、狭く検証可能な取り決めです。すなわちアイデンティティのプロトコル、ログのスキーマ、API のスタイル、タグ付けの規約です。標準こそが、一貫性が実際に強制される場所です。なぜなら、それは検証できるほど具体的だからです。

具体的な端に位置するのがガードレールです。これは原則、標準、パターンを実行可能な形で表現したものであり、安全な経路がデフォルトとなり、危険な経路が自動的にブロックまたはフラグされるように符号化されています。このスペクトラム全体を通じて決定的に重要な区別は、意思決定に情報を与える資産と、意思決定を制約する資産との間にあります。どちらも正当です。問題が始まるのは、組織がすべてを情報提供的な散文として書き、そのうえでなぜ何も収束しないのかと不思議がるとき、あるいはすべてを厳格なブロックとして書き、そのうえでなぜチームがプラットフォームを迂回するのかと不思議がるときです。

ここ数年の目に見える潮流は、アーキテクチャ資産とその利用との間の距離が消滅していることです。共有ドライブの中にスライド資料として存在し、稀にしか参照されず、選択的にしか従われなかったリファレンスアーキテクチャは、舗装された道へと置き換わりつつあります。すなわち、テンプレートから始め、パイプラインを実行し、文書を一切読むことなく準拠したベースラインを継承することで、チームが採用できるデフォルト群です。資産は、告げられるものから、その上に構築するものへと移行したのです。

プラットフォームエンジニアリングは、これが取る組織的な形態です。社内プラットフォームチームは、ゴールデンパスを製品として扱い、デリバリーチームをその顧客とし、公開ではなく採用によって自らを評価します。この捉え直しは、聞こえる以上に重大です。文書は書き終えれば完成します。しかし製品は決して完成しません。なぜなら、チームが自前で行うという代替案に対して、その利用を絶えず勝ち取り続けなければならないからです。その圧力こそが、リファレンスアーキテクチャを誠実に保つものなのです。

これと並行して、policy-as-code はガバナンスをレビュー会議からパイプラインへと移しました。許可されたリージョン、必須の暗号化、必須のタグ、承認済みのベースイメージに関する規則がコードとして表現され、plan または deploy の時点で自動的に評価されます。同じ本能が、アーキテクチャのフィットネス関数を生み出します。これは、層と層の間の禁止された依存関係や、標準的なヘルスエンドポイントの存在といった構造的性質を主張する自動テストであり、アーキテクチャの意図が、たまに検査されるのではなく継続的に検証されるようにします。architecture-as-code と、バージョン管理され機械可読なモデルが、この全体像を完成させます。標準は単に記述されるだけでなく、他のシステムが取り込み、そこから生成し、それに照らして検証できる定義となるのです。進む方向は一貫しています。一貫性は左へとシフトされ、レビュー委員会の外へ、そしてチームが既に使っているツールの中へと移されつつあります。そこでは準拠に追加のコストがかからないのです。

共有資産が実際に再利用されるかどうかは、その技術的品質よりも、資産そのものに関するわずかな設計上の選択にかかっています。第一は、デフォルトが代替案よりも真に容易でなければならないということです。チームが自ら見つけ、解釈し、手作業で組み立てなければならないパターンは、チーム自身の判断と対等の条件で競合し、そしてたいてい判断のほうが勝ちます。動作するテンプレートとして提供され、パイプラインに組み込まれ、デフォルトでセキュアなパターンは、競合しません。それは単に最も抵抗の少ない経路となるのです。再利用は、正しさに従うよりもはるかに確実に、利便性に従います。

第二の原則は、ガードレールは結果を制約すべきであり、あらゆる手順を規定すべきではないということです。有用な取り決めは、すべてのサービスが標準的なアイデンティティプロバイダーを通じて認証を公開するということであって、すべてのサービスが一つのフレームワークで書かれるということではありません。細部まで指図しすぎるゴールデンパスは脆くなり、チームが正当に異なるニーズを持った瞬間に放棄されます。技術とは、パターンの境界を明示し、チームがどこで従わねばならず、どこで自由なのかを正確に把握できるようにすること、そして逸脱が起きないふりをするのではなく、逸脱のための認可された方法を設計することにあります。

第三の原則は、バージョン管理と進化を第一級の関心事として扱うことです。リファレンスアーキテクチャは現在についての主張であり、それは十八か月後には誤りになっているでしょう。もしそれが他のあらゆる依存関係と同様にバージョン管理され、廃止され、移行されえないなら、それは硬直化します。そしてチームはそれを無視することを学びます。なぜなら、それに従うことは、組織自身がもはや信じていない意思決定を継承することを意味するからです。第四の原則は、あらゆる標準が、その強制のコストを自ら負うということです。誰も検証しない標準は助言であり、助言は大規模における一貫性を生み出しません。提案されたいかなる標準についても問うべきは、それが正しいかどうかではなく、それが検証可能かどうか、そして誰がその検証を実行するのかということです。自動化された答えがないなら、その標準は願望であり、統制と取り違えられるのではなく、そのように明記されるべきなのです。

共有資産のプログラムは、見分けのつく形で失敗します。そして、その失敗モードに名前を付けることが、それらを避けるための最短の道です。象牙の塔。アーキテクトが、その中で生きねばならないチームから隔絶して、リファレンスの全体像を定義します。その成果物は内部的には優美でありながら、実務上は使い物になりません。なぜなら、それが実際のデリバリー制約に対して一度も圧力試験されなかったからです。その兆候は、採用率がほぼゼロの美しいカタログであり、その診断は、資産が共同設計されたのではなく公開されたということです。

金メッキされたデフォルト。舗装された道は存在するものの、自前で行うよりも重く、遅く、あるいは制約が多いため、有能なチームはひそかに自らの道を築き、ゴールデンパスは脱出する技量を欠く者にのみ役立ちます。これは最も危険な失敗です。なぜなら、部分的な成功のように見えながら、能動的に誤った採用者を選別しているからです。最も弱いチームだけが使うゴールデンパスは、標準ではありません。それは補習コースなのです。

考古学としての標準。wiki には四十の標準があり、その半分は互いに矛盾し、三分の一はもはや使われていない技術を記述し、そのどれにも日付も所有者もありません。チームは、生きた指針と堆積物とを見分けられないため、それらすべてを任意のものとして扱うのももっともなことです。純然たる障害物としてのガードレール。ガバナンスがブロックとしてのみ表現され、舗装された代替案が一切提供されないため、そのガードレールはチームに対し、アーキテクチャを「否定の部門」とみなし、その創意工夫を迂回に投じるよう教えます。支援された前進の経路を伴わないブロックは、全体像の水準を高めるのではなく、回避策の水準を高めます。バージョン管理されない真実。リファレンスアーキテクチャが時代を超越したものとして扱われ、決して廃止されないため、それは組織が実際に推奨するものから徐々に乖離し、ついにはそれに忠実に従うこと自体が誤りとなります。これらの失敗はいずれも、一つの根を共有しています。すなわち、資産が、忙しいチームが合理的に使おうと選ぶものとしてではなく、正しさの表明として最適化されたということです。

Nashua は、リファレンスアーキテクチャと標準を、ガバナンスの問題ではなく供給の問題として捉え、エンゲージメントもそれに応じて形づくられます。私たちはまず、目標とする図が主張するとおりではなく、実際にあるがままの全体像を地図化することから始めます。すなわち、チームがどこで指示されずとも既に収束しているか、どこで、そしてどれほどのコストで発散しているか、そしてどの繰り返し生じる問題が何度も一から解かれているか、です。その発散の地図こそが真のバックログです。なぜなら、それは共有デフォルトを構築する労力がどこで報われるか、そして標準化がどこでは繰り返さない問題に儀式を加えるだけになるかを、正確に示すからです。

その地図から、私たちはデリバリーチームを迂回するのではなく、彼らとともに、捉える価値のあるパターンを蒸留します。パターンがカタログに名を連ねる資格を得るのは、それが実際のチームの実際の問題を解決したときだけであり、これが象牙の塔を寄せ付けず、最初の採用者が徴集兵ではなく提唱者であることを保証します。私たちは、各資産が原則からガードレールへと至るスペクトラム上のどこに位置するか、そしてそれがどう拘束するかについて意図的です。すなわち、何が真に必須で自動的に強制されるのか、何が逸脱への認可された経路を伴う強いデフォルトなのか、そして何が義務を伴わずに提供される単なる指針なのか、です。これらを混同することは、反感とドリフトの双方の最も一般的な原因であり、それらを明確に分離することが価値の大部分を占めます。

そして私たちは、デフォルトを容易な経路にします。それは、テンプレート、パイプライン統合、policy-as-code、フィットネス関数に投資することを意味します。パターンの採用が、それについて読むことではなく、舗装された道から始めることの問題となり、準拠がゲートでではなく継続的に検証されるようにするためです。全体を通じて、私たちは資産を、所有者、バージョン、そして廃止の規律を伴う製品として扱い、私たちが去った後もカタログを生き続けさせる運用モデルを引き渡します。私たちが自らに課す尺度は、標準がいくつ存在するかではなく、そのうちいくつがデフォルトで従われているか、そしてその結果として統合税がどれほど下がったか、です。

Nashua がもたらす違いは、リファレンスアーキテクチャを文書化の作業として扱うことへの拒絶です。多くの企業は、見栄えのするパターンのカタログと一連の標準を作成し、それを提示し、去っていきます。カタログは成果ではありません。成果とは、独立したチームが中央のボトルネックなしに一貫して構築する全体像であり、その成果は、資産が無視するよりも従うほうが安価かどうかに完全に依存します。私たちはエンゲージメントをそのより厳しい基準に照らして保ち、何を標準化すべきかを決めるアーキテクチャ上の判断力と、それらの標準を願望ではなく実行可能にするプラットフォームエンジニアリングの能力の双方をもたらします。

また、作業が何を前提としてよいかを変える実務上の帰結もあります。エンゲージメントがまだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platform は、エージェンティック・エンジニアリングを通じて、ほぼあらゆる機能を迅速に取り込めるように構築されています。必要なものが平易な言葉で記述され素早く生成されますが、それは常に堅固なアーキテクチャ原則の内で、かつ厳格な品質保証のもとで行われます。そのため、スピードが一貫性、セキュリティ、統制を犠牲にすることは決してありません。その効果は、単に便利であるだけでなく戦略的です。それは内製か購入かの線引きを動かし、選択肢を安価に保ち、戦略が棚にたまたまあったものに合わせて曲げられるのではなく、アーキテクチャが戦略に従うことを可能にします。

この違いを持続させるのは、私たちが成果物ではなく運用モデルで考えることです。バージョン管理されないリファレンスアーキテクチャは劣化します。強制されない標準は助言です。製品として維持されないゴールデンパスは、より良い局所的な選択肢が現れた瞬間に放棄されます。私たちは、共有資産が初期の作業が終わった後もずっとその利用を勝ち取り続けるようにする、所有権、進化の規律、そして自動化された準拠検証を構築します。そして成功を、カタログの大きさではなく、統合コストの低下とデフォルト採用の上昇によって測ります。大規模における一貫性の価値は、すべてのチームが同じことをすることにあるのではありません。それは、組織が苦労して勝ち取った各意思決定を一度だけ捉え、それを何度も費やすこと、そして自律性と一貫性がトレードオフであることをやめ、同じ舗装された道になることにあるのです。