今回は、Archiのパレット上に居るのに今まで紹介されなかった面々にスポットを当てます。思いのほか量が増えたので前後編の2回にわけてご紹介します。今回はその前編です。

ビジネス・オブジェクトのなかま

「レプレゼンテーション」と「コントラクト」

これらとビジネス・オブジェクトとの関係を絵にするとこのようになります。

ビジネス・オブジェクトとコントラクトとの関連は、3本とも逆向きにも引けます。念のためですが、これはArchiMateを説明するための、いわゆるメタモデルであって、実際の用例ではないことにご注意下さい。

まずレプレゼンテーションですが、他の2つとはリアライゼーションで繋がっています。各ターゲットの「抽象度低い」バージョンですね。どういう風に低いか、というと「人間にとって知覚可能 (perceptible) な情報媒体」です。物理的な書類から、pdfとかのファイル、画面のUIなどの表現に使えます。下の段でいえば、左のレプレゼンテーションは「契約書」、右は「契約」というより広い概念です。「契約書」は物理的な紙にしろpdfにしろ、「人に読んでもらう」という意図に変わりは有りませんね。それはこんな風に表すことができます。

インターフェースはディスプレイやプリンタ、レプレゼンテーションはディスプレイ上のUIや、印字された紙です。レプレゼンテーションは人間に読んでもらうためにあるワケですから、それが「誰のため」なのかも、こんな風に描いておくべきでしょうね。

コントラクトは文字通り契約です。情シスには沢山ありますね。とりあえずこれを実際に存在する契約の数だけ並べてゆけば、契約台帳の出来上がりです。契約当事者はアクターですね。下の絵でアクターAが組織内、アクターBが組織外とすれば、コントラクトは組織の内外の境界を成すことになります。

オンプレシステムの保守契約などなら、このままノードやアプリケーション・コンポーネントに紐付ければ済みますし、SaaSならこんな風に、まずサービスに紐付けると良いでしょう。PaaSやIaaSならアプリケーション・レイヤーの要素の代わりにテクノロジー・レイヤーの要素を使います。

サービスから先 (下) の描き様は、上記に限らずいろいろ考えられますが、「誰と誰との、どんなサービスに関わる契約」という絵はすぐに描けるでしょう。そのあとでサービスの先をぼちぼち繋げてゆけば良いのです。

また、コントラクトの別の使い方として、マッチング系のビジネスでは、コントラクトは最も重要なビジネス・オブジェクトですから、概念ERを描くときに使うのもアリです。ER図を描くと決めたら、まず最初にこれをドン、と真ん中に置いて、おもむろに周りにエンティティを足していく、というわけです。

「プロダクト」

これはカタチは受動構造要素に似ていますが、実は複合 (Composite) 要素という、厳密にはビジネス・オブジェクトの「仲間」とはいえないものです。メタモデルを描くとこんな風になります。

このようにサービスや情報、モノ (Material) に至るまで、プロダクトとして集約することができます。契約もプロダクトに含められます。

プロダクトとはつまり、顧客がお代と引き換えに「財 (goods) や便益 (services) を使う権利」ですね。ですから本質的に契約同様「境界上の」要素になります。横文字だとオファリングというのが近そうです。また今風にユーザー・エクスペリエンス (UX) と言い換えても、当たらずとも遠からずでしょう。

しかしながら、オファリングやUXは、契約などとことなり、すでに定義されたものとして組織内に存在していることはまれでしょう。逆にいえば、それらを定義するのに、この「プロダクト」要素が使えます。例えばこんな風に。

一番上のステークホルダはカスタマーですね。カスタマーバリューがあり、要求があり、その下に抽象度高から低に要素を並べています。また、プロダクトは価値と繋がって価値を提案 (オファリング) します。一番下にプロジェクトの成果物が居ますが、DXとかAIとかのプロジェクトの成果物が、顧客向けプロダクトの実現に関わるとき、その表現に使えます。

