エンタープライズアーキテクチャ

システムを業務課ごとにばらばらに調達してきた結果、同じデータを二重に持ったり、システム間の連携が場当たり的になったりする。EA（Enterprise Architecture）は、組織の業務、データ、アプリケーション、技術基盤という階層で全体像を描き、部分最適に陥らない整合のとれた姿（あるべき姿）へ近づける設計手法である。現状の構造を「現行アーキテクチャ」、目指す構造を「目標アーキテクチャ」として描き分け、その差を埋める移行計画を立てるのが基本の流れになる。自治体では、情報システムの全体最適化計画や情報化推進計画を立てる際の考え方として用いられ、標準化やクラウド移行の方向づけにも関わる。担当者にとっては、EAが個別システムの設計図ではなく、調達や更新の判断を貫く全体方針である点を押さえることが要点となる。

四つの階層

EA（エンタープライズアーキテクチャ）は一般に、業務（ビジネス）・データ・アプリケーション・技術基盤の四階層で組織の全体像を整理する。業務アーキテクチャは何の業務をどう行うかを、データアーキテクチャは業務が扱う情報の種類と相互の関係を、アプリケーションアーキテクチャはそれを支える情報システムの構成を、技術アーキテクチャはサーバー・ネットワークなどの基盤を表す。上位の業務から順に下位を設計することで、流行の技術ありきでなく業務に根ざした構造をとりやすく、どの業務がどのシステムで支えられているかの対応関係も見通せる。階層に分けることで、一部を変えたときの影響範囲も追いやすくなる。

現行と目標の差で計画を作る

EAでは、いまの状態を写した現行アーキテクチャ（As-Is）と、あるべき姿を描いた目標アーキテクチャ（To-Be）の両方を作り、その差分を埋める道筋を移行計画に落とす。これにより、なぜその調達や改修が要るのかを全体像のなかで説明でき、個々の調達が目標へ近づくものかを問える。場当たりにシステムを積み上げると、似た機能の重複や連携しない孤立システムが生まれるが、共通の目標像に照らして判断することでこれを避けられる。計画は一度作って終わりでなく、業務や技術の変化に合わせて目標像ごと見直していく。