エンタープライズアーキテクチャに投資してきた大半の組織は、やがて同じ居心地の悪いギャップに気づきます。参照アーキテクチャ、原則カタログ、技術標準、そして目標オペレーティングモデルを備えていながら、そのほとんどを無視しているように見えるデリバリーポートフォリオもまた抱えているのです。それらの成果物が誤っているわけではありません。単に、どのデリバリーチームも直接行動に移せない抽象度で提示されているにすぎません。コモディティ機能については構築より購入を優先するといった原則は、目の前にある特定のSaaS製品がこの特定のプロセスのデータ所在地制約を満たすかどうかを、プロジェクトチームに教えてはくれません。エンタープライズの視点は、プロジェクトが問うていない問いに答え、プロジェクトがこのスプリントで答えなければならない問いには沈黙を守ります。

ソリューションアーキテクチャは、そのギャップを偶然に委ねるのではなく、意図的に埋めるために存在します。それが10年前よりも今いっそう重要である理由は、流行によるものではなく構造的なものです。デリバリーは加速しました。チームは継続的にリリースしており、先送りされたアーキテクチャの決定とは、最初にコードを書いた者が下す決定にほかなりません。IT資産環境は断片化しました。今日の平均的な企業は、クラウドプラットフォーム、パッケージソフトウェア、ローコードツール、そしてレガシーの中核システムを同時に組み合わせてソリューションを構築しており、任意のものを構築するうえで実行可能な方法の数は倍増しています。そして非一貫性のコストは上昇しました。目標とする統合パターンを顧みずに構築された統合は、単に見苦しいだけでなく、荷重を支える依存関係となり、同じデータに触れるあらゆる将来の取り組みを制約します。この橋が重要なのは、その上を行き交う交通量が増え、その下に広がる落差が深まったからです。

率直に述べるに値する第一の原則は、スコープに関するものです。エンタープライズアーキテクチャはポートフォリオ全体、そして時間軸全体にわたって論じます。ソリューションアーキテクチャは単一の取り組みの内部において、その着想から運用までのライフサイクル全体にわたって論じます。作業の単位はソリューションです。すなわち、一つのシステムまたは機能の変更に対する一貫した設計であり、デリバリーを進められるだけの詳細さと、より広範なIT資産環境との適合性を判断できるだけの構造をもって表現されたものです。ソリューションアーキテクトは構築される対象の設計を担い、そしてそれが構築していないすべてのものとの整合性についての責任を担います。

ソリューションアーキテクチャは単一の成果物ではなく、小さく規律ある一連の決定です。それはソリューションの構造、すなわちコンポーネント、その責務、その境界を定義します。ソリューションがどのように機能要件を満たすかを定義しますが、より重要なのは、どのように品質要件、つまりバックログにはめったに現れないものの、そのものが本番環境との接触に耐えられるかどうかを決定づける性能、可用性、セキュリティ、保守性といった特性を満たすかを定義することです。それはソリューションとIT資産環境との関係を定義します。すなわち、どの既存機能を利用し、どれを公開し、どの標準を採用し、どれから意識的に逸脱するのかを定義します。そして、その部屋に居合わせなかった人々がその決定を理解し、異議を唱え、再検討できるように、その論拠を記録します。

有能なソリューションアーキテクチャを飾りから区別するのは、目標に照らした要件の扱い方です。脆弱な設計は要件を満たしつつ目標アーキテクチャを無視します。素朴な設計は目標アーキテクチャを尊重しつつ、都合が悪いと感じた要件を静かに満たさずに済ませます。強固なソリューションアーキテクチャは両者を緊張関係のなかに保ち、要件を満たし、可能な限り目標と整合させ、真にそれができない場合には、その対立を明示し、各選択肢のコストを定量化し、省略によって決定を下すのではなく決定を求めます。このレベルのアーキテクチャとはトレードオフのマネジメントであり、その主たる産出物は図ではなく、擁護可能な立場です。

いくつかの動向が、ソリューションアーキテクチャが優れていなければならない対象を作り変えつつあります。第一は、あつらえの構築から組み立てへの移行です。ソリューションのうち、コーディングされるのではなく組み合わされる割合が増えています。SaaS製品、プラットフォームサービス、パッケージモジュール、そして統合レイヤーを縫い合わせたものです。これはアーキテクトの重心を、内部の設計から接合部の設計へと移します。困難な決定は境界へと移ります。すなわち、製品をどう統合するか、データをどこでマスター管理するか、アイデンティティをどう流通させるか、周囲のすべてをほどくことなくある機能を後で置き換えるにはどうするか、といった決定です。組み立ては構築より容易ではありません。それは困難さを継ぎ目に集中させるのです。