以前ステークホルダはCxO、というお話をしましたが、ここまでくれば、カスタマーを外部のステークホルダーとして描く意味も出てきます。こういったカスタマーに近いところの構造を、もっとエンタープライズ・アーキテクチャ・モデルに取り込んでいくことが、今後ますます重要になるでしょう。内部構造はコストで、収益構造と一緒に見て、これらの差し引きで、アーキテクチャの価値が決まるわけですから。

「ノード」の仲間

「デバイス」と「システム・ソフトウェア」

これらは「ノード」の特化 (specialization) バージョンです。デバイスは物理、システム・ソフトウェアは論理の、それぞれコンピュータ環境なりリソース、と考えれば良いでしょう。

「デバイス」は以前触れたように、スマホやタブレット、ハンドヘルドスキャナ、もろもろのIoTデバイスなど「物理デバイスであること自体に意味がある」ものです。先にフローのところで示したレプレゼンテーションの例に、デバイスを加えるとこうなります。デバイスはプリンタなり、PCに限らずディスプレイが付いた何かのハード、ということになります。

システム・ソフトウェアはOS、ミドルウェア、DBMS、Webサーバなど様々です。クラウドだとEC2インスタンスが「ノード」、そこにあるLinuxやらMSSQLやらApacheやらが「システム・ソフトウェア」といった使い分けができます。Lambdaになるとシステム・ソフトウェアなのか、テクノロジー・サービスなのか、それはもう好みで良いのかも知れません。

システム・ソフトウェアは大抵「構造リレーション」を使って、ノードやデバイスにネストした形で描かれます。

「コミュニケーション・ネットワーク」と「パス」

コミュニケーション・ネットワークは「回線網」、パスはその上の「経路」です。簡単な絵に描くとこんな感じになります。

コミュニケーション・ネットワークA及びBはLAN、Cは加入回線で、回線事業者との契約が付いています。LANの構成には実際にはOSU、L2スイッチ、Wi-Fi、WANアクセラレータなどなど、いろいろな機器が含まれますが、モデルの要素としては持っておいて、必要に応じて (障害部位の説明など) ビューに登場させることになります。

パスはVLANやセグメントレベルのルーティングですね。具体的な中身にはノード (ホスト) 間の疎通のためのルータ設定情報が使えるでしょう。

リレーションについては、アサイメントを「ノードの居所」という意味で使っています。論理的にはパス、物理的にはLANが居場所である、ということです。もちろんノードはほかにもたくさんあるはずですが、これは例なので一個しか書いていません。あとは、加入回線は各LANに「使われている」、3つの物理ネットワークが「パスを実現している」、です。加入回線と契約は「関係している」です。

ネットワークがパスを実現している、について以前、この描き方だと「実現」にはどれかがあれば良い、という意味になる、というお話をしましたが、そのときの対象は「打ち手 (Course of Action) 」で、今回の対象のネットワークではORというオプションは無いのは自明なので、わざわざANDジャンクションを使う必要は有りません。教科書のサンプルではANDジャンクションが使われていますが、見た目が良いとも思えませんし、リレーション上余計なホップが一個増えるので個人的にはおススメしません。

パスはさらにデータフローに関連付けることが出来ます。前回のアソシエーションの例に加えてみましょう。

こうすれば、アプリケーションレベルのパスから論理ルーティング、物理ネットワークという依存関係が分かるようになります。重要なデータフローのパスが単一障害点 (SPOF) だったら、お金掛けてオルタナティブ・パスを確保しなければなりませんね。そういうのを済々と説明するのに使えます。

EA全体から見て、テクノロジー要素は「有って当然、動いて当然」で、インシデントはより抽象度の高い、ビジネスやモチベーション要素に直接ネガティブ・インパクトを与えます。老朽インフラが気になるかたは、ArchiMateでのモデリングをぜひ試してみて下さい。

後編の次回は、フィジカル・レイヤー、コンポジットその他の要素、またArchiのパレットにいる「ナゾの棒」をご紹介します。お楽しみに。