エンタープライズアーキテクチャは、この20年で目標状態を記述することに長けてきました。リファレンスアーキテクチャ、ケイパビリティマップ、ドメイン分解、そして各種の原則は今やよく理解されており、大半の大規模組織は、自社のシステム資産をどこへ導こうとしているのかについて、少なくとも一つは信頼に足る全体像を持っています。慢性的に未成熟なまま残されているのは、今日とその全体像とをつなぐ結合組織です。目標を見せてほしいと頼めば、たいてい一枚の図が示されます。ロードマップを見せてほしいと頼めば、同じ図に四半期の注記がボックスの脇に書き添えられたものが示されることが少なくありません。

このことは、10年前よりも今のほうがはるかに重要です。理由は明確です。変化が継続的かつ並行的になったのです。組織はもはや、明確なビフォーとアフターを持つ単一のトランスフォーメーションプログラムを実行しているのではありません。クラウド移行、アプリケーション合理化、データプラットフォーム統合、アイデンティティの近代化、規制対応を、共有システムをまたいで、重なり合うチームと限られた予算のもとで同時に走らせています。そうした環境において、順序づけのない目標はむしろ危険です。それは各プログラムが自らの最終状態のためだけに最適化することを招き、その衝突は遅れて、本番環境で、統合の破綻、重複した支出、そして誰も安全に完了もロールバックもできない中途半端に移行されたシステムとして表面化します。

ロードマップとは、独立した善意の寄せ集めを、生き延びられる作業の順序へと変えるものです。その役割は人を鼓舞することではありません。その役割は、ここから目標に至るあらゆる段階でシステム資産が稼働可能であり続けること、各段階に予算が付けられること、そして各段階が単に目標を指し示すのではなく実際に目標へと組み上がっていくことを保証することにあります。この保証が欠けているとき、トランスフォーメーションが停滞するのは目標が誤っていたからではなく、そこへ至る道筋を誰も順序づけなかったからです。

ロードマッピングの核心は、組織が一貫して投資を怠っている単純な三つ組にあります。ベースラインアーキテクチャがあります。これは今日ありのままのシステム資産であり、文書化されていない連携や、誰もが依存し続けていることを忘れているシステムまでを含みます。目標アーキテクチャがあります。これは意図された最終状態です。そしてその間に、トランジションアーキテクチャがあります。これはシステム資産の中間状態であり、それぞれが内部的に整合し、本番で運用可能であり、そこに立ち止まる価値のある状態です。トランジションアーキテクチャこそ、ロードマッピングが実際に生み出す作業単位であり、最も頻繁に飛ばされてしまう概念です。

トランジションアーキテクチャはマイルストーンでも進捗率でもありません。それはある時点におけるシステム資産全体の記述された状態です。どのシステムが存在し、どれが廃止され、どの連携が稼働し、どのデータフローが移行済みで、そして決定的に重要なこととして、事業がその上で運用できるかどうか、です。それらを定義するという規律は、曖昧なロードマップが避ける二つの問いを突きつけます。第一に、この中間状態は実際に稼働できるのか、それとも同じデータについて二つの正本システムが同時に権威を持つことを要求してしまうのか。第二に、そこに到達する価値があるのか、それとも二週間のあいだ二つのオペレーティングモデルを抱えるコストが節約分を上回るほど短時間で通り過ぎてしまう状態なのか、です。

トランジションアーキテクチャの間には、ワークパッケージが位置します。これはシステム資産を一つの整合した状態から次の状態へ移す変更のまとまりで、それぞれが依存関係、デリバリーのオーナー、そしてコストを伴います。ロードマップとは、これらのワークパッケージを、依存関係が尊重され、どのトランジション状態も稼働不能に陥らず、各フェーズを資金決定に結びつけられるように順序づけたものです。TOGAFのようなフレームワークはこれを移行計画のフェーズとして形式化していますが、重要なのはフレームワークそのものよりも、その根底にあるコミットメントです。あなたが計画しているのはプロジェクトではなく、一連の運用可能なシステム資産であり、そのそれぞれが、組織が原理的にはそこに留まることを選べる場所なのです。

いくつかの変化が実務のかたちを作り直しています。第一は、時間枠による順序づけから、ケイパビリティベースおよびバリューストリームベースの順序づけへの移行です。従来のロードマップはシステム単位、あるいはリリーストレイン単位で順序づけていました。現在の実務はビジネスケイパビリティの増分単位で順序づけます。どのケイパビリティが、どの順序で改善し、それぞれを解放するために最小限必要なアーキテクチャ作業は何か、です。これはロードマップを、アーキテクチャチームが整然としていると感じるコンポーネントではなく、事業が資金を出す成果を中心に組み直し、予算を握る人々にとって順序づけを読み取れるものにします。

