ArchiMateリレーションシップ、今回は「動的 (Dynamic)」と、バンドルで「その他 (Other)」リレーションもご紹介します。動的リレーションが「トリガ (Trigger)」と「フロー (Flow)」、その他リレーションが「特化 (Specialization)」と「関連 (Association)」の、それぞれ2種類です。

「動的」リレーションは、時間・空間的な概念を含むところが「構造」や「依存」のリレーションとの違いになります。時間・空間的な概念とは、「順番」とか「動く向き」ですね。抽象度が高いモチベーション要素や、永続的存在である受動構造要素には、刺さったり、それから生えたりしない、というのが特徴です。

「その他」リレーションは要するに「構造」「依存」「動的」いずれにも当てはまらないもの、というだけで、そこに含まれるもの同士に共通点は有りません。

それでは順番に見ていきましょう。

「トリガ」リレーション

これは振舞い要素や能動構造要素を、因果関係の順番に並べるのに使います。

例えばEquipment Aが火災センサー、Bがサイレン、イベントが火災の検知、アクターがフロアに居るヒトだと、センサーが火災を検知してサイレンが鳴ってフロアに居るヒトに避難を促す、といった意味に読めます。レイヤーとか構造要素か振舞い要素とかあまり気にせず、要はモノゴトの時系列上の前後関係を表現したいときに使える、ということです。

「抽象度高め」と言いながら、これは抽象度の低い例ですね。もう少しEAらしい、抽象度の高い例も挙げておきましょう。

夫々プロジェクト計画、移行イベント、ターゲット・アーキテクチャですが、それらの前後関係を示しています。

「フロー」リレーション

トリガが「順番 (A then B)」なら、フローは「向き (from A to B)」です。「何か」がAからBに移るわけですが、その移る「何か」は様々です。

インターフェースAからBに「データ」が流れています。「何が」流れているかは誰でも気になるものなので、このように何かしら名前を付けた方が良いでしょう。データだったら実際には例えばI/Fのファイル名を入れたりします。Archiでシステム間のデータフローをちゃんと描けば、スプレッドシートの「インターフェース台帳」なんか要らなくなります。

ここでは流れているのは経費精算とかの「伝票」ですね。ロールは一般的によくある「起票」「審査」「承認」(英語でもpreparer / reviewer / apporoverといいます) なら、トリガも組み合わせれば順番も強調出来ます。繰り返しですが、伝票は物理的に存在しないかもしれませんが、概念としては有るのですから、それはちゃんと書いて残す必要があります。ムダな業務の削減とかはその後の話になります。

以上2つが「動的リレーション」です。

「アソシエーション」リレーション

続いて「その他リレーション」のご紹介、最初は「アソシエーション」です。

今までご紹介した他のリレーションと異なり、アソシエーションにはいわゆる文法的制約は有りません。任意の要素間で自由に引けるので、教科書には下書きなんかにも使える、と書いてあります。しかしそれでは話が終わってしまうので、代表的な使い方を4つ紹介します。

1つめはモチベーション要素間の関係です。

ステークホルダ、ドライバー、アセスメントの関連を表しています。この辺りで引けるのはアソシエーションとインフルーエンスくらいですね。たまにリアライゼーションも使いますが。

2つめは概念ER図です。いわゆる「意味的なデータモデル」ですね。自組織のビジネス領域 (ドメイン) を、永続的なデータ (エンティティ)で表現します。ビジネスモデルの違いはこのカタチに響きますし、業界の違いはエンティティの中身に現れます。

この例だと、AとBがリソースのマスタ (カスタマーとプロダクトとか)、CとDがトランザクション (受注と出荷とか)、といった感じです。

ArchiMateでは、論理物理レベルは大事なエンティティだけ押さえておけば、ER図的な表現まで描く必要は有りません (し出来ません) が、こういった概念ERくらいは描いておくべきでしょう。ハイレベルなデータ・アーキテクチャはArchiMateで押さえて、ローレベルはデータモデリングツールで描く、という使い分けです。

