前回は、論理アーキテクチャと物理アーキテクチャのそれぞれを「都市計画」と「家づくり」になぞらえてみました。その上で、「家づくり」に相当するITプロジェクトは、より俊敏なスタイルに変わっていくべきと書きました。言い換えると、物理アーキテクチャの実装に相当する個々のプロジェクトにおいて、「より着実に」「より早く」成果が出せるような形にしていきたいわけです。まさにリノベーションさながらです。さて、こうしたプロジェクトを支えるアーキテクチャ活動を見ていく前に、今回は「論理アーキテクチャ」と「物理アーキテクチャ」の意味を、少し掘り下げてみたいと思います。それらの持つ価値についても十分に認識されていないことがあるように感じますので、私の捉え方を織り交ぜつつ考察してみます。
ということで、今回のテーマは「論理アーキテクチャと物理アーキテクチャ」です。
***
論理アーキテクチャは、要求からソリューションを導く最初のマイルストーンとして、技術非依存な初期モデルとして扱われることが多いと思います。一方で、物理アーキテクチャは、より具体的な特定技術や制約を考慮に入れたものを指します。この特徴から論理アーキテクチャには、次のような価値があります。
・様々なステークホルダーの共通言語としての価値
・特定の技術変化に依存しない安定したモデルとしての価値
システム開発においては、「要求の定義」→「論理アーキテクチャ作成」→「物理アーキテクチャ作成」という流れで作成されます。論理アーキテクチャに対する一つの考え方として、要求から(特定技術による)物理アーキテクチャに可能な限り早く到達するための使い捨てとするアプローチがあります。一方で、論理アーキテクチャを『戦略的な資産』として保守するというアプローチもあります。多くの企業で採られるアプローチはこれらの間のどこかに位置しています。しかし、DX時代とかVUCAの時代と言われる現代こそ、場当たり的なIT投資は避けたいものです。ですので、戦略的な資産としての論理アーキテクチャの必要性はますます高まっていると思います。
***
少し見方を変えて、エンタープライズアーキテクチャの4つのドメインの観点で、論理アーキテクチャと物理アーキテクチャを考えてみます。
AA(アプリケーションアーキテクチャ)
アプリケーションソフトウェアの世界では、「論理アーキテクチャ」と「物理アーキテクチャ」の捉え方は一般的です。オブジェクト指向により、特定技術に依存しない論理コンポーネントとして設計することが広く浸透しました。サービス指向アーキテクチャやマイクロサービスアーキテクチャの台頭が、その傾向に拍車をかけているように思われます。
DA(データアーキテクチャ)
データアーキテクチャの世界でも、古くから論理モデルと物理モデルという考え方が確立されています。企業活動をするにあたって本質的なデータは何かを設計する際に、論理モデルは極めて有効です。
BA(ビジネスアーキテクチャ)
ビジネスアーキテクチャでは、その対象として主に組織構造やビジネスプロセスを扱います。そういう意味では本質的に技術非依存に見えますが、昨今ではFacebookをはじめとする様々なソーシャルメディアプラットフォームを介した顧客体験のデジタル化や、IoTデバイスやRPAの浸透による顧客自体のデジタル化という流れがあります。よって、ビジネスアーキテクチャの世界でも技術に依存した観点がクローズアップしてきたと言えるでしょう。
TA(テクノロジーアーキテクチャ)
BAとは逆に本質的に技術依存の領域ですが、組織としての技術戦略や技術標のカタログというような、プロジェクト単位での物理アーキテクチャ実装を越えたテクノロジーモデルの確立は、大規模化/複雑化する企業活動において一層重要となるでしょう。
こうしてみると、全てのアーキテクチャドメインに「論理アーキテクチャ」と「物理アーキテクチャ」という側面があると思われます。ここで重要なポイントが一つあります。
それは「論理アーキテクチャ」という切り口によって、BAからTAまでを地続きでつなげることが極めて重要であるということです。言い換えると、ビジネスとテクノロジーがギャップなくつながっている状態です。以前のブログで、組織が抱える構造的な問題を解決するには2つのギャップを解消する必要があると書きました。その一つが、「ビジネスとテクノロジーのギャップ」です。具体的には、デジタル技術が経営に活かされていなかったり、ITシステムがビジネスの足枷となっていたりする状況です。ビジネスとテクノロジーのそれぞれの専門職はもっと協調すべきですし、「わたし作る人」「わたし使う人」という溝は埋められなければなりません。しかし、BA~TAの階層構造が、その意に反してビジネスとテクノロジーの分断を起こしている気もするのです。(そう感じられたことはありませんか?)
ビジネスからテクノロジーまでは地続きでなければなりません。その地続きのイメージを、本ブログでは地平(遠くまで続く大地のなだらかな広がり)と表現してみました。その地平の役割を担うのが「論理アーキテクチャ」であると考えます。企業システム全体を俯瞰する論理アーキテクチャを手に入れることで、今まで有効に活用できていなかったアーキテクチャ資産を再発見したり、その能力の不足を解消することが可能になります。もちろん、「物理アーキテクチャ」の側面においてもBAからTAまでの一貫性が求められることは当然ですが、「論理アーキテクチャ」によってそこは担保されると思われます。
これがドメイン(空間)を越えた論理アーキテクチャの価値です。
***
さらに視点を変えて、アーキテクチャが変化する時間軸の観点で、論理アーキテクチャと物理アーキテクチャを考えてみます。
望ましいアーキテクチャの将来像をTo-Be(またはターゲット)アーキテクチャと言います。一方で、現在のアーキテクチャの姿をAs-Is(またはベースライン)アーキテクチャと言います。As-Isアーキテクチャから一足飛びでTo-Beアーキテクチャに到達できることもあれば、技術的な難易度や様々な制約があるため何段階かのステップでTo-Beアーキテクチャを実現するという判断もあります。ステップを分ける場合、各ステップをCan-Be(またはトランジション)アーキテクチャと言います。To-Beアーキテクチャは戦略的なレベルで検討することが多いと思いますので、中長期的なスパン(3~5年またはそれ以上)で将来像を構想することになるでしょう。その結果として、数ステップのCan-Beアーキテクチャを経て、To-Beアーキテクチャヘ至るロードマップが描かれることになります。ここにおいて、To-Beアーキテクチャを表現するものは論理アーキテクチャであり、それに至る各ステップの一つ一つの差分が物理アーキテクチャ実装にあたると考えるとわかりやすいと思います。
ここで、重要なポイントがあります。To-Beアーキテクチャは永遠に完成することはないということです。当初描いた将来像が実現できればそれで終わりではありません。当初考えていなかったようなビジネスの変化、または破壊的なテクノロジーの進化は常に存在するものです。よって、To-Beアーキテクチャは永遠の未完成品なのです。にもかかわらず、プロジェクトが終われば、アーキテクチャモデルを棚にしまったままという企業は案外多いのではないでしょうか。とてももったいないことです。DX時代とかVUCAの時代と言われる現代こそ、海図を常にアップデートしていくことが求められると思います。環境の変化に追随し、結果としてビジネスアジリティを高める。これが時を越えた論理アーキテクチャの価値です。
***
今回は、地平(遠くまで続く大地のなだらかな広がり)になぞらえてアーキテクチャを考えてみました。もともとITの世界で「アーキテクチャ」という概念が登場したのは、IBMが最初の汎用コンピュータであるSystem/360の設計思想を表現するために用いたのが始めだそうです。それがいまや、情報システムはもとよりビジネスの世界を表現するようになりました。これからは、社会や世界とのつながりも含めるようになっていくに違いありません。アーキテクチャの地平はますます広がっていくでしょう。そうした広がりのなかから、新しい発見やイノベーションが生まれてくれば素晴らしいと思います。