第二は、共存パターンが一級のロードマップ要素として常態化したことです。ストラングラーパターン、並行稼働、そして漸進的なデータ移行は、もはや気の利いた例外ではありません。それらは重要度の高いあらゆるシステム資産にとっての既定の前提です。なぜなら、ビッグバン方式の一斉切り替えは大規模には危険すぎることが証明されたからです。これはロードマップが含むべきものを変えます。今やロードマップは共存の仕組みを明示的に定めなければなりません。腐敗防止層、トラフィックを旧か新へ振り分けるルーティング、両方が稼働している間に二つのシステムを整合させ続ける突合、といったものです。これらは後で発見される実装の細部ではありません。それらはあらゆるトランジションアーキテクチャの荷重を支える部分であり、しばしばフェーズの中で最もコストのかかる部分です。

第三の変化は財務的なものです。ポートフォリオおよびプロダクトの資金モデル、増分的かつ継続的な予算、そしてクラウドに伴う資本費用から運用費用への移行は、いずれもロードマップの資金プロファイルを、後付けの考慮事項ではなく設計上の制約にしました。アーキテクチャ的には優雅でも、ある年に大きな資本コミットメントを必要とし、その年にそれが用意できないフェーズは、実行可能なフェーズではありません。ますますロードマッピングは財務を同席させて行われ、各増分が次を賄うのに十分な実現価値やコスト回避を生み出すよう増分を形作っています。ロードマップは、前もって提示される請求書ではなく、自己資金でまわる連鎖になるのです。

持続するロードマップは、それを願望リストから区別するいくつかの原則に従います。第一は、あらゆるトランジションアーキテクチャが稼働可能でなければならないということです。これは譲れない原則です。計画上のいかなる時点でも、システム資産が事業を実際には運用できない状態に依存してはなりません。二つのシステムが顧客マスターを自らのものだと信じているフェーズがあってはならず、廃止された連携の代替が稼働していないフェーズがあってはなりません。トランジション状態が運用可能でないなら、それはトランジションアーキテクチャではなく、崖です。

第二は、順序を駆動するのは日付ではなく依存関係だということです。ロードマップは、何が何に先立たねばならないかの有向グラフとして構築され、クリティカルパスが可視化され、日付はそのグラフから導かれるべきであって、グラフに押し付けられるべきではありません。データ依存関係はとりわけ尊重に値します。データが他の三つのシステムから解きほぐされていないアプリケーションを移行することこそ、ロードマップがひそかに崩れる場所です。なぜなら、データの結合は人々が描き忘れる依存関係だからです。

第三は、廃止は願望ではなく成果物だということです。追加するだけのロードマップはロードマップではなく、堆積計画です。各フェーズは、何を停止させて実現された節約に変えるのかを明示すべきです。なぜなら、旧システムの引退こそ通常ビジネスケースの拠り所であり、そしてそれはチームが際限なく先送りしたい誘惑に最も駆られる段階だからです。第四はオプショナリティです。優れたロードマップは、初期のフェーズが後の選択肢を開いたまま保ち、単独で価値を提供するよう順序づけられています。そうすることで、フェーズ2の後に資金や優先順位が変わっても、組織は整合した状態に残され、跳躍の途中で立ち往生することはありません。可逆性、少なくとも各切り替えに対する定義された代替手段は、同じ原則の一部です。安全に放棄できないフェーズは、始めるべきでないフェーズです。

ビッグバンの誘惑。最も一般的な失敗は、フェーズが少なすぎて大きすぎるロードマップで、それが単一の決定的な切り替えに集約されるものです。スライド上では効率的に見え、そしてすべてのリスクを一つの不可逆な瞬間に集中させます。ある程度の規模を持つシステム資産は、責任ある組織であれば受け入れるべきでない失敗確率を伴わずに、一挙にプラットフォームを刷新することはできません。その是正策は、一時的な共存の仕組みを抱えるコストを払ってでも、より小さく運用可能な増分にすることです。

孤立したトランジション状態。これに近い失敗は、中間状態が実際には稼働不能なロードマップです。目標は整合し、出発点も整合していますが、フェーズ3が二つの正本システムを同時に権威あるものとして要求したり、重要なインターフェースに稼働中のオーナーが存在しないまま残したりします。こうしたロードマップがレビューを通ってしまうのは、レビュー担当者が端点を確認して中間を信頼してしまうからです。各トランジションアーキテクチャを運用可能なシステム資産として書き下すという規律こそ、まさにこれを捕らえるものです。