「データ・ドリブン経営」を目指すなら、その第一歩は、こうやって「ビジネス語彙でデータの意味を定める・伝える」ことになるはずですが、これが出来ない・やりたがらないトコロが実はとても多くて、なので大半がBIツール買ってそれっきり、で終わったりするわけです。

3つめはデータフローです。

データをAからBに移送しているのをきちんと描くと、これだけの要素が要りますが、データの方をアソシエーションで繋いでしまえば、上のアプリ連中が要らなくなって、すっきりしたデータ・セントリックなビューが出来ます。何が流れているかは両端のエンティティを見ればわかるので、それをいちいち描く必要も有りません。

ArchiMateの文法上は、アソシエーションには向きはありませんが、ツール的にはそうも行かず、他のリレーションと同様、ソースとターゲットの線を引いた順をデータとして持っています。

この図のターゲット側の「ヒゲ」は、リレーションのプロパティを"directed"にすることで生やすことが出来ます。そのうちこれもArchiMateの正式文法になるかも知れませんが、今のところはArchiツールの独自実装です。

最後の4つめですが、アソシエーションには、ほかのリレーションにはない「片側がリレーション」という離れ技があります (厳密にはアグリゲーションとコンポジションも引ける場合が文法上はありますが、非常に限定的です)。

これはデータフローの中身を示していますね。一般にリレーションの存在にはその両端の要素が不可欠ですが、要素を書くのは後回しにして、とりあえず判っているデータフローだけ並べたい (I/F台帳の中身、使う予定のJSONメッセージなど) 場合に便利でしょう。

「スペシャリゼーション」リレーション

UMLをご存じの方には説明不要ですが、ここでも「オブジェクト指向」というArchiMateの出自が現れていますね。特化リレーションと名前が付いていますが、矢印の向きは実際には「汎化 (generalization)」で、矢印と反対方向が「特化 (specialization)」です。

これもハイレベルのデータ・アーキテクチャを描くときに「スーパータイプ/サブタイプ」の表現に使うことができます。

この絵は「上は下を汎化 (generalize) したもの」「下は上を特化 (specialize) したもの」という表現ですね。でも、汎化とか特化とか、いったいどんな意味なんでしょう？他の関係、例えばアグリゲーションと何が違うんでしょう？

簡単にいえば、スペシャリゼーションで結ばれたこの3つのエンティティは、キーと主な属性項目を共有していますが、サブタイプAとBはそれぞれ固有の属性項目を持っている、ということになります。

例えばスーパータイプは「クルマ」、サブタイプAは「ガソリン車」、サブタイプBは「EV」とすると、「燃料タンク容量」という属性はAには必要、Bには不要ですね。「バッテリー容量」という属性はその逆になります。

スペシャリゼーションは「属性項目の違い」、アグリゲーションは「ある属性の値の違い」ですね。「クルマ」に含まれる「赤いクルマ」とか「白いクルマ」は、アグリゲーション関係で表現される「色という属性項目の中の値の違い」ということになります。

スプレッドシートで例えれば、項目多くてめっちゃ横長なわりに、空白セルが偏っているとき作りたくなるのがサブタイプ、ということになるでしょう。

これとは逆に「要らない属性を抜きたい」場合もありますね。次の絵では、上のほうが例えば個人情報を含むデータ、下でそれを匿名化して (属性を抜いて) 分析に使っているようなケースです。

能動構造や振る舞いの要素も同様に「スーパークラス/サブクラス」として表現できます。RMA (返品) が受注メニューのひとつだったら、「受注」ファンクションがスーパークラス、「RMA受注」ファンクションがひとつのサブクラスです。

特化には排他 (区分値のどれかを選択) とか共有 (複数フラグ) とかあって、データモデリングツールだとちゃんとER記法で表現できますが、ArchiMateでそこまでやらなくても良いでしょう。まずは間違ってても良いから、ビジネスのコトバで、概念ERを描いてみることです。

次回は、今までご紹介していなかったその他もろもろのキャラをご紹介します。お楽しみに。