本記事の狙い
システム・アーキテクチャの設計を行ったことのある方であれば、多かれ少なかれ次のような悩みを持たれたことがあるのではないでしょうか。
- システムの全体像を俯瞰したいのだけれど、どう表現したらいいのだろうか？
- どう表現すればステークホルダーの利害関係をうまく引き出し、可視化し、トレードオフを議論できるのできるだろうか？
- システムが連携して動く仕組みをどう表現すれば、開発チームの間での齟齬や隙間での抜け漏れをなくせるだろうか？
- 現行システムの主要な業務・アプリ・インフラの間の対応関係を整理し、課題やあるべき姿を描きたいのだけれど、どう表現したらいいのだろうか？
これらの悩みの解決に役立つモデリング言語があります。ArchiMateです。
ArchiMateとは、エンターブライズ・アーキテクチャを表現するための記法として、The Open Groupが規格化したモデリング言語です。
例えば『アーキテクチャモデリング言語「Archimate」』の図を眺めていただければ雰囲気が分かると思います。
ArchiMateは使いこなせるようになると便利な道具なのですが、使いこなせるようになるまでの最初の一歩が辛いため、そこを手助けすることで、多くのアーキテクトに活用していただけたらと思い、この記事を書きました。
ArchiMateの活用ポイント
業務アーキテクチャをDFDや業務プロセス図を用いて分析していくことがあると思いますが、それらのプロセス指向の表現方法では、アプリとの関係性や業務が提供するサービスの観点といった事項を表現しようとすると、表現力が足りず苦しくなってきます。
この辺を補ってくれる記法がArchiMateです。
業務・アプリ・インフラという3層からなるアーキテクチャをまとめて表現できるほど表現力が豊かです。
もちろん、万能ではありませんので、UMLやER図、BPMN等とは次のように使い分けするといいといわれます。
- 業務・アプリ・インフラそれぞれのアーキテクチャの相互関係やステークホルダーの関心事を、必要に応じて塊にまとめつつ俯瞰してみるためにはArchiMate
- アプリアーキテクチャを深ぼりしたソフトウェア設計を記述するためにはUMLやERD等（ArchiMateでは表現できない観点が書ける）
- 業務アーキテクチャを深ぼりしたプロセス設計を記述するためにはBPMN等（ArchiMateよりも表現力がある）
（もっと言うと、ArchiMateを使えばIoTやスマートファクトリの対象になる物理設備や、実装〜移行のタスクも表現できますが、少しやりすぎかもしれません）
ArchiMateを記述するためのツール Archi
素敵なことに、ArchiMateを記述するためのツールには、Archiという無償のツールがあります（Windows/Mac/Linux用あり）。
しかし、そこには罠が・・・
「表現力が豊かで、無料で利用できるツールがあるなんて。なんて素晴らしいのだ。」と思われたかもしれません。
・・・が、そこには罠があります。
表現力が豊かすぎて、まず、ツールを開いた瞬間に表示される部品パレットのアイコンラッシュにたじろぎ（上図参照）・・・
それにめげずに、使い方を調べようと本家を眺めてみるものの規格特有の厳密だが初心者には理解が辛い説明ばかり（あと、欲しい資料はまず有料）・・・
インターネット検索に救いを求めるも概要以上の情報はなし・・・という状況に使いこなす自信を失います。
これに躓いて使わないのは勿体ないので、最初の一歩となる、凡例となる典型的な使い方について簡単に説明したいと思います。
（余談です）
私も一回自信を失い、そっとアプリを閉じたものの、よさそうな記法とツールだったので、めげずに頑張って乗り越えました。
その後、とあるアーキテクチャの議論のためにArchiMateを用いたところ、案の定、関係者から「図の記法が分からない。書くのはともかく読めない。」というツッコミを受け、凡例や典型的な使い方の説明資料を作成しました。
ArchiMateの仕様自体は公知のものですし、この説明資料を社内に留めておくのは勿体ないと考え、今回、一部公開したという次第です。
基本形は「S + V + O + インターフェース + 提供サービス」
ArchiMateにおけるエンタープライズ・アーキテクチャは次の3つの階層に分割されます。
- 業務アーキテクチャ
- アプリケーション・アーキテクチャ
- テクノロジー・アーキテクチャ（インフラストラクチャ・アーキテクチャと言った方が実際のイメージに近いでしょう）
（あれ、エンタープライズ・アーキテクチャにはデータ・アーキテクチャもあるのでは？と思われるかもしれません。どうも、全部の階層にデータに関する存在があり、他のアーキテクチャが水平分割であるとするとデータは垂直分割という扱いになっているようです。そもそも、データモデルの詳細な構造はERDやUMLに譲っているということもありそうです。）
この3つの階層で共通的に現れるパターンがあります。
そのパターンとは、「S + V + O + インターフェース + 提供サービス」という構造・振る舞いです。
| 構造・振る舞い | 定義すること |
|---|---|
| S | どのような存在が、 |
| インターフェース | どのようなチャネルやインターフェースで、 |
| 提供サービス | どのようなサービスを提供するのか、 |
| V | そのサービスをどのようなプロセスや機能で実現するのか、 |
| O | そのプロセスや機能はどのような情報を使用するのか |
ArchiMateでは、これらの構造と振る舞いを（業務アーキテクチャを例にすると）下図のように箱と線で構造化して表現します。
箱の形や右上のアイコンが「構造・振る舞い」の種類を表しています。
複雑？まだめげないでください。もう少しマシ表現方法があります。
このままだと色々な種類の線が入り乱れてて読みにくいため、箱を入れ子にすることで線を省略できます。
先ほどの図は、下図のように箱を入れ子にすることで少し見やすくなります。図の包含関係が、所属の上下関係になります。
ここでは業務アーキテクチャを例に基本的なパターンを見ました。
この基本パターンはアプリアーキテクチャやインフラアーキテクチャにも全く同等に存在します。
次の節では、基本パターン以外の箱と線について説明します。
一気に全体像へ
「S + V + O + インターフェース + 提供サービス」という基本的なパターンに加えて、各階層における特徴的な構造と振る舞いを説明するための特別な構成要素があります。
文章で説明していくと冗長になるため、図で説明します。
下図の箱間の相互関係を眺めてみていただければ、それら構成要素の意味が理解できると思います。
なお、箱の色でアーキテクチャの階層が表現されます。黄色い箱が業務、青い箱がアプリ、緑の箱がインフラです。
この図があれば、誰でもArchiMateを使いこなせるようになる（少なくとも読めるようになる）・・・はずです。
- 注意
- この図に現れているものは典型的な使い方であって、全ての可能な使い方が示されている訳ではありません。
- 間違いなどありましたら教えてください。
そして、次の一歩へ
え？説明されていない箱（戦略の領域や、システム化構想や要件の領域、開発と移行の領域、物理的設備の領域）が沢山あるって？
素晴らしいご指摘です。
今回は長くなり返って分かりにくくなるかと思い割愛とさせていただきました。
ご要望が多いようであれば続きの説明を書きます。
他にもIoTシステムの例としてLEGOで作るスマートロックのアーキテクチャをArchiMateで表現してみるかもしれません。
この辺を含むArchiMateの詳細な仕様や具体的な活用方法、実践する上でのパターンやアンチパターンなどについて知りたい方には、次の本をオススメします。
私はこの本を読んでArchiMateを使えるようになりました。ちょっと「高いなぁ」と思いながらも買う価値がありました。ArchiMateを直接使わないにしても、システム・アーキテクチャを分析・設計する上での観点を身につけるための教材としても利用できるいい本だと思います。
この記事がITアーキテクトを目指す方の一助となれば幸いです。
（つづく・・・かも）