第二の動向は、プラットフォームおよびプロダクトのオペレーティングモデルです。組織が長命なプロダクトチームと内部プラットフォームを中心にデリバリーを再編するにつれ、ソリューションアーキテクチャは中央機能から押し付けられるのではなく、それらのチームの内部でますます行使されるようになります。参照アーキテクチャは、チームが既定として利用する舗装された道と一連のプラットフォーム機能となり、ソリューションアーキテクトの仕事は、いつその舗装された道が適合するのか、そしていつ特定の取り組みがそこから離れる権利を得たのかを見極めることへと移ります。ガバナンスは承認ゲートから、プラットフォーム自体に組み込まれたガードレールへと移ります。

第三は、非機能要件および規制上の関心事の比重の増大です。データ保護、オペレーショナルレジリエンス要件、主権規則、そしてますます、自動化されAI駆動で下される決定の追跡可能性が、今や本番稼働前に後付けされるのではなく、最初のスケッチの段階からソリューション設計を形づくります。データがどこに存在し、誰がそこに到達でき、依存関係が障害を起こしたときにシステムがどう振る舞うかを明示できないソリューションアーキテクチャは、もはや単に不完全であるだけでなく、多くの場合コンプライアンス違反です。最後の動向は、設計および構築プロセスそのものへの生成系ツールの到来です。これはコードと候補設計の生成を加速させ、そうすることで、一貫性についての人間の判断の価値を下げるのではなく高めます。なぜなら、局所的にはもっともらしいが全体としては誤ったソリューションを生成することが、今やたやすくなったからです。

デリバリーとの接触、そして次の三つの取り組みを生き延びるソリューションアーキテクチャは、いくつかの原則を守る傾向があります。第一は優雅さよりも適合性です。正しい設計とは、アーキテクトが描ける最も洗練された設計ではなく、IT資産環境との整合を保ちながら、許容可能なコストでこの取り組みの要件を満たすものです。要件が求めていない洗練は、他の誰かが保守することになる負債です。

第二は創造より再利用です。ソリューションが新たなコンポーネント、新たな統合パターン、あるいは新たな技術を導入する前に、アーキテクトはIT資産環境に対して、既存のもので必要を満たそうとする真摯な試みを負っています。あらゆる純増要素は、組織が運用し、保護し、理解しなければならない対象範囲への恒久的な追加です。再利用は単に経済的であるだけでなく、エンタープライズアーキテクチャが成長するなかで一貫性を保つ主たる仕組みです。

第三は継ぎ目に向けて設計するです。ソリューションのうち最も変化しやすい部分、すなわち製品、プロバイダー、モジュールは、変化が封じ込められるよう安定した境界の背後に分離すべきです。疎結合は美的な好みではなく、次の取り組みがこの取り組みを再交渉することなく進められるかどうかを決定づける性質です。第四は非機能要件を明示するです。可用性、性能、セキュリティ、復旧の期待値を設計の入力として明記すること。なぜなら、設計されなかった品質特性とは、インシデントのなかで発見される品質特性だからです。第五は、そして最も見過ごされがちなのが追跡可能な決定です。あらゆる実質的な選択は、その代替案と論拠とともに記録されるべきです。これこそがソリューションアーキテクチャを、考古学的な謎ではなく生きた資産たらしめるものであり、目標からの逸脱を、静かな浸食ではなく、誠実で文書化された例外たらしめるものです。

象牙の塔。アーキテクチャは孤立して作成され、完成した成果物としてデリバリーに手渡され、数週間のうちに構築されたシステムから乖離します。その設計は誤っていたというより、決して現実のものではなかったのです。なぜならそれを構築する人々の摩擦によって形づくられなかったからです。デリバリーとの接触を保たないソリューションアーキテクチャは、存在しないシステムの文書と化します。

形式的な承認印。正反対の失敗です。アーキテクチャは、設計が形づくられるのではなく承認されるガバナンスのチェックポイントへと切り縮められます。設計がレビュー委員会に到達する頃には重要な決定はすでにコードのなかで下されており、委員会にできるのはそれを祝福するか、高くつく手戻りを引き起こすかだけです。遅すぎる時点で行使されるアーキテクチャはアーキテクチャではなく、監査です。

静かな乖離。取り組みが、目標アーキテクチャにとって扱いにくい要件を満たすことになり、その目標を無視することで対立を静かに解消します。例外は提起されず、コストは記録されず、目標アーキテクチャがもはや存在しない組織を記述するに至るまで、IT資産環境は文書化されない逸脱を蓄積していきます。これが最も腐食性の高い失敗です。なぜなら、それぞれの事例は個別には理にかなっていながら、総体としては致命的だからです。

