「主語」と「目的語」をモデル化する

前回はArchiMateの振る舞い要素についてご紹介しました。今回は構造要素をご紹介します。下の図の左側「リソース」の仲間たちです。

「振舞い」の目的語

前回ご紹介した「振る舞い」要素には、振る舞う対象があります。レイヤー毎に下のような図形であらわされます。

上から「ビジネス・オブジェクト」「データ・オブジェクト」「アーティファクト」です。ArchiMateではこれらを「受動構造 ("Passive Structure") 要素」と呼んでいます。アプリケーション・レイヤーの受動構造要素は、このデータ・オブジェクトのみ、ビジネスとテクノロジの各レイヤには、何種類かの派生形がありますが、それらは追々ご紹介しましょう。

大抵のケースでは振舞い要素から「読み書き」される受け身の存在ですが、抽象度のより高い概念を「実現する」こともあります。

これらはデータアーキテクチャでいうところの「概念」「論理」「物理」の各エンティティの表現に使うことが出来ます。ただしArchiMateにはクラスとインスタンスの区別はなく、カーディナリティを表現する語彙を欠く点がER図などのデータモデルの記法とは異なります。大所はArchiMate、その詳細はER図、という使い分けです。

またこれらはデータエンティティに限らず、他のさまざまな概念の抽象表現にも幅広く用いられます。例えばEDINETに投げるXBRLドキュメントもデータオブジェクトです。「OSビルド」はアーティファクトです。

データは大事

データはエンタープライズ・アーキテクチャの重要な構成要素です。

エンタープライズ・アーキテクチャの観点では、主要なデータエンティティ、少なくともリソースのマスタと、会計仕訳に繋がるイベントのトランザクションを、重要な概念エンティティとして出来るだけ押さえておきたいところです。これにビジネス・オブジェクトを使います。

念のためですが、ビジネス・レイヤーは人間系、アプリケーション・レイヤーはシステム系、という意味ではありません。ビジネス・レイヤーはシステム化されていようがいまいが、要はビジネスがやっていることの表現です。

昔の紙の受注伝票や、それらを綴じた5cmファイルの受注台帳とかが「ペーパーレス」の結果なくなっても、「受注伝票」とか「受注 (出荷・請求) 台帳」という「概念」まで失ってしまってはいけません。

概念を残すためには言語化が必要ですが、残念なことにこれを怠ったことで、ペーパーレスどころか「概念レス」に陥って「画面操作は知っているが、意味や目的は知らない」組織が現実に数多く存在します。EAモデリングはそういう「組織の失語症」の予防に役立ちます。

リソース・マスタとして、「自分の組織」「取引相手」「取引品目」の三つは、ビジネスの種類によらず、どんな組織にも存在します (各組織固有のエンティティは、それらのサブタイプとも言えます)。組織固有のこれらのデータ・エンティティを、ビジネス・オブジェクトとして特定します。

イベント・トランザクションとしては、まずサプライチェーン・ビジネスであれば「在庫取引」の、またマッチング・ビジネスであれば「契約」の、それぞれの概念エンティティをビジネス・オブジェクトとして押さえましょう。売掛買掛の「会計取引」は両方に共通です。最終的に総勘定元帳に刺さるデータが大事ですね。

エンティティの種類として、マスタ、トランザクションのほかにもう一つ、残高 (バランス) があります。「総勘定元帳」は残高テーブルの親玉です。その資産勘定の補助簿として「売買残高」や「在庫受払残高」などもあるでしょう。

ビジネス・オブジェクトを使って簡単な概念ER図を描けば、それはその組織のビジネスのドメインモデルにもなります。

主要な概念エンティティの存在を押さえることができたら、それらと「データ・オブジェクト (≒論理エンティティ)」、またデータ・オブジェクトと「アーティファクト (≒物理エンティティ)」との関連を線でつなぎます。

多くの組織は既に数百、数千の「物理テーブル」をシステムの一部として持っていながら、「概念エンティティを描いたもの」を持たないので、データの「意味的なビジネス価値」がわかりません。最初にも記したように、戦略的な「リソース」は、抽象としての「データ」を含みます。でも物理名しか書いてないテーブル・レイアウトを見ても、どんなデータの集まりなのか、どれが大事なのかはよく分かりませんよね。なので、重要な物理エンティティを特定するためにも、まず自らの組織に存在し、事業を事業足らしめている主要なデータを、概念エンティティとして描いてみるわけです。

「振舞い」の主語

「振舞い」要素には、振る舞う「当人」も当然います。レイヤー毎にはこのようになっています。

上から「ビジネス・アクター」「アプリケーション・コンポーネント」「ノード」です。ArchiMateでは"Active Structure"、能動構造要素と呼びます。

能動構造要素には、この3つの他にもいくつかの派生形があります。この後に紹介するインターフェースとコラボレーションも能動構造です。それら以外の「役者」については、追々ご紹介して行きたいと思います。

後述しますが、能動構造には「コスト」、更にアクター以外には「寿命」が付き物です。モデルに拾っていくときは「高価なモノ」「寿命が近いモノ」から先に押さえましょう。

「ビジネス・アクター」は自然人、法人を問わず、固有名詞で識別可能な個人やその集団です。企業名、部署名、役職名などを入れられます。これを階層構造に並べて組織モデルを作っておけば、あとでモデル上の他の様々な要素との関連付けに使えます。

