一般的な企業は数百から数千のアプリケーションを稼働させており、その数はほぼ常に経営層が考えているよりも多いものです。シャドーIT、経費カードで支払われる部門単位のSaaS契約、そして移行の際に誰も廃止を確信できなかったために生き残ったシステムが、実際の数をすべて押し上げます。ほぼすべてのポートフォリオレビューにおける最初の不都合な発見は、アプリケーションが古いということではなく、信頼できる一覧を誰も作成できず、ましてや各アプリケーションが事業のために何をしているのかを言える者がいない、という点です。

これが十年前よりも今いっそう重要になっているのには、明確な理由があります。新しいアプリケーションを取得する限界費用が崩壊したのです。機能を追加するということが資本プロジェクトであり、サーバーであり、ライセンス交渉を意味していた頃、資産は緩やかかつ意図的に成長しました。それが、部門長が一午後のうちにクラウドサービスに登録することを意味するようになると、成長は継続的かつ無秩序になります。資産は、どんな中央機能が把握できるよりも速く拡大し、機能的な重複は例外ではなく既定の状態になります。二つのチームが同じ問題を二つの異なるツールで解決し、どちらも相手の存在を知らないのです。

そのコストはライセンス支出だけではありません。もっとも、重複した支出は現実であり、しばしば無視できない規模です。より深いコストは結合と脆弱性です。顧客データに触れるすべてのアプリケーションは、そのデータが整合から外れて食い違いうるもう一つの場所であり、維持すべきもう一つの統合であり、いかなる変更も安全に行う前に考慮しなければならないもう一つのシステムです。偶然に成長した資産は、密かつ不可視に相互接続される傾向があり、その結果、何かを変更する労力は、変更の大きさではなく全体の大きさに比例して増大します。アプリケーションアーキテクチャは、その資産を読み解けるものにし、その上で意図的に再構成するために存在します。

アプリケーションアーキテクチャの組織原理は、アプリケーションが第一の対象ではない、というものです。第一の対象はビジネスケイパビリティです。ケイパビリティとは、組織が実行できなければならない事柄を、どのように実行されるかとは独立に表現した、安定した記述です。顧客関係を管理する、保険料を算定する、支払いを決済する、生産を計画する、といったものです。ケイパビリティはゆっくりと変化します。事業そのものを記述しているからです。アプリケーションは絶えず変化します。それが実装だからです。アーキテクチャをケイパビリティに結びつけることで、特定のどのシステムよりも長く存続する座標系が得られます。

その座標系に対して、資産を読み解けるものにする二つのビューを構築します。第一は、ケイパビリティとアプリケーションのマッピングです。各ケイパビリティについて、どのアプリケーションがそれを支え、どの程度支えているかを示します。これは即座に、複数のアプリケーションが同じケイパビリティを主張する冗長性と、事業が依存するケイパビリティが表計算ソフトと習慣以外の何ものによっても支えられていないギャップとを、浮かび上がらせます。第二のビューは機能分解です。アプリケーションを、それが実際に提供している機能的な構成要素へと分解することで、単一のスイートとして販売されているシステムを、それが提供する八つ、あるいは十の別個のサービスとして理解します。そのうちのいくつかは、まったく異なる製品のサービスと重複しています。

これら二つのビューは、主観的な議論を証拠に変えます。ある事業部門があるシステムを維持する必要があると主張するとき、問いは精密になります。ほかの何ものも支えていないどのケイパビリティをそれが支えているのか、そして答えがなしであれば、対話は感情から順序づけへと移ります。そこから生じる意思決定を枠づけるために広く用いられるツールが、しばしば許容、投資、移行、廃止として表現される処置モデルです。各アプリケーションは、そのビジネス価値と技術的適合性の両方に照らして配置され、それが収まる象限がその意図を規定します。育てるのか、維持するのか、置き換えるのか、廃止するのかです。このモデルの価値はラベルにあるのではなく、すべてのアプリケーションに既定の未来ではなく宣言された未来を持たせるという規律にあります。

環境の組み立て方を二つの力が作り変えつつあります。第一は、大規模な統合スイートから、より小さく独立して置換可能な部品によって構築されるコンポーザブルな資産へという、決定的な移行です。語彙もそれとともに移りました。パッケージ化されたビジネスケイパビリティ、コンポーザブルERP、そして単一のベンダーが領域全体を所有するよりも交換可能なコンポーネントを好むアーキテクチャスタイルです。その意図は健全です。いずれか一つのシステムの影響範囲を縮小し、周囲のすべてを置き換えることなくコンポーネントを置き換える選択肢を保つのです。コンポーザビリティは、ほとんどの組織が少なくとも一度は経験し、二度と繰り返したくないと願う、複数年にわたる高リスクのスイート置き換えに対する備えです。

