「構造」をモデル化する
単語を並べて文章にする
「継続事業」という概念に「カタチ」はないが概念的な「構造」はあって、それは「概念要素」の「関連」で表現できます。これまで様々な種類の概念要素をご紹介してきましたが、概念要素を並べただけでは構造にはなりません。バラバラな〇ゴブロックと同じですね。
これらを組み上げれば、ブロックは概念ではなく物理的存在なので「カタチ」が出来て、そこに「建物」とか「乗り物」とかいった意味なり価値なりが表現されることになります。ArchiMateで概念要素間に関連を引くことは、この「ブロックを組み立てる」ことに当たりますね。
またブロックを単語に見立てれば、それを繋げて意味をなす文章を書いている、ともいうこともできます。関連をひくことで、幼児期の単語の羅列から、いよいよ首尾一貫した文章表現に進歩するわけです。
ArchiMateの視覚表現を直接理解出来ると効率的ですね。しかしそうなるにはやはり脳内変換で一旦日本語とかにする段階を経る必要があるでしょう。視覚表現と自然言語表現を自由に行き来できるようになれば、それがリテラシーの獲得、ということになると思います。
ArchiMateの「関連 (Relationship)」には「構造 (Structural)」「依存 (Dependency)」「動的 (Dynamic)」の、主に3つの分類があります。
このうち構造リレーションは、概念要素間の静的な関係を表します。静的とは、相手に「作用」しない、つまりそれによって相手の何かが変わったりすることがない関係ですね。
構造リレーションには「アサイメント (Assignment)」「アグリゲーション (Aggregation)」「コンポジション (Composition)」「リアライゼーション (Realization)」の4種類があります。順にご紹介しましょう。
「アサイメント」リレーション
以前の記事でこんな図を描きました。
この二つの要素の間の「根本が丸い矢印」が「アサイメント」リレーションです。
直訳すれば「割り当て」ですね。よってこの図は、リソースがケイパビリティに割り当てられている状態です。
アサイメントの「ソース」、いわゆる「起点」は、常に構造要素、あの「角が四角い」ヤツ、なおかつ「能動」です。「ターゲット」は振舞い要素 (「角が丸い」)、構造要素のどちらも有り得ます。
ターゲットが「振る舞い要素」なら、ソースの構造要素は、その振舞いの「主語」と解釈できます。「リソースがケイパビリティに割り当てられている」という上の図は、リソースが主語として、ケイパビリティという「振る舞い」をしている、ということになります。
ターゲットが「構造要素」なら、要素の種類によって「ソースはターゲットに責任がある」という関係になります。例えばこんな図があるとします。
例えばアクターがサポセン担当者、ロールがカスタマーサポートとして、サポセン担当者はカスタマーサポートに責任がある、という意味になります。
この辺りまではだいたい「アサイメント」の本来の意味と近いのでわかりやすいですね。
アサイメントにはもう一つ、少し解り難い解釈があって、それはソースがターゲットに「場所を提供している」というものです。逆に読めば「ターゲットはソースのところにある」となります。
左側の「ロケーション」要素はこれまで出てきませんでしたが、要は地名や住所で表現可能な、地理的な場所のことで、どのレイヤーにも属しません。
「ノード (特定のハード)」は「ロケーション (どこそこのサーバ室とか)」、また「コミュニケーション・ネットワーク (特定のVLANタグとか)」にあります、また「ノード」には「テクノロジー・インターフェース (SFPとか)」と「アーティファクト (ファームウェアとか)」があります、といった意味になります。
「アグリゲーション」リレーション
「アグリゲーション」は要するに「仲間」「グループ」です。基本的に同じ種類の要素間で使いますが、アスペクト (構造とか振舞いとか) が同じなら大丈夫です。
この例では、ビジネスプロセスAとBが一つのビジネス・ファンクションにまとめられている、という意味ですね。ちなみにこれはあくまで例で、ファンクションとプロセスの上下関係についてArchiMateに決まりはなく、逆向きの線も実際に引けます。
アグリゲーションは「一蓮托生ではない (個別のライフサイクルをもつ)」関係を表現します。この例でいえば「上が無くなっても下が無くなるわけではない」という関係を表現しています。ビジネス・プロセスの括りなんか、例えば職制変更によってすぐに変わってしまいますからね。
先ほどの「ロケーション」要素は、このように何でもアグリゲート出来ます。ノードがどこにあるかの表現としてはこちらの方が一般的ですね。
以前取り上げたモチベーション要素のSDGsの表現です。プリンシプル「X」がSDGsのゴール、「A」と「B」はSDGsのターゲットですね。
「コンポジション」リレーション
コンポジションはアグリゲーションと違い「一蓮托生 (ライフサイクルをシェアしている)」な関係です。
例えばこれらのファンクションやプロセスは密結合で、プロセスAだかBだかが止まったらファンクションも止まる、という関係になります。「家」と「部屋」みたいな関係にも例えられます。家がなくなっても部屋がある、なんてことは無いので。
先ほどのアサイメントの代わりにコンポジションを使った例です。アサイメントならフィジカルな (e.g. SFP) 構成、コンポジションならロジカルな (e.g. VLANポート) 構成、といったニュアンスで使い分けが出来ます。
「リアライゼーション」リレーション
リアライゼーションは、具象と抽象の表現です。なので基本的にレイヤーを跨いで引かれることのないアサイメントやコンポジションと異なり、これはレイヤーを跨ぎます。ソースが具象、ターゲットが抽象です。
データベースを齧ったことがあれば、「物理エンティティ」「論理エンティティ」「概念エンティティ」というのを聞いたことがあるでしょう。それらの関係をArchiMateで描くとこうなります。もちろん下から「物理」「論理」「概念」です。そしてデータの戦略的価値を突き詰めると、一番上の「リソース」になります。
実存としては、一番下の物理エンティティが、例えばAuroraのDBインスタンスの中にあるだけですね。その一つのブツを、抽象レベルを変えて表現しているわけです (複数の論理サブタイプの実装が物理テーブル一本、とかはもちろんありますが)。
外コンのヒトとかだと、よくhigh level、low levelといった表現を使いますが、このhighやlowも結局は抽象度ですね。この「モノゴトを抽象・具象の両面から見る」ことは、EAリテラシーの正にキモとなるセンスの一つでしょう。こういう二分法的な視点はほかにもありますね。
what/why と how
バリューとコスト
長期と短期
安定と変動
これらを意識してモデルを眺めて「なるほど」と感じられればしめたものです。例えば概念エンティティで大事なのは「ビジネスの」what/whyでありバリューです。物理エンティティは「実装の」howでありコストです。概念エンティティはオペレーション・モデルに属し、それは毎月変わったりしません。物理エンティティの実装はそれこそミクロなレベルでは常に変動しているでしょう。そこまでモデルには書きませんが。
下の例も上記のような二分法的な観点から同様な観察が可能でしょう。一番下のワークパッケージはプログラムとかプロジェクトですね。上から下にだんだん「解像度」が上がっていく感じです。
ところで、ハイレベルの概念の実現には、複数のローレベル概念が必要だったりもしますね。それは例えばこんな絵になるのでしょうか？
ArchiMateの文法上では、これだとコース・オブ・アクションの具現化には、ワークパッケージA、B「どちらかが」あれば良い、という意味になってしまいます。AとBどっちも必要、というのを明示したいときは、”AND”ジャンクションを入れましょう。
ネスティングに注意
構造リレーションに限らず、リレーションはネスティング (入れ子) で代替できますが、それは「線を見えなくしている」ということでもあります。ツールを使ってネスティングを描くとき、線を引き損ねていないか、線種や向きを間違っていないか、ネストをバラしてチェックするクセをつけることをお勧めします。
「ネスティングは外側が上位階層」というのはあくまで人間の解釈で、ツールにはそういうチェックはありません。ですからこんな絵も描けてしまいます。
左は「このノードはこのロケーションにある」という正しい絵で、ネストさせるなら本来はロケーションが外側、ノードが内側になるはずですが、逆に右側のような変な絵も描けてしまいます。シンタックス上は「AがBの一部ならBもAの一部」ということで問題ないのでしょうが、セマンティック上は問題アリですね。
リアライゼーションとジャンクションの例も、こういう絵は描けますし、実際にこの表現を使うこともあるでしょう。
これは「ジャンクションの黒丸が中に入れても消えずカッコ悪いのでビュー上で消した」ものですが、これだけだと「A or B (=代替案)」なのか「A and B (=両方やる)」なのか、中にそういう説明を書くか、もしくはデータを見ないと分からないですね。
ArchiMateにおいてはデータが正、ビューは補助的なモノ、という意識が大事です。ビューは一見フレンドリーに見えますが、実は意味的に不十分だったり間違っていたりすることもあるので気を付けましょう。
こうしてみると、日本のトラディショナル組織は縦割りに加えてヨコも断絶しているような気がします。「データはアプリ (とかマイクロサービス) が動くためにある」とマジで思ってるヒトが情シスに沢山いたりするし、一方では幹部合宿で講師も呼んでマインドマップとかBMCとか描いて、でも描きっぱなしのまま放置、とかフツーにありますよね。そしてこれらの間に繋がりが生じることもなく、発散が進んでいくわけです。
エンタープライズ・アーキテクチャとはつまり、抽象と具象との間を行ったり来たりすることですね。DXとかもそうやって実現していくのではないでしょうか。ArchiMateでEAモデルが描ければそれが出来るのに、もったいないなあ、と感じます。EAリテラシーが広まることで、そういう状況が少しでも良くなれば、と願うばかりです。
次回は「依存 (Dependency)」関連をご紹介します。お楽しみに。
この記事が気に入ったらサポートをしてみませんか？