top of page

BTABoK/Architecture Lifecycleの紹介


今回はBTABoKのオペレーションモデルのひとつであるアーキテクチャライフサイクル(Architecture Lifecycle)についてのコラムです。




BTABoKでは冒頭で以下のようにArchitecture Lifecycleを紹介しています。


 アーキテクチャのライフサイクル、つまりアーキテクチャ開発ライフサイクル (ADLC) は、アーキテクチャがその開始から廃止までを通過する段階です。

ADLC は、アーキテクチャ開発のためのガイド プロセスを提供し、アーキテクトがアーキテクチャの状態を理解し、伝達するのに役立ちます。



  上図はADLCの段階を示しています。ADLCは、アーキテクチャが周囲の環境に合わせて発展・進化するための反復サイクルです。


ADLCのステージを以下に示します:

【イノベーションサイクル】

- ビジネスを変化させ、価値を得るための価値主導のアイデアの継続的なサイクル。これが継続的にアーキテクチャの進化を促します。

【戦略】

- 長期的なアーキテクチャの方向性を描き、ビジネスケースと課題の評価と優先順位付けを行う。その結果、アーキテクチャを開発するための要件が示されます。

【計画】

- 課題とアーキテクチャに関する要件が与えられ、アーキテクチャの基本的な設計図が作成されます。また、アーキテクチャ実務やチームは、アーキテクチャ変革を実現するために何が必要かという観点から評価されます。

【変革】

- 製品やソリューションなどの成果物を作成する際にアーキテクチャを使用し、スポンサーに期待価値を提供すること。これには、製品又はソリューションの開発中にアーキテクチャを改良することも含まれます。

【活用と測定】

- 成果物の配備後の実践におけるアーキテクチャの使用。これには、アーキテクチャがスポンサーに期待される価値を提供したかどうかを評価するための測定が含まれます。

【廃止】

- アーキテクチャの利用が一巡し、スポンサーに価値を提供しなくなった場合、アーキテクチャは廃止されるか、別のアーキテクチャに置き換えられます。


 ADLCは、アーキテクチャの継続的な改善を目指すサイクルであり、アーキテクチャの測定がさらなる革新のためのフィードバックを提供します。


さて、ここで登場する「スポンサー」とはだれを指すのでしょうか?

組織によりケースバイケースで、特定の人物ではないのでしょうが、その中のひとりはCIOと呼ばれる経営ボードでしょう。

CIOは情報システムのあるべき姿を維持、成長させることが使命のひとつとされています。そのためのアーキテクチャの継続的な改善を支えるADLCは、CIOにとっての有効で重要な手段となるでしょう。

また、スポンサーは、システムを設計し、構築するエンジニアたちでもあります。アーキテクチャの価値を一番身近に感じるのは彼らであり、ADLCはそのスポンサーであるエンジニアたちにも貢献することが求められます。

いづれにしても、ADLCを適用する際には、スポンサーの定義から行うことが重要となります。

さて、ADLCのステージの説明において、味わうべきは、アーキテクチャの【廃止】(廃止もしくは置き換え)のフェーズであります。

「当社にはアーキテクチャが無い」となげくCIOなど経営ボードがいますが、実際にはアーキテクチャが無いのではなく、良否はともかく描かれていないというのが実態と言えるでしょう。

現行AsIsのアーキテクチャを描いてみて、改善のサイクルを回すべきか、新たなイノベーションを起こし、現行のアーキテクチャは廃止し、新たなアーキテクチャに置き換えるべきかの決断から始めることが、求められます。そのうえで、ADLCを回していくことで、あるべきアーキテクチャに近づくことが出来るとBTABoKは主張しています。

BTABoKは、ADLCの必要性を以下のように述べています。


ライフサイクルが必要な理由

ADLCは、アーキテクトが高品質のアーキテクチャを開発するためのツール、成果物、プロセスを含む手法を提供します。ライフサイクルに標準的な段階を設けることで、アーキテクチャの開発におけるアーキテクト間の共通プロセスを提供します。アーキテクトがアーキテクチャの状況を伝え、ライフサイクルの各段階でアーキテクトに何が求められているかを知るのに役立ちます。


ライフサイクルは、アーキテクトがライフサイクルの適切な段階において、順序立ててアーキテクチャ活動を行うことを支援し、アーキテクチャ開発におけるプロセスの伝達方法を提供します。


ADLCそのものを開発することで、アーキテクチャ業務にアーキテクチャ開発の標準的な作業方法を取り入れることができます。これは、アーキテクチャ実務の反復的かつ継続的な改善を促進し、ガバナンスの基盤にもなり得ます。


 ADLCを適用することで、自社のアーキテクチャをあるべき姿にし、そして情報システムを優位性のあるものとし、経営基盤を支えていくことになるでしょう。

 自社のアーキテクチャの存在があいまいな状態の組織においては、道は遠いとも感じるかも知れません。しかし、まずは、あるがままに現行システムのアーキテクチャを描き、客観的に評価し、ADLCによりアーキテクチャを管理していくことで、情報システムの見える化が実現されます。重ねて申し上げますが、これが、経営戦略に基づいた情報システムとなり、いわゆるDXの実践に向かうことを可能にするのではないでしょうか?

 ADLCは、活用してこそ価値があるものです。是非、原文を参考に適用を検討してみてください。

 BTABoK/Architecture Lifecycleの原文は以下のサイトを参照ください。

 

IASA日本支部では、BTABoKの解説セミナーなどを定期的に行っています。

詳細については、https://www.iasa-japan.org/eventを参照ください。

奮ってご参加されることを願っております。よろしくお願いいたします。

以上

閲覧数:32回0件のコメント

最新記事

すべて表示

[TABoK紹介シリーズ] "Information Usage"仮訳

BTABoKといえば「エンゲージメント・モデル」ですが、その前身であるITABoKといえは「5つの柱と4つの専門領域」でした。もちろん現在もこれらは全て「コンピテンシー・モデル」としてBTABoKに受け継がれ、さらに加筆修正、新たな項目の追加が随時行われています。今回はBTABoKの「インフォメーション・アーキテクチャ」コンピテンシー・モデル、つまりITABoKでいうところの「インフォメーション・

bottom of page