第二の力は調達の消費者化であり、これがSaaSの乱立をこの十年を定義するポートフォリオ問題へと変えました。資産は今や周縁で成長します。少数の大規模な導入ではなく、多数の小さな契約を通じてです。そしてその多くは、更新やセキュリティレビューが露呈させるまで、中央のアーキテクチャからは不可視です。その結果は、より一層モジュール化されると同時に、より一層断片化された資産です。追加は容易でありながら、全体を見通すのはより困難なのです。

コンポーザビリティはまた、複雑さを除去するのではなく再配置します。多数の小さな交換可能なコンポーネントからなる資産は、それらを結びつける統合とデータアーキテクチャに等しい良さしか持ちません。そして環境は、モノリスを、そのモノリスよりも推論の難しい分散システムへと分解しうるのです。したがって現在の規律は、モジュール型を統合型よりも良しとする教義を選ぶことよりも、ケイパビリティごとに、組織が独立した置換可能性から真に恩恵を受ける場所と、適切に境界づけられたスイートのほうが率直な答えである場所とを判断することに重きを置きます。成熟した見方は、コンポーザビリティを目的地ではなく、コストを伴うツールとして扱います。

ケイパビリティをよく支える環境は、小さな一連の原則に従う傾向があり、それらを明確に述べておく価値があります。それらこそが、設計された資産を堆積した資産から分けるものだからです。第一は単一の機能所有です。各ケイパビリティは一つの権威あるアプリケーションを持つべきであり、各重要なデータドメインは一つの記録システムを持つべきです。これは、あらゆる場所でケイパビリティごとに一つのアプリケーションを持つという意味ではありません。それは達成可能でも常に望ましくもありません。しかしこれは、重複が存在する場合、それが誰も気づかなかった偶然ではなく、意図的で文書化された選択であることを意味します。

第二の原則は、高い機能的凝集性を伴う疎な結合です。アプリケーションは、ともに変化するものがともに存在し、独立に変化するものが安定した明示的なインターフェースによって分離されるように組織されるべきです。健全な資産の尺度は、いかにシステムの数が少ないかではなく、いかに独立して変化できるかです。一つのシステムへの変更が五つの他のシステムにわたる協調した変更を強いる資産は、個々のコンポーネントがいかに現代的であっても高い結合を持ちます。そして結合こそが、年数ではなく、環境が動かしがたいという感覚の真の源泉であるのが通例です。

第三の原則は、統合はアーキテクチャであって配管ではない、というものです。アプリケーションがどのように互いに通信するか、イベントを通じてか、共有サービスを通じてか、マスタ化されたデータ層を通じてか、あるいは危機のたびに一つずつ構築された脆弱な一対一のインターフェースを通じてか、それが全体の結合を決定します。一対一で配線された環境は、その複雑さが規模の二乗で増大するメッシュになります。第四の原則は、すべてのアプリケーションは宣言されたライフサイクル段階と名前を持つ所有者を持たなければならない、というものです。所有者のないシステムは統治できず、宣言された未来のないシステムこそが、既定によって永遠に生き残るものです。とりわけ廃止は設計活動です。廃棄は置換が選ばれた瞬間から計画され、データ移行、インターフェースの疎結合化、アーカイブが、ついぞ十分な予算のつかない後回しの作業としてではなく、第一級の作業として扱われます。

表計算の作業としての合理化。もっとも一般的な失敗は、合理化を一度きりのコスト削減の一掃として扱うことです。コンサルタントが一覧を作り、目標が設定され、明白な重複がいくつか削られ、そしてプロジェクトが終わった日から資産は再び堆積を始めます。合理化は出来事ではなく、継続的なケイパビリティです。所有者と常設のプロセスがなければ、数年のうちに数は元の水準に戻り、この作業は再びやり直さなければなりません。

決して完了しない廃止。組織は置換を購入することには長けており、置き換えたものを停止することには不得手です。新しいシステムが稼働を開始し、古いものはそれに続くはずでしたが、何年も経ってもなお稼働し続けています。一つの帳票、あるコンプライアンス用アーカイブ、あるいは一つの頑固なインターフェースが決して移行されなかったからです。資産は結局、古いものと新しいものの両方を抱え込むことになり、これはどちらか一方だけよりも悪い状態です。その失敗はほぼ常に、廃棄が実際の作業として予算化も計画もされなかったことにあります。