「アプリケーション・コンポーネント」の名前には、システム名やシステム資産の識別番号などを付けると良いでしょう。差し当たりはシステム台帳に載っているシステムを並べるところから始めます。

もしシステム名や資産番号がざっくりしすぎる場合は、結合度合いで分けてみましょう。ライフサイクル的に一蓮托生なら一つのアプリケーション・コンポーネントですし、部分的に更新可能ならその部分は独立したアプリケーション・コンポーネントです。判れば年間償却費とか保守費が幾ら掛かるか、ベンダーはどこ、とか保守契約の期限とかも入れておきましょう。

SaaSならサブスクの契約単位です。これも課金単位とか実績とか入れておきましょう。

「ノード」は物理・仮想どちらにも使えます。オンプレのサーバは物理ノードです。AWS EC2は仮想ノードですね。物理ノードならマシン名、仮想化ノードならインスタンスIDなどを名前に使えば良いでしょう。もちろんディスクアレイやらコアスイッチやらの他の重要な装置も、これで示すことが出来ます。

スマホやタブレット、ハンドヘルドスキャナ、もろもろのIoTデバイスなど「物理デバイスであること自体に意味がある」ものには「ノード」の派生形である「デバイス」を使った方が良いでしょう。同様にオンプレとクラウドにあるものを明示的に区別したい (オンプレサーバが何台残っているか数えたい、とか) 場合は、物理ノードに「デバイス」を使って構いません。

コスト関連はアプリケーション同様です。一番良いのはメタデータを整備して"Property"を使うことですが、差し当たりは"Documentation"に書いておきましょう。

インターフェースとサービス

ArchiMateのインターフェース要素は、サービスの振る舞い要素とペアです。

冒頭のリソースとケイパビリティとの関係と似ていますね。サービスという「外部に露出した振る舞い」の「当人」、あるいはその振舞いの「在りか」をイメージ頂くと良いでしょう。

ビジネスレイヤーでの例を一つあげると、カスタマー・コールセンターがインターフェース、カスタマー・サービスがビジネスサービスです。

アプリケーションレイヤーなら、REST APIのエンドポイントがインターフェースですね。

テクノロジーレイヤーでは、クラウドの入り口、例えばAWSのゲートウェイがテクノロジー・インターフェースに当たるでしょう。

コラボレーションとインタラクション

最後に「コラボレーション」要素です。これはサービスとインターフェースとの関係と同様、インタラクション振る舞い要素とのペアになります。

インターフェースは「点」でしたが、コラボレーションは「場」のイメージです。ビジネス・レイヤーであれば、インタラクションが「会議でやること(議題や目的)」、コラボレーションは「会議体そのものの名前」です。例えば「生販調整会議」がコラボレーション、「PSI計画の策定」がインタラクションです。

前回のインタラクションでも記しましたが、アプリケーションやテクノロジー・レイヤーでは、コラボレーションは急いで描く必要も無いでしょう。何かと何かがコラボレーションしているわけですから、コンポーネントやノードが一通り出揃ったら、どれとどれがどんなコラボレートをしているかを考える、という順番になります。

しかしながら、エンタープライズ・アーキテクチャがいったん出来上がったら、その後はそれをどう発展・進化させるかを考える上で、コラボレーションは重要な概念です。例えばIoTのコンテクストで、どんなノード同士をコラボレートさせれば、どんな振舞い (インタラクション) が実現できるか、などを考えるわけです。

能動構造はコスト

アーキテクチャが語られるとき、おカネに触れられるケースはほとんど目にしません。なぜなのか理由は分かりませんが、すくなくともそれをやってはいけない理由はないでしょう。

「継続事業の論理構造」は、PL上のSGAの違うカタチでの表現でもあります。すくなくともそういう意識は必要、かつ他の領域 (コンピュータ・サイエンスとか) への関心より優先されるべきでしょう。

ビジネス・アクターは人件費、アプリケーション・コンポーネントはソフトウェア資産、ノードはハードウェア資産そのものです。ソフトやハードは近年オフバラ化、変動費化が進んでいますが、償却費がサブスク費に変わったと思えば同じです。

ArchiMateではデータとしての要素に、いろいろな属性 ("Property")を持たせることができます。属性項目などのメタデータをきちんと管理する、などのガバナンスが必要ですが、そこに金額などを入れることで、コンピュータを使って集計や分析もやがて出来るようになるでしょう。

最初はそこまでやらずとも、能動構造を描くとき、これは年間いくらかかるのか、とか、償却資産なら取得はいつか、耐用年数は何年か、などを意識することで、一見図形やデータの羅列に過ぎないモデルから、現実のビジネスのダイナミズムを少しずつでも感じ取れるようになるでしょう。そこまでいけば、いよいよEAリテラシーも本物ですね。

-------

前回今回と、継続事業の構造を、能動・受動・振舞い要素といった、いわば存在論的な観点からブレークダウンする方法について考えてみました。

しかしエンタープライズ・アーキテクチャはそこでは終わりません。継続事業は自然現象ではなく人工物なので、そこには人間の意志が働いています。次回は、これをArchiMateでどうやってモデル化すればよいのか考えてみましょう。おたのしみに。