100日チャレンジ24日目です。
複雑化するシステムの根本原因は？
CIOともなればアーキテクチャでは悩まないかもしれません。
しかしながら単純なエラーやミスが進行なシステム障害を引き起こしたり、開発テストの長期化・高コスト化の根本原因を突き詰めていくと、標準化の徹底不足や個別の機能追加の結果システム構造が肥大化・複雑化していることがあります。
ITアーキテクチャの標準とは
大きくシステム構造とシステム要素の標準に分けられます。
システム構造の標準
データの処理方式
データモデルの標準
ミドルウェア製品の導入をルール化
システム要素の標準
ハードウェアやミドルウェアの種類、バージョンについての標準
これらを定めることで一貫性を保ち複雑化を防ぐことにつながります。
業務とシステムの全体構造 EA
エンタープライズアーキテクチャ(EA)は組織の目標、ミッション、事業運営、およびそれらを支えるシステムを可視化し、企業の業務とシステムの全体の見取り図を作成する方法論です。下記の4つの階層で規定されます。
クラウド時代のアーキテクチャ標準
2000年代にはEAを導入、検討した企業も多かったと思います。ERPパッケージからEAやSOAを軸にIT部門が業務プロセス革新をリードすることが求められました。しかし今はSaaSアプリが多く登場しユーザ部門で個別に使い始めることができるようになりました。IT部門や子会社に構築依頼するのに比べて柔軟で導入L/Tも短くコストも抑えられている気がするのは否めません。
ではアーキテクチャ標準は不要なのでしょうか。そんなことはないと思います。
ビジネス・アーキテクチャはアプリケーションに依存しませんし、業務データがどのシステムにどういうデータモデルで配置されているかを抑えておかないとデータを活用し切れなくなります。また部門ごとにバラバラのアプリケーションを使っていると組織変更にシステムがついていくことができません。またユーザにとってはクラウドであってもプロバイダに任せるものからプライベートの基盤を構築するものもあります。
アーキテクチャ標準もあわせて成長させていくことが重要です。そのためのアーキテクトの育成もしかりです。
