 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||
|
||||||||||||||
| アーキテクチャの整理 | ||||||||||||||
|
本連載の第2回「ノンストップ稼動メインフレーム資産のマイグレーション 〜 大手鉄鋼会社の事例」では、対象システム全体のアーキテクチャを整理していく手法として、いわゆるEA（Enterprise Architecture：エンタープライズアーキテクチャ）的アプローチを試み、段階的にメインフレームをオープン化している事例を紹介した。 EAとは、狭義には「企業内のビジネスとITとに関連する構造（アーキテクチャ）を捉える枠組み」および「当該アーキテクチャを理想に近づけるためのテクニックとしての標準・基準体系」と定義される。広義にはその枠組みに基づき、現状の定義／理想像の策定／理想像の実現に向けたトランジションを推進するためのプロセスと組織体制／それらプロセスと組織体の総合的な取り組みを指す。 そういったことから、EAプロセスはレガシーシステム刷新プロセスの計画フェーズのタスクを一部含んでいる。レガシーシステム刷新プロセスのアーキテクチャ・デザインや開発テストフェーズ以降はEAプロセスのガバナンス対象、つまりアーキテクチャが標準に遵守されているかどうかのチェック対象となる。 EAの観点からすると、EAプロセスが先に実行され、その中のフェーズの1プロジェクトとして、レガシーシステム刷新プロセスがあるべきと整理される。つまり、レガシーシステム刷新プロセスでは、現状評価（アセスメント）の「システムアセスメント」や「ビジネスアセスメント」の一部（ハイレベル）の作業はEAプロセスで完了しているために、そのEAプロセスの成果物を参照するのが本来の姿ということになる。 |
||||||||||||||
| EAプロセスとレガシーシステム刷新プロセスの関係 | ||||||||||||||
|
図3に以上説明したEAプロセスとレガシーシステム刷新プロセス（LM）の関係を示す。EAプロセス個々の詳細説明は省くが、ここで対応させているプロセスは、一般に完成度の高いものと評価されているEAフレームワークであるTOGAF（The Open Group Architecture Framework）の「アーキテクチャ構築手法（ADM）」で定義されているものである。  図3：EAプロセスとLMプロセスの関係 （画像をクリックすると別ウィンドウに拡大図を表示します） EAの手法で最終的に整理作業を完了させるまでには非常に長い期間を要する。そこで現実には、過去のダウンサイジング事例を含めた実際のアーキテクチャ・デザインの経験からポイントを押さえたマクロ整理を行い、必要部分のみ詳細調査と分析を実施して、移行ロードマップを作成することになる。 その場合のポイントは、現在のITレベルを踏まえながらシステム構築計画の見直しに適宜対応できるように、アーキテクチャ・デザインにおける判断根拠を体系的に残しておくことである。当社ではこの進め方について、アーキテクチャを判断（デシジョン）するということから、アーキテクチュアル・デシジョン（Architectural Decision）と呼んでいる。 |
||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
