「振る舞い」をモデル化する

角が丸いか四角いか

前回の記事で、手始めにこんなモデルを描いてみました。

この二つの四角をよく見ると、Resourceのほうは角が四角くて、Capabilityのほうは角がまるくなっています。

ArchiMateでは、四角い角を「構造要素 ("Structure Element")」、丸い角を「振舞い要素 ("Behavior Element")」と呼んでいます。構造要素は、静的・スタティックな、「在る」「モノやヒト」を、そして振る舞い要素は、動的・ダイナミックな、「やる」「コト」を、それぞれ抽象化したもの、といえば伝わるでしょうか。

振舞い、または日本語でもしばしばビヘイビアと呼んだりします。上のモデルの例は、ケイパビリティというビヘイビアですね。ビヘイビアの名前にはだいたい動名詞が使われます。英語だと～ingが付くヤツですね。また日本語なら「～する」と付けておかしくないのが動名詞ですね。

例えば、マーケティングはingで終わるのでビヘイビアですね。マーケティング・ケイパビリティって言いますよね。

日本語なら「商品開発」などどうでしょう。商品開発「する」ですね。商品開発のケイパビリティです。

一方、角が四角い「構造要素」は「振る舞いの主体」だったり、あるいは「振舞いの対象」だったりします。簡単に言えば、前者は「人」とか「システム」、後者は「データ」「情報」です。前者の構造要素は特に「能動構造 ("Active Structure")」、後者は「受動構造 ("Passive Structure")」と呼ばれます。これらの能動・受動両方の構造要素をひっくるめた、より抽象度の高い表現が「リソース」要素です。

構造要素の突っ込んだ説明は次回に譲るとして、今回はまず振舞い要素にフォーカスしてみましょう。Archiが使える方は、実際に操作しながら読み進めてみて下さい。

レイヤー違いでも同じ振る舞い

パレットには沢山の要素のタイプがありますが、よく見ると、同じシンボルが複数あることに気づきます。とりあえず同じシンボルのものをビュー上で縦横に並べてみましょう。

どれも英単語二つの組み合わせですね。縦並びがビジネス、アプリケーション、テクノロジなどで、これらをレイヤと呼びます。

ビジネス・レイヤはシステム化されている・いないに関わらず、ビジネスのためにやっていることですね。

アプリケーションとテクノロジのレイヤは、いわゆる「機能要件」と「非機能要件」で切り分けるのがわかりやすいでしょう。

一番下のインプリイベントは「導入と移行」レイヤーに属します。

プロセス、ファンクション、イベント、インタラクション、サービスの振舞い要素は3つのレイヤーに共通しています。最初にご紹介した振舞い要素であるケイパビリティは「戦略」レイヤーにのみ存在します。

ちなみにレイヤーの色分けですが、これは慣例的なもので、ArchiMateでは色についての決まりは定められていません。前回のCSVデータでもわかるように、モデルのデータには色という項目はなく、同じひとつの要素に違う色を塗ることもできます。差し当たりはツールのデフォルトのカラースキームに任せることにしましょう。

それではこれらの16個の振る舞い要素について、意味や使い方を見て行きましょう。

イベント

まずカンタンなところで、真ん中のイベントから行きましょう。イベントとは何かの状態が非連続に遷移して、それが後続の何かの振る舞いをトリガする、そういう出発点です。

ただ、エンタープライズ・アーキテクチャの観点からだと少々具体的過ぎで、書き始めるとキリがなくなったりするものなので、今のところは意味だけ押さえておけば十分です。

例だけ挙げておくと、ビジネスイベントだと「新製品のローンチ」、アプリイベントだと例えばワークフロー上の「承認された」とかのイベント、テクノロジイベントだと監視のアラートなどが考えられますね。