適合性ではなく傾向によって決められる内製対購入。ある組織はエンジニアリングがそう望むために反射的に内製し、別の組織は調達のほうが容易であるために反射的に購入します。そして両者とも、真のアーキテクチャ上の意思決定を文化的な既定として扱います。正しい枠組みは狭いものです。ケイパビリティが真の差別化の源泉である場合にのみ内製し、市場がよく解決するコモディティである場合には購入します。コモディティのケイパビリティを内製することは、組織が競争上の利得なしに永遠に維持しなければならない独自システムを取得する道です。

統合と取り違えられたスイートのロックイン。多くのケイパビリティを網羅する単一のベンダーは、しばしば統合された資産として販売され、時には本当にそうであることもあります。しかし、一つの製品がすべてを所有することによって達成される統合はアーキテクチャではなく、依存です。そしてそれは、いかなる部分もプログラムなしに置き換える選択肢を奪います。その失敗の形態は、更新の時になって、資産に交渉力も出口もないと気づくことです。自律性として容認される重複。最後に、機能的な重複はしばしば事業部門の独立性として擁護されます。それが正当である場合もあります。しかし多くの場合、それは権限委譲の言葉をまとった、単に管理されていない重複にすぎず、誰もそのコストを可視化していないために存続するのです。

Nashuaはまず資産を読み解けるものにすることから始めます。それなしには、後続の何ものも擁護できないからです。それは、誰かが最後に表計算を更新した時点ではなく現実を反映した、信頼できるアプリケーションインベントリを構築することを意味します。そこには、正式な登録簿が見落とすシャドーシステムや部門システムも含まれます。次に各アプリケーションは、それが支えるビジネスケイパビリティにマッピングされ、それが実際に提供する機能的サービスへと分解されます。こうして重複と冗長性は逸話であることをやめ、指し示せる証拠になります。

その基準線から、作業は処置へと移ります。Nashuaは各アプリケーションを、そのビジネス価値と技術的・機能的適合性の両方に照らして配置し、宣言された意図を割り当てます。維持、投資、置換、あるいは廃止です。これは事業に対してではなく、事業とともに行われます。所有する機能部門が受け入れない処置は、意思決定ではなく、なし崩しだからです。意図が合理化にある場合、Nashuaは作業を容易さではなく結合とリスクによって順序づけ、資産の変更を高価にする重複と一対一の絡み合いに取り組み、置き換えられたシステムの廃棄を、データ移行とインターフェースの疎結合化を最初から範囲に含めた、予算化され計画された作業として扱います。

内製対購入の意思決定は、好みではなく差別化に照らして枠づけられます。Nashuaは、独自の内製がその生涯にわたる維持コストに見合う一握りのケイパビリティを、適切に境界づけられたパッケージ化されたコンポーネントが率直な選択である大多数から区別する手助けをし、それらのコンポーネントを疎に結合し独立して置換可能に保つ統合とデータアーキテクチャを設計します。全体を通じて、重点はアプリケーションポートフォリオ管理を、名前を持つ所有者、宣言されたライフサイクル、そして反復可能なレビューの周期を備えた常設のケイパビリティとして確立することに置かれます。こうして資産は偶然に堆積することをやめ、設計によって変化し始めます。成果物は一度きりの報告書ではなく、エンゲージメントが終わった後も読み解けるものであり続ける、統治されたポートフォリオです。

Nashuaがもたらす違いは、アプリケーションアーキテクチャを純粋なコストの作業としても、純粋な技術の作業としても扱うことへの拒否です。資産を合理化すると約束するのは容易であり、それを持続させるのは困難です。資産を乱立させた力、すなわち容易な調達、局所的な自律、そして何かを停止することへの躊躇は、目標が達成された日に止まりはしないからです。Nashuaは、より痩せたスナップショットではなく、組織が統治し続けられるポートフォリオを残すべく取り組みます。ケイパビリティがマッピングされ、処置が所有され、結合が理解され、そして次の偶然の重複が固着する前にそれを捉える周期があるポートフォリオです。その機能的な厳密さと組織的な現実主義の組み合わせこそが、環境を、組織に起こったものから、組織が方向づけられるものへと変えるのです。

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

成果を一貫して分けるのは、Nashuaがビジネスと技術の両方のビューを一つの対話の中で結び合わせて保持することです。処置モデルは、その下にあるケイパビリティマップに等しい良さしか持たず、ケイパビリティマップは、そのさらに下にあるインベントリの誠実さに等しい良さしか持たず、そしてそのいずれも、所有する機能部門が意思決定とそれを持続させる統治を受け入れなければ、組織との接触に耐えられません。Nashuaはいずれか一つのつながりではなく、鎖全体に取り組みます。だからこそ、それが設計を助けた資産は設計されたまま留まる傾向があり、事業が実際に依存するケイパビリティを支え、次の痛みを伴う清算まで静かに堆積することがないのです。