アーキテクチャライフサイクルマネジメント

ふっと年末から考えているのだが，システムやソフトウェアのアーキテクチャが，そのアーキテクチャを持った製品のライフサイクルと異なる周期で動くものであるならば，アーキテクチャそのものもが「ライフサイクルプロセス」を持っていて良いのでは無いか？特に，Product Line開発を狙うなら，アーキテクチャそのものがライフサイクルを持つ，という捉え方をするのが適切なのでは無いかと考えている．
このアーキテクチャのライフサイクルは，多分，以下の４つのプロセスから構成される．

1. 企画・要求定義：アーキテクチャに対する要求を定義して，アーキテクチャ開発を企画する活動．技術動向や，組織として売り物としたいコアコンセプトのようなものを具体化して共有するための活動を行うフェーズ．ポイントになるキーワードは，品質要求になるはず．また，なぜそういうアーキテクチャにして置くかを考えるためには，もっと上流のビジネス要求等も具体化して置かないといけない気はする．
2. 開発：アーキテクチャを具体的に開発し，アーキテクチャに対する要件を満たしているかの妥当性を確認する（Validateする）までの活動．このプロセスエリアには，基本的にISO 12207 SLCPの方式設計の活動を割り当てる．既存のアーキテクチャのどこを変更するか，アーキテクチャのどの部分を新規開発するか，なんて話も，もちろん，アーキテクチャを設定する活動の一環として，この「開発」プロセスに入れて置くことになるはず．
3. 保守・運用：アーキテクチャを維持し，これを利用するフェーズ．ここは，個々の製品に対する要求に応えるように，アーキテクチャを維持し，あるいは変更範囲を具体化する活動を割り当てる．
4. 廃棄：アーキテクチャは，ある限界を超えると，それ以上の保守・運用に膨大なコストをかける必要が出てくる．大抵の場合，こうなったら，そのアーキテクチャをそれ以上使いまわすのは，経済的に損になる．こう言う時には既存のアーキテクチャを廃棄する必要があると思う．具体的には，廃棄の条件を予め設定して置き，この条件に達したら実際にアーキテクチャの廃棄を判断し，そして最後に次のアーキテクチャへの移行を計画する．こうした活動を無視しちゃいけないと思う．ISO 15288にある廃棄の考え方に近いが，実現方式の廃棄なので物理的な廃棄は存在しない．という点は注意が必要かもしれない．

各プロセスをより具体化して行くと，アーキテクティングという活動の全体像が説明できるようになるんじゃ無いかと思うんだが，どうだろう？もちろん，SLCPにある支援系の活動は，同様にアーキテクチャライフサイクルプロセスでも必要になると思うけど．ここには構成管理，要求変更管理，検証，妥当性確認，文書化等の活動を割り当てる．これくらいの活動の枠組みでアーキテクティングという活動を捉えて見ると，大体世間で言われていることや活動が整理できるんじゃ無いかな...と連々と考えて見た．