過剰装飾とその双子。設計は、取り組みが抱えていない問題を解決し、仮説的な未来に備えて柔軟性、レイヤー、抽象を追加し、デリバリーは誰も使わないオプション性のためにコストを払います。その双子は、恒久的として計上された戦術的な近道です。すなわち、期日に間に合わせるために取られた意図的な妥協が、その後決して再検討されず、借入として負った技術的負債が静かに資本へと転換されるのです。両方の失敗は同じ根本原因を共有しています。トレードオフが、可視化されないまま下されたのです。深刻なソリューションアーキテクチャの失敗はほぼすべて、同じことに帰着します。すなわち、記録するのが安価で放置するのが高くつく瞬間に、それが重大だと知らなかった誰かによって、重大な決定が暗黙のうちに下されたのです。

Nashuaはソリューションアーキテクチャを、エンタープライズの視点とデリバリーチームのあいだに位置し、そのいずれにも完全には属さない実践として扱います。私たちは、組織がすでに保持する目標アーキテクチャと原則から出発し、それらが手薄な場合には実行可能な最小限の版の確立を支援し、そして取り組みごとに、その視点をデリバリーが行動に移せる設計へと変えていきます。重点は、文書ではなく決定を生み出すことに置かれます。構築にもガバナンスにも誰も使わない成果物はオーバーヘッドであり、私たちはそれを惜しみます。

実際には、これは私たちのソリューションアーキテクトがデリバリーの上位ではなく、その近くで働くことを意味します。彼らはそれを構築するエンジニアと、それを運用する事業オーナーとの対話のなかで設計を形づくり、アーキテクチャが理想化されたものではなく現実の制約を反映するようにします。私たちはあらゆる実質的な決定において、IT資産環境との適合を明示します。すなわち、何が再利用され、何が導入され、設計がどこで目標を尊重しあるいは逸脱するのかを明らかにします。逸脱が正当化される場合には、それを第一級の例外として扱い、定量化し記録することで、組織が何を取引しているのかを見て、意図的に選択できるようにします。舗装された道が適合する場合には、私たちはそれを選びます。なぜなら標準の価値は、それが使われて初めて実現されるからです。

私たちは非機能要件および規制に関する設計についても同様に意図的です。可用性、性能、セキュリティ、レジリエンス、データ所在地、そして自動化された決定の追跡可能性は、本番稼働前のゲートとしてではなく、最初の対話から設計の入力として扱われます。そして私たちは、組織を見出したときよりも有能な状態にして去るよう努め、私たちが手を引いた後も組織自身のチームが一貫性を維持できるよう、決定記録、ガードレール、そしてレビューの習慣を根付かせます。目的は決して単一のよく設計されたソリューションではありません。それは、一貫性がソリューションの設計のあり方に組み込まれているがゆえに、エンタープライズアーキテクチャと整合を保ち続けるデリバリーポートフォリオです。

Nashuaがもたらす違いは、アーキテクチャが現実のプロジェクトと出会う地点で行使される判断力であり、その判断を確実に定着させる到達力に裏打ちされています。多くの企業は目標アーキテクチャを描けますし、多くの企業はソフトウェアを構築できます。希少な能力は、その両者を結びつける規律です。すなわち、取り組みの要件と企業の原則を同じ手のなかに保ち、どのトレードオフが重要かを見極め、それらを静かにコードのなかに沈ませるのではなく明示する能力です。それが私たちの行う仕事であり、一貫性が文書のなかの願望ではなくポートフォリオの性質となるまで、取り組みごとに続けます。

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

私たちの実践を最終的に際立たせるのは、私たちがその全域にわたって、すなわちエンタープライズの視点からソリューション設計を経て運用中のシステムに至るまで説明責任を負い、境界で引き渡すのではなく、自らのアーキテクチャ決定の帰結を担うことです。その説明責任が決定の質を変えます。ソリューションアーキテクチャは、実際に構築されるものと、それが本番でどう振る舞うかへの忠実さの分だけしか優れておらず、組織に資するのは、いかなる単一の設計の優雅さでもなく、同じ意図を尊重するあらゆる設計の積み重なった一貫性です。Nashuaが違いを生むのは、各ソリューションが、それ自身の条件のもと、それ自身のプロジェクトのなかで、エンタープライズアーキテクチャを見出したときよりも強くして残すことを確実にすることによってです。