資金とデリバリーの乖離。財務とデリバリーを欠いてアーキテクトだけで描かれたロードマップは、システム資産が望む順序ではあっても予算が支えられない、あるいは余裕のないチームを前提とした順序で作業を段階分けします。すると各フェーズは、技術的な理由ではなく、資金が計画の想定とは異なるかたちで到来するために遅延します。決して廃止されないレガシー。これに関連し、そして広く蔓延しているのが、新システムが導入され、旧システムは引退するはずなのに、引退がいつも来四半期という事態です。プログラムを正当化した節約は決して実現せず、システム資産は以前より複雑になり、二つの世代を同時に抱え込んでしまいます。凍りついたロードマップ。最後に、ロードマップが、現実の動きに合わせて再ベースライン化される生きたモデルとしてではなく、一度公開されて守られる固定された成果物として扱われる失敗です。継続的な変化にさらされるシステム資産は、昨年の順序を無効にします。見直されないロードマップは虚構となり、それでも人々はそれを前提に計画してしまうのです。

Nashuaはロードマッピングを、運用可能なシステム資産を順序づける営みとして捉え、文書化されたベースラインではなく正直なベースラインから着手します。いかなる段階分けを提案するよりも先に、私たちはシステム資産が実際に何であるかを確立します。本物の連携、真のデータ所有権、そしてアーキテクチャリポジトリではなく運用の中に生きている依存関係です。理想化された現状の上に築かれたロードマップは、その理想化のあらゆる欠落を受け継ぎます。ですからベースライン作業は前置きではなく、順序が立脚する土台なのです。

そこから、私たちはトランジションアーキテクチャを明示的に定義します。各中間状態は、運用可能なシステム資産全体として記述され、単一の問いに照らして検証されます。すなわち、事業がそこで運用しなければならなくなったとして、無期限に運用できるか、です。次いで、これらの状態の間を移すためのワークパッケージが定義され、依存関係はクリティカルパスを浮かび上がらせたグラフとしてモデル化され、データの結合は実装上の脚注ではなく一級の依存関係として扱われます。私たちは順序をケイパビリティの増分とバリューストリームを中心に構築し、各フェーズが事業の認識し資金を出す成果に対応するようにします。そして廃止とその実現された節約が、願望ではなく成果物として計画に書き込まれるようにします。

私たちはこれを、最初から財務とデリバリーを同席させて行います。資金プロファイルが段階分けを形作ります。各増分は、次を支えるのに十分な価値やコスト回避を生み出すよう規模が定められ、資本と運用への影響が明示され、計画は実際に存在する予算とチームに照らしてストレステストされます。そして私たちはロードマップを、デリバリーの進行に伴って計測され再ベースライン化される生きたモデルとして引き渡します。なぜならシステム資産は動き続け、それとともに動けないロードマップにはほとんど価値がないからです。成果物は、四半期が添えられた図ではなく、資金化可能で順序づけられたプログラムです。

Nashuaがもたらす違いは、目標を計画の代わりにさせることを拒む点にあります。多くのアドバイザーはあなたの最終状態を検証し、順序づけはそれを構築しなければならない者に委ねます。価値は結合組織の中にあります。運用可能なトランジションアーキテクチャ、システムだけでなくデータをも尊重する依存関係グラフ、財務が資金を出せデリバリーが人員を配置できる段階分け、そして廃止とその節約を永遠に先送りするのではなく計画上に保ち続ける規律です。それは数多くのシステム資産を通じて蓄積された技であり、目標を、事業を運用し続けながら組織が実際に旅できる経路へと変えるものです。

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

これらのエンゲージメントを一貫して際立たせるのは、システム資産が全体を通じて稼働可能であり続けることです。クライアントはロードマップを、危険な着地を伴う信仰の跳躍としてではなく、一連の整合した状態として経験します。そのそれぞれが安全に立ち止まれる場所であり、それぞれが目標により近く、それぞれが前の状態が解き放った価値によって賄われています。それこそが適切に行われたロードマッピングの要点です。より美しい到達点ではなく、事業に単一の切り替えへすべてを賭けることを決して求めず、システム資産を運用できない状態に決して取り残さない、順序づけられ資金化可能なそこへの道筋です。Nashuaの貢献は、その道筋を現実のものにし、足元の地面が動いても現実のものであり続けさせることにあります。