ArchiMateのリレーション、今回は「依存 (Dependency)」です。前回の構造リレーションと違い、依存リレーションはターゲット要素に何らかの「作用」を及ぼします。

なぜそれを「依存」と呼ぶのかというと、ArchiMateの「お里」が元々「オブジェクト指向だから」、ということになります。そのお国コトバでは、オブジェクトaがオブジェクトbを呼び出して使うとき、aはbに依存している、といいますが、その名残、というワケですね。

依存リレーションは「インフルーエンス (Influence)」「アクセス (Access)」「サービング (Serving)」の3種類です。それでは順番に見て行きましょう。

「インフルーエンス」リレーション

これはいわゆる「インパクト」です。インパクトが「依存」というのはなんだかモヤッとしますが、教科書的には「もっとも弱い依存」ということのようです。

「弱い」ということは、つまり抽象度が高い、というわけで、ターゲットは抽象度の高いモチベーション要素に限定されます。ソースは何でもアリですが、たいていは同じモチベーション要素、たまにストラテジー要素が使われます。

(ローレベルな要素がハイレベルなモチベーション要素にいきなりポジティブなインパクトを与える、というのは、話が飛び過ぎていて説得力が有りませんよね。IT業界ではそういう話がゴロゴロしていて困ったものですが。逆にネガティブなインパクトは、技術的負債やセキュリティなどたくさんあって、そちらをもっと心配すべきです)

インパクトには「強弱」「正負」があるので、そういう属性を表現できるようになっています。

便利な使い方として「トレードオフの表現」があります。

線の真ん中辺にプラスとマイナスの記号があり、もちろんこれが「正負」を表します。記号の数、この場合はどちらもふたつですが、これがインパクトの「強さ」です。

上の図は、何らかの施策 (Outcome) が目標 (Goal) に対してポジティブに働くが、ある規範 (Principle) に対しては、同じくらいにネガティブに働く、ということを表現しています。ゴールの達成に良かれと思った施策が、実は例えばSDGs的には問題がある、といった表現に使えます。

「アクセス」リレーション

これは能動構造要素や振る舞い要素から、受動構造要素への「読み書き」という作用の表現です。

ツール (Archi) ではアクセスが「読み」か「書き」かを「線を引く順番」ではなく、線の「属性」で設定します。下の図で矢印は上向き、つまり「読み」ですが、線を引く操作の順番は、最初のソースがファンクション、次がターゲットのデータです。

線を引いたらデフォルトで「書き」、つまりこの場合矢印は下向きになっているので、引いた線の属性を「読み」に変更すると、矢印の向きが上の図のようにひっくり返る、という寸法です。「ソースとターゲット」と「読み書き」とは別、ということですね。

というのも、属性には4つオプションがあるからです。write、read、access、read/writeが選べます。accessだと矢印なしのただの点線、read/writeだと両頭矢印になります。

アクセス・リレーションは次のようにネストで表現することも出来ますが、これも前回同様「線が見えない」問題がありますので、読み書きの向きを確かめた上で入れ子にすることをお勧めします。

前回ご紹介した、各レイヤーの受動構造要素による「概念」「論理」「物理」のエンティティ表現に、アクセスする能動構造要素を加えると、こんな絵になります。

こうなると、左側の列にも縦の線が欲しいですね。大丈夫、ちゃんとあります。

サービング・リレーション

左側の能動構造のスタックにも、縦の線を付けてみました。

これがサービング・リレーションです。ソースがターゲットに何らかの「便益を提供 (serve) している」という、日本語的には少々面倒な読み方になってしまいますが、逆は簡単で、要するにターゲットはソースを「使っている」です。これは最初にご紹介した「依存の語源」に近いものですね。

せっかくですから振る舞い要素も足してみましょう。

左側のファンクションのスタックの縦関係は、右側のエンティティにあわせてリアライゼーションを使っていますが、実際はサービングをつかうことが多いでしょう。リアライゼーションだと「同じ機能の抽象度違い」という表現になり、現実にはそういうケースはあまり存在しないでしょうから。

同様に、ノードやアプリケーション・コンポーネントが夫々のファンクションを「リアライズ」することもできますが、ここでは単に夫々のファンクションが、ノードやアプリケーション・コンポーネント (の一部) を使っている、という表現になっています。

一方、ビジネス・アクターがビジネス・ファンクションを「リアライズ」することは無いので、ここではサービングしか引けません。但し向きは両方有り得ます。この図のようにアクターがファンクションに「使われている」のであれば、アクターは社内のスタッフでしょうし、アクターがファンクションを使っているのなら、それは社外のカスタマー、という見立てが出来ます。もっともその際はファンクションではなく、同じ振る舞い要素でもビジネス・サービスを使うのがより適切でしょうが。

またこの図では、センターのスタック間のサービング・リレーションは、「導出 (derived) されたリレーション」とも言えます。アクターがファンクション、ファンクションがコンポーネントを使っている、ということはつまり、アクターは (ファンクションを介して) コンポーネントを使っている、という見立てです。

それでは、さらにこれを、サービング・リレーションにもっとフォーカスして描いてみましょう。振る舞い要素のレイヤー間のリアライゼーションや、導出されたサービングを取ってしまいます。そうするとこんな形で、サービング関係で上から下まで全部つながった絵に出来ますね。

また、データのアクセス元も、能動構造要素から、振舞い要素に変えてみました。どちらが正しい、ということはなく、ファンクショナル・ドメインでエンティティもきれいに分けられるのであれば、ファンクションとつなげばよいだろうし、そうでなければコンポーネントなどの能動構造とつなげばよいでしょう。

実際の「継続事業の概念構造」を描く際には、描くヒトはレイヤー毎に違う (ビジネスは業務側、アプリはアプリ担当、テクノロジーはインフラ担当) わけですが、レイヤー間はこうやって、サービング・リレーションでつなげればよいわけです。

関連付けが大事

レイヤー跨ぎのサービング・リレーションのない要素とはつまり、使われていない要素、ということになります。それは直ちに「そもそも必要なのか？」という疑問につながるでしょう。

サービング・リレーションがあればあったで今度は「それはどのくらい役立っているのか」という疑問につながります。

また逆にモデルの観察を通じて「サービスが欠けている要素、不十分な要素」を考えることも出来ます。

いずれにせよ、繋がりによって意味が生まれ、意味から価値が生まれるわけです。繋がりによる価値モデルの創造と発展、これがArchiMateの本当の使い道ですね。トランスフォーメーションとは発明 (invention) ではなく発見(discovery) だ、と誰かが言っていましたが、EAにおける「発見」の対象は、この「繋がり」ですね。繋がりはインサイト (insight) であり、それには意味 (sense)、そして価値 (value) があるはずです。

このような手法は昔からZettelkastenをはじめとして、世の中にいろいろありますが、それを個人ではなく組織レベルで、かつワークショップのような一過的なイベントではなく、組織全体の継続的な習慣、あるいはカルチャーにしてしまうという取り組みは、エンタープライズ・アーキテクチャ・マネージメントと呼ぶことができます。

人間一人ではままならない記憶や思考をArchiMateで拡張して、designとexecutionの両方で、みんなでbuildとfixを回していきましょう (Bob the Builderのテーマでも歌いながら)。そうやってemployee engagementを高めることで、「一人の天才」抜きでも、みんなで勝てるチャンスが来るかも知れませんね。

次回は「動的 (Dynamic) 」関連をご紹介します。お楽しみに。