前回まで企業戦略とIT投資の整合を図る方法として、BSCと情報資本ポートフォリオについてお話をしてきました。

情報資本ポートフォリオを使ったマネジメントの基本的な考え方は、企業の戦略との関係性において自らが保有する情報資本のレディネスを高めるということでした。

エンタープライズアーキテクチャは、企業の保有する情報資本すべてをマネージメントするための考え方で、全体最適を進めるにあたっては、必要不可欠なフレームワークです。

エンタープライズアーキテクチャ（EA）の基本的なフレームワークは、下記の図に示すように、企業の持つ情報資本を、BA、DA、AA、TAの4層に分けて可視化しマネジメントしようとするもので、情報資本ポートフォリオも実はこのEAのフレームワークと同じ構造をしています。（内部プロセスの視点がBAに相当します）

出典：ＩＴアソシエイト協議会「業務・システム最適化計画について(Ver.1.1)～ Enterprise Architecture策定ガイドライン～」平成15年12月

情報資本ポートフォリオは戦略と関係の深い情報資本のみにフォーカスを充てています。そのため、情報資本ポートフォリオにはすべての情報資本が掲載されているわけではわりません。逆にいうと、EAが整備されていると、情報資本ポートフォリオの作成が非常に容易になります。

一方、EAに掲載されている情報資本には、それがどのような技術で構築されているのかは記載されていません。メインフレームもクラサバも、Webベースも、クラウドもすべて同じアプリケーションとして記載されています。
しかしながら、デジタルトランスフォーメーションにおいては、テクノロジーレベルのアーキテクチャの設計が必要となります。

この検討のために、EAにガートナーのペースレイヤ―モデルを組み込んだフレームワークを利用します。

出典：https://www.slideshare.net/jeffshuey/pace-layered-approach-and-winshuttle-share-point-conference-nov-2012-jeff-shuey

次回は、このペースレイヤ―モデルの説明から始めます。

ペースレイヤーモデルの概念がガートナーから提唱されたのは2012年です。

https://www.gartner.com/newsroom/id/1923014

当時はアジャイル開発対ウォーターフォールという不毛な議論が盛んな時代でしたが、Pace Layered Modelを適用することにより、明確な役割分担の指針を出すことができると考えました。

その後、同じくSystem of Recordsという概念を有するバイモーダルITのコンセプトが広まったために、Pace Layered Modelはあまり広まりませんでした。

しかしながら、デジタルトランスフォーメーションの時代になって、戦略との整合性をも設計できるPace Layered Modelを改めて使う時がきたと考えています。

それを的確に表したのが、2016年4月にガートナーが公開した「Pace-Layered Application Strategy and IT Organizational Design」に掲載された下記の図です。

ベースとなる座席管理のサブシステムは、Systems of Recordと分類され、しっかりと確実に作られるべきだとしています。この部分は近いうちにブロックチェーンに置き換わるかもしれません。一方、料金体系は戦略に応じて様々なものが設定されるため、料金エンジンは差別化のためのシステムとして分類されています。戦略との整合が最も強く現れるところです。

ここの更新頻度は半年に一度位でしょう。ホテルの宿泊料金に様に需要予測から設定する変動型にしておくと一年に一度位の変更で済むかもしれませんが、ユーザーに不安感を与えるので、ある程度は予測可能なモデルにしてくべきでしょう。このようなルールの考え方がすなわち会社戦略を反映しているわけです。

一方エンドユーザーと接するSNS連携やWebアプリ（スマホアプリでも同じです）の部分は革新システムとして位置づけられています。

差別化システムについては明確な差別化戦略がありそれに基づいて構築されます（またはそうあるべきです）が、革新システムは予測がつかないものであり、不毛な机上の空論で時間を費やすよりも、早く市場に投入し、その反応を見ながらスパイラル型でブラッシュアップしていくスタイルが必要となります。もしくはそのスタイルを取らなければ、誰にも使ってもらえないアプリになります。

このようにデジタルトランスフォーメーションの時代のシステムは、３つの異なる性格を持つシステムで構築されることになります。バイモーダルITのモデルではこの部分がうまく説明できないのです。

さて、上記の図に示したような美しいアーキテクチャを採用できるようになるには、企業システム全体がある程度成熟している必要があります。縦割りの部分最適な状態では上記のアーキテクチャを採用したシステムが稼働できないからです。

ということで、次回からはEAの発展段階を整理するフレームワークとして「アーキテクチャ成熟度ステージ」をご紹介します。