一番下にインプリ・イベントというのがあります。これは「導入と移行」レイヤーの要素で、プロジェクトによってエンタープライズ・アーキテクチャ上で生じる状態変化です。ですから上3つと違い、明示的な期日を伴いますし、イベントの発生も一度きりです。「導入と移行」レイヤーについては稿を改めてご紹介します。

プロセスとファンクション

それではつぎに、左側をみてみましょう。プロセスとファンクションですね。日本語ではどちらも同じような意味にとれますが、違いは何でしょうか。

ArchiMate標準には何やら難しい説明が書いてありますが、ここでは継続事業を描く上での現実解にフォーカスしましょう。個人的におススメしたいのは、ファンクションが「管理」、プロセスが「処理」という解釈です。

例えば「販売管理」というのは、管理 (マネージ) する機能だからファンクション、というわけです。そこには「受注取込処理」とか「在庫引当処理」とか「出荷請求処理」といった、オペレーショナルな処理、つまりプロセスが含まれている、という見立てです。

アプリケーションも同様、パッケージやERPのモジュール単位の切り分け、例えば買掛管理、とか在庫管理、とかがファンクション、モジュールに含まれる業務メニュー、例えば入金引当、とか保管場所移動、とかがプロセス、といった見立てが出来ます。

テクノロジーなら、いまならさしずめCI/CD管理とか、プロビジョニング管理などがあって、その下に個別の様々な処理プロセスがぶら下がる格好になるでしょう。

プロセスは粒度的にイベントに近く、つまりこれも書き始めるとキリがなくなる心配があります。言ってみればファンクションは部長さん、プロセスは課長さん、といったレベル感で、まずは部長さんレベルの仕事を描いてみるのが良いと思います。

サービス

続いて、右端のサービスについて考えてみましょう。サービスといってもいろいろですが、エンタープライズ・アーキテクチャでは「重要性」に注目しましょう。重要なサービスとは一般的に、それに対して直接に対価が発生する、または対価が無くとも、例えばプライバシーポリシーなどの権利義務を伴う、といったものでしょう。そういうサービスを特定してゆけば良いわけです。

ビジネス・サービスなら、約款や約定といったものがつきものでしょうし、アプリケーション・サービス、テクノロジー・サービスはそれぞれSaaSやPaaSとしてSLAなどが存在するでしょう。

サービスは、自組織が提供するものはもちろんのこと、自組織の外部から提供されるものも、自組織のモデルに含んで構いません。そしてそこが、サービスの向き (インバウンド・アウトバウンド) に関わらず「継続事業」と「外部環境」との境界になるわけです。

インタラクション

最後はインタラクションです。ビジネス・レイヤーだと、異なる部署が参加する会議の「議題」をイメージすると良いでしょう (「会議体そのもの」は別の概念要素があり、別途ご説明します)。例えば販売と生産とで「PSI計画の策定」などが、ビジネス・インタラクションに当たります。とりあえず「部長さん以上が出席している大事そうな会議でやっていること」を挙げて行けばよいわけです。

アプリケーションレベルのコラボレーションでは、複数のアプリがAPI連携などでひとつの機能を実現していたりします。テクノロジー・レイヤーでは、何らかのテクニカルな機能が、複数のクラウドやプラットフォームで実現されていれば、それがインタラクションということになります。

ただし、アプリケーションとテクノロジーレイヤのインタラクションは、ビジネスの「会議」のように独立した概念として知覚できるケースはまれでしょう。ですので少なくとも最初のうちは出番は多くないのではないかと思います。

---------

今回はArchiMateの振る舞い概念にどのようなタイプがあるか、またそれを現実の事業を構成する要素にどのように当てはめ、概念化すればよいかについてご紹介しました。「面白そう！」と思われた方は、ぜひチャレンジしてみて下さい。何か新しいものを作るわけではなく、今そこにある事実を写すだけなので、ネタとして手に入りそうなもの、例えば業務フローなどがあれば、すぐに始めることが出来ます。

次回はArchiMateの構造要素をご紹介します。お楽しみに。