アジャイルプロジェクトのプロジェクトオーナは，おもにビジネスとITのコネクションを確保する役割だと受け止められがちだ。しかし，ITとビジネスの効果的なアライメントのためには，プロダクトオーナでは不十分だ。組織のビジネスやデマンド，サプライといった役割の人々は，ITとビジネスのアライメントの効果を高めるために何ができるだろう？
OrdinaのKlasien Postma氏はAgile and Software Architecture Symposium 2014で，"Agile projects do not yield an effective IT business alignment"と題したプレゼンテーションを行った。講演の中で氏は，どのようなアーキテクチャ資料がいつ必要かを決定するために，リーン思想を用いる方法を示し，多くのプロジェクトにおいて，アジャイルプラクティスがITチームにのみ利用されることの多い理由を議論した上で，ビジネスやデマンド，サプライに関わるステークホルダたちをアジャイルプロジェクトにより深く関与させる方法についての提案を行った。
氏は，司法評議会やオランダ税務当局といった政府機関において，アーキテクチャに関するさまざまな役割を務めた際の，自分自身の経験について発表した。これらの組織で氏が見た傾向は，限定的なオフィスへの中央集権化，共有サービスセンタを用いた専門化，ITガバナンスに対する関心の高まり，といったものだ。
司法評議会では２種類のチームを使用していた。ビジネスバリューを重視するチェーン志向チームの製品開発チームと，プロジェクトを越えたスコープでの品質と再利用性を重視するコンポーネント志向のサービス開発チームである。チームはそれぞれ，作業を管理するためにいくつかのバックログを用意して，他チームとのコラボレーションを行っていた。
氏は，どのようなアーキテクチャ資料がいつ必要か決定するために，リーン思考ベースの質問をいくつか用意した。
- 資料が必要なのは誰か？
- なぜ必要なのか？
- その人にとっての価値は何か？
- 資料がなければどうなるのか？
利用可能なアーキテクチャ資料はさまざまだ。長期計画にはドメインアーキテクチャが利用可能である。プロジェクト開始アーキテクチャはプロジェクトの立ち上がりをサポートする。さらに，アーキテクチャコントロールと変更管理を備えたソリューションアーキテクチャは，スプリント中に使用することができる。
デマンドとサプライ，ビジネスがパートナとしてコラボレートできないのには理由がある，と氏は言う。
- ユーザは同僚ではなく，顧客として扱われる。
- サプライはビジネスパートナとは考えられていない。
- 先入観が多すぎて，十分に信頼できない。
講演で氏は，ビジネス-ITアライメントをより効率的なものにするため，それぞれのステークホルダに対して提案をしている。ビジネスに対しては，自動化が自らの問題であることを認識すること，自動化のプロセスを掘り下げること，ITを避けないように努めることをアドバイスした。デマンドからのステークホルダに対しては，理論と現実は違うのが普通だから役員室を訪ねること，仕様決定の際には実際のユーザの関与を得ること，ITを必要以上に難しいものと捉えないことをアドバイスした。最後に，サプライ側のステークホルダには，プロダクトオーナ以外のユーザをデモに参加させること，仕様会議に参加すること，説明の簡素化に努力することをアドバイスした。
ビジネスとITのアライメントにおいては，本質に基づくコラボレーションがもっとも重要だ，と氏は言う。ビジネスのリアリティを効果的にITソリューションに適用するには，モデルや事前定義されたパターンを超えた考え方が必要なのだ。