エンタープライズアーキテクチャツールの選び方:自社に合う製品を見極める
用途別にエンタープライズアーキテクチャツールを比較し、プロセスデータで実態を確かめる方法を紹介します。
エンタープライズアーキテクチャツールは、組織のケイパビリティ、アプリケーション、データ、プロセスを可視化し、それらの関係を把握するためのものです。必要なのが資産の一覧、標準やロードマップの管理、それとも業務の実態を示すデータなのかによって、適したツールは異なります。
リポジトリでは、何を保有し、どのように連携させる想定なのかを確認できます。ただし、従業員がシステムやプロセスを使うときに何が起きているかまでは、必ずしも分かりません。
この隔たりは、アーキテクチャを保守する人たちの責任ではありません。業務は変化し、文書は古くなります。また、静的なモデルだけでは示せない実態が、業務システムには記録されています。
エンタープライズアーキテクチャツールの用途
エンタープライズアーキテクチャツールは、組織とその構成要素の関係を記述するためのものです。主に、次の3つの用途があります。
- **在庫情報:**ケイパビリティ、プロセス、アプリケーション、データ、担当者、依存関係を記録します。
- **標準とロードマップ:**TOGAFやArchiMateなどのフレームワークを使い、変更案を評価し、現在の状態から目標の状態への移行を計画します。
- **分析:**組織の業務の進め方や、変更が及ぼす影響を把握します。
リポジトリを使えば、あるケイパビリティを支えるアプリケーションや、特定のシステムに依存するプロセスなどを確認できます。また、変更についてチームで話し合う際の共通用語にもなります。
ただし、アーキテクチャリポジトリだけで、業務の実態が分かるわけではありません。プロセス名、担当者、説明だけでは、例外経路をたどるケースの頻度、待ち時間が発生する箇所、承認が繰り返される回数までは把握できません。
この違いが、以降の比較の軸になります。リポジトリツールは、保有するものと実行する予定の内容を記述します。一方、ProcessMindでは、システムのデータから実際に起きていることを確認できます。
エンタープライズアーキテクチャソフトウェアの比較ポイント
ベンダーのページに掲載された機能だけでなく、必要な業務を支援できるかどうかを基準に、エンタープライズアーキテクチャソフトウェアを比較しましょう。
- **リポジトリとメタモデル:**回避策を使わずに、ケイパビリティ、複数階層のプロセス、アプリケーション、データ、各要素の関係を表現できますか?
- **フレームワークへの対応:**ArchiMateやTOGAFに製品として対応していますか?それとも、主に図表作成用の要素を提供していますか?
- **プロセスの詳細度:**上位のプロセスから、サブプロセス、アクティビティ、ゲートウェイ、バリアントまで確認できますか?複数の階層でプロセスをどのように表現できるか、デモを依頼しましょう。
- **データ連携:**すべてを手作業で更新するのではなく、アーキテクチャの一部を業務データで更新または確認できますか?
- **共同作業と権限:**チームで作業を追加、レビューできますか?編集ライセンスを持たない人もリポジトリを閲覧できますか?
- **ホスティングとデータ保管場所:**データの保管場所とアクセスできる人を確認し、要件を満たしているか確かめましょう。
- **相互運用性:**アーキテクチャをエクスポートし、APIやオープン形式を利用できますか?作成したものを持ち出せることが大切です。
- **ライセンス:**編集者、レビュー担当者、閲覧専用ユーザーのライセンス体系を確認しましょう。中核チームだけでなく、アクセスが必要な全員分の総費用を比較してください。
プロセスの詳細度とデータ連携には、特に注意を払いましょう。ケイパビリティマップは計画に役立ちますが、従業員が実行するプロセスと結び付けられなければ、改善につなげにくくなります。
モデルの保守方法、プロセス階層をどこまで確認できるか、情報をデータと照合できるかをベンダーに確認しましょう。回答から、プロセスレイヤーの運用まで支援できるのか、記録にとどまるのかが分かります。
こうした点を確認することで、必要なのがエンタープライズアーキテクチャリポジトリなのか、プロセスの実態を示すデータなのか、あるいはその両方なのかを判断できます。
用途に合ったエンタープライズアーキテクチャツールの選び方
エンタープライズアーキテクチャツールには、種類ごとに異なる用途があります。機能の数ではなく、必要な業務から比較を始めるとよいでしょう。以下の表では、8つの確認項目を各カテゴリに当てはめ、最後にProcessMindを掲載しています。
| 確認項目 | リポジトリ中心のEAスイート | EA管理プラットフォーム | 図表作成・ArchiMateツール | ITSM・プラットフォームのモジュール | ProcessMind |
|---|---|---|---|---|---|
| リポジトリとメタモデル | 幅広いアーキテクチャリポジトリ | アプリケーションとケイパビリティの在庫情報 | モデルと図表 | より広範なプラットフォーム内のアーキテクチャビュー | バリューストリームからアクティビティまで、設定可能な階層でプロセスアーキテクチャを構成 |
| フレームワークへの対応 | フレームワークとガバナンスの実務 | アーキテクチャ管理機能 | 図表作成の標準が中心となることが多い | プラットフォームのモジュールによって異なる | 業務の実態に沿ったバリューストリームとプロセス階層 |
| プロセスの詳細度 | リポジトリの機能は設定によって異なる | アプリケーションとケイパビリティが中心となることが多い | 図表レベルの詳細 | モジュールによって異なる | BPMN 2.0モデルで、各階層のアクティビティ、ゲートウェイ、バリアントを表現 |
| データ連携 | 統合方法と導入内容によって異なる | 在庫管理に対応。必要なデータ要件を確認 | 通常はモデルの更新に依存 | プラットフォームと設定によって異なる | イベントデータをモデルに接続し、プロセスの流れを確認 |
| 共同作業と権限 | アーキテクチャチームとガバナンス向けに設計 | エンタープライズアーキテクチャ管理に対応 | ツールと導入方法によって異なる | プラットフォームの権限を使用 | RACIの担当設定、ガバナンスワークフロー、閲覧者ポータル |
| ホスティングとデータ保管場所 | ベンダーと導入方法によって異なる | SaaS方式 | ツールによって異なる | プラットフォームによって異なる | フランクフルトのEU域内でホスティング |
| 相互運用性 | エクスポートと統合の要件を確認 | エクスポートと統合の要件を確認 | 対応形式を確認 | プラットフォームの統合方法を確認 | BPMN 2.0のインポートとエクスポートに対応し、標準XML形式でモデルを移行可能 |
| ライセンス | ロールとアクセス要件を比較 | ロールとアクセス要件を比較 | ツールによって異なる | プラットフォームのライセンスに含まれることが多い | シート単位の料金プランを公開。無料プランに加え、有料シート1つにつき閲覧者用シート10席が無料 |
Software AG ARIS、Bizzdesign、MEGA HOPEX、Orbus iServer、Sparx EAなどのリポジトリ中心のEAスイートは、アーキテクチャリポジトリ、フレームワーク、ガバナンス、ポートフォリオ管理向けに設計されています。正式なアーキテクチャプログラムを運営する権限とキャパシティがある組織に適しています。
SAP LeanIXなどのEA管理プラットフォームは、アプリケーションやケイパビリティの在庫情報をSaaSで管理できます。アプリケーション全体を把握し、体系的にエンタープライズアーキテクチャを管理したい組織に適しています。
図表作成・ArchiMateツールは、主にモデルの作成と共有が必要な場合に適しています。Archiは無料のオープンソースで、ArchiMateに標準対応しています。Visioを使ってアーキテクチャを文書化する方法もあります。リポジトリ、共同作業、ガバナンスの機能が要件を満たすか確認しましょう。
ITSM・プラットフォームのモジュールは、すでに利用しているシステムと並べてアーキテクチャビューを管理したい場合に適しています。モデリングの詳細度とリポジトリ機能が、アーキテクチャ管理の要件を満たすか確認しましょう。
ProcessMindは、異なる問いに答えます。業務はどのように進み、業務データには何が記録されているのでしょうか。バリューストリームとプロセス階層を、システムにすでに記録されているイベントデータに結び付けます。これにより、従業員が行うアクティビティまでアーキテクチャを確認し、実際の業務と照合できます。
どのカテゴリにも、すべての用途に適した唯一のツールがあるわけではありません。まず、必要な業務に合うツールを選びましょう。主な関心がプロセスの動きにある場合は、プロセスレイヤーのデータから始め、アーキテクチャプログラムで必要になった段階でリポジトリを追加できます。
エンタープライズアーキテクチャが実態とずれる理由
リポジトリの更新が手作業に依存し、モデルが記述対象の業務から離れていると、エンタープライズアーキテクチャは実態とずれていくことがあります。
ずれが生じやすくなる構造的な要因は、次の3つです。
- **リポジトリを手作業で保守します。**プロセス、アプリケーション、担当者の変更を入力し、レビューする必要があります。
- **効果が表れるまで時間がかかることがあります。**正確な在庫情報が必要になるのは将来の監査や影響分析のときでも、更新作業は今すぐ発生します。
- **モデルが示すのは意図であり、実際の動作ではありません。**文書化されたプロセスだけでは、実際のケースで発生する手戻り、例外、引き継ぎ、待ち時間が分からないことがあります。
ケイパビリティマップやアプリケーションの在庫情報は、組織の全体像を把握するのに役立ちます。しかし、ケイパビリティやアプリケーションの階層で止まるモデルでは、現場の人が日々の業務を思い描けないことがあります。
違いは、プロセスのバリアント、引き継ぎ、繰り返される承認、待ち時間などの詳細に表れます。リポジトリには予定されたプロセスを記録できますが、その説明が業務の実態と一致しているかを確認するには、別のデータが必要です。
誰にも実態が分からないアーキテクチャは、2つの問題を引き起こします。モデルでは承認が1回とされているのに、実際には3回必要だとチームが知っている場合、モデルは参照されなくなります。あるいは、監査前に更新されるだけで、その間は使われないコンプライアンス上の記録として残ります。どちらもツールの問題ではなく、モデルと業務の隔たりが原因です。
ガバナンスを改善すれば、リポジトリを適切に保守しやすくなります。しかし、それだけではモデルと実態が一致していることを独立して確認できません。プロセスモデルを業務データに結び付けることで、そのレイヤーを確認できます。
アーキテクチャを現場の業務につなげる方法
業務の現場に即した詳細を示すことで、チームがアーキテクチャを自分たちの業務として捉えやすくなり、業務データとの照合も可能になります。
ケイパビリティマップは、組織が何を行う必要があるかを示します。プロセスモデルでは、業務の進め方、担当者、サブプロセス間の関係を表現できます。各階層を明確につなげるほど、アーキテクチャの全体像と、その中で表現される業務を行き来しやすくなります。
イベントログには、完了したケースのデータが記録されています。どのアクティビティがどの順序で発生し、ケースにどれだけの時間がかかったかを確認できます。そのデータをプロセスモデルと比較すれば、観測された動作が文書化された経路と異なる箇所を特定できます。
ただし、エンタープライズアーキテクチャのすべてをイベントデータから導き出せるわけではありません。ポートフォリオの決定、標準、目標の状態に関する選択には、引き続きアーキテクチャの実務とガバナンスが必要です。データはプロセスレイヤーの根拠にはなりますが、リポジトリ全体の代わりにはなりません。
業務の現場に即したプロセスの詳細があれば、どちらの問題も防ぎやすくなります。アーキテクチャにアクティビティ、引き継ぎ、待ち時間まで示されていれば、チームはモデル上で自分たちの業務を確認でき、担当者は自らが責任を負う判断を把握できます。EAツールはポートフォリオを管理できます。そのポートフォリオを実現する人々につなぐのは、実際の業務です。
データがあれば、レビュー担当者が確認できる根拠を示せます。モデル上の待ち時間はログ上の待ち時間と一致するはずです。一致しない場合は、図表ではなくプロセスについて話し合えます。そのほうが、さらに更新を重ねるよりも有意義です。
作業の進め方も変わります。まずリポジトリを完成させ、後から詳細が加わることを期待するのではなく、1つのプロセスを測定して上位階層につなげ、確認できる範囲でモデルへの信頼を築きます。最初の対象を絞れば、無理なく完了でき、計画だけでなく実際に機能する事例をアーキテクチャプログラムに示せます。
プロセスアーキテクチャの文書化では、プロセス階層とその関係の表現方法を確認できます。データについては、プロセスマイニング用のイベントログの作成方法をご覧ください。
TOGAFへの実践的な入り口は、バリューストリームマッピングですか?
TOGAFでは、バリューストリームとケイパビリティマップを含むビジネスアーキテクチャを定義します。このレイヤーの構築には、バリューストリームマッピングを使います。バリューストリームをマッピングし、その下位のプロセスをつなげ、測定した業務データで実態との一致を確認します。Process Architectureのプランでは、バリューストリームを起点にしています。組織内で価値がどのように生み出されるかと、アーキテクチャを結び付けやすくなるためです。TOGAFプログラム全体では、このレイヤーを取り巻く標準委員会やガバナンスの年間計画も必要になりますが、モデルの構築はここから始められます。
ProcessMindが異なるアプローチでアーキテクチャに取り組む理由
ProcessMindは、データで実証できる部分からアーキテクチャに取り組みます。これは意図的に異なるアプローチであり、リポジトリの機能を小さくしたものではありません。
TOGAFについて検討しましたが、データに基づいて運用し続けるのは容易ではありません。そこで、現時点では測定と実証が可能な部分に注力することにしました。プロセスの効率化によって最も大きな価値を得られるのも、その部分です。
ポートフォリオ管理、アプリケーションのライフサイクル、標準のガバナンスは、リポジトリが得意とする領域です。ARIS、SAP LeanIX、Bizzdesign、MEGA HOPEX、Orbus、Sparxは、こうした業務を適切に支援します。ProcessMindは、プロセスレイヤーに取り組みます。
ProcessMindは、バリューストリーム、設定可能なプロセス階層、RACIによる担当設定、ガバナンスワークフロー、閲覧者ポータルからなるプロセスレイヤーに注力し、イベントデータと接続します。このレイヤーだけでプロセスに関する問いに答えられます。また、アーキテクチャプログラムでリポジトリが必要な場合は、自然に併用できます。
エンタープライズアーキテクチャツールの選び方
チームが答えを必要としている問いと、ガバナンスの対象となるアーキテクチャ業務を基準に選びましょう。
- **ポートフォリオ管理、標準、ロードマップが必要な場合:**リポジトリを保守するための人員とプロセスを計画したうえで、フル機能のEAスイートを候補に加えましょう。
- **アプリケーションとケイパビリティの在庫情報をSaaSで管理したい場合:**SAP LeanIXなどのEA管理プラットフォームを、在庫情報とガバナンスの要件に照らして評価しましょう。
- **プロセスの実態を把握したい場合:**プロセスモデルと業務データから始め、より広範なリポジトリも必要かどうかを判断しましょう。
- **まだ決めかねている場合:**チームからよく寄せられる質問を整理しましょう。リポジトリ、プロセスの実態を示すデータ、またはその両方のどれから始めるかを決める助けになります。
リポジトリ中心のツールを比較している場合は、ARISの代替ツール比較をご覧ください。モデルとデータの連携方法を検討している場合は、プロセスモデリングとプロセスマイニングの相互補完についてお読みください。
まずはデータで実態を確認できるところから始めましょう。アーキテクチャプログラムで、より広範なガバナンスやポートフォリオ管理が必要になった段階で、リポジトリを追加できます。
ProcessMindの位置付け
ProcessMindは、業務の実態を示すデータとアーキテクチャをつなぐ、プロセスとバリューストリームのレイヤーです。
リポジトリがポートフォリオと標準を管理するのに対し、ProcessMindはプロセスレイヤーと、それを裏付けるデータを管理します。両方を利用するチームは、プロセスの詳細を確認できるアーキテクチャを実現できます。プロセスレイヤーだけが必要なチームは、それ単独で利用できます。
プロセスを設定可能な階層に整理し、BPMN 2.0でモデル化して、RACIによる担当者の割り当てができます。ガバナンスワークフローと閲覧者ポータルも利用できます。また、プロセスモデルをイベントデータに接続し、文書化されたプロセスと観測された動作を比較できます。プロセスシミュレーションを使えば、本番環境のプロセスを変更する前に、モデル上で変更の影響を確認できます。
ProcessMindのプロセスアーキテクチャ機能について詳しくは、エンタープライズプロセスアーキテクチャのページをご覧ください。プロセスガバナンスとプロセスマイニングとは何かについてもご紹介しています。
Where to Go From Here
You need process architecture that reaches the level teams work at and can be checked against operational data.