Brown氏とSeal氏の Software Architecture Document Guidelines v0.1 は以下のことを提供することを目的にしている。
1. ソフトウェアアーキテクチャの概要についての記述方法。これには主要なソフトウェアコンポーネントやそれらの相互作用も含まれる
2. 設計から実装までの間用いられるアーキテクチャ上の原則についての共通認識
3. システムが構築されデプロイされるハードウェアおよびソフトウェアのプラットフォームについての記述方法
4. そのアーキテクチャがどのように非機能要求を満たすかを明確にする方法
15項目から成るこの文書の各項には、そこに該当する事柄についての簡単な説明や例、そしてアーキテクトのためのチェックリストが書かれている。このガイドラインは二人がQCon London 2008で発表したチュートリアル(source)の一部として作ったもので、PDF形式で配布されている(PDF・英語)。
Mike Kavis氏は「私が読むほとんどの記事では2つの決定的要素について議論されています。つまりテクノロジと管理です。しかし変更を管理することについて話をしている人はまだ多くありません」と語る。彼はJohn Kotter著”Winning at Change”にある8つのステップ(source)を使い、エンタープライズアーキテクチャやSOAが浸透していく中で起きる変化にアーキテクトがどのように対応すればいいかを説明する。彼がアーキテクチャプロジェクトに適用してきた8つのステップは以下のことだ。
1. 投資対効果をきちんと検討しそれを書面にするMike Kabis氏は確かな投資対効果検討書を作るにはビジネスプロセスにフォーカスするべきだという見方を示した。
2. 最重要スポンサやトップレベルの株主を保護する
3. ロードマップをつくる
4. ロードマップを公表する
5. ロードマップに沿って他の人が行動できるようにする
6. 小さく始めて早く頻繁に（つまりアジャイルに）リリースする
7. 大きくし、再利用をおこなう
8. 管理する
BPM（継続的なプロセス改善による経営改善法）に対する必要性を経験したことで、彼の組織はSOAとBPMにおいて主導的な立場を手にすることができた。私たちはSOAについて専門用語を使ったりはしませんでした。私たちが述べたのは”新しい”テクノロジを利用すれば、バックエンドシステムを書き直すことなく契約から出荷までのワークフロー全体を自動化できる、ということでした。そして、この新しいテクノロジは”変換技術”を通じて新しいウェブベースのシステムと既存のシステムをつなぐことが可能になると述べたのです。もちろん、この”変換技術”とはサービスのことです。
原文はこちらです：http://www.infoq.com/news/2008/03/architect-resources