エンタープライズアーキテクチャ(Enterprise Architecture，EA)の役割，およびビジネス戦略との連携を扱った出版物が最近多くなっている。Chris Curran 氏によると，
EAは多くのケースで，その潜在的な能力に到達できていません。それは "EA" 自体をあまりに強調しすぎて，結果について重視しないことが多いからです。もっと堅実で協調的なビジネスプランの方に注目するべきです。EA はそれを支える役割でよいのです。
16 のエンタープライズアーキテクチャ戦略苦心談 (16 Enterprise Architecture Strategies Learned the Hard Way) の議論の中で，Curran 氏は次のように述べている。
ビジネスと IT パートナーの間の信頼と信用の強さが，EA 成功の指標となります。これらは多くの場合，プロジェクト毎の戦略的計画を立案するための共同作業を通じて獲得されます。
Curran 氏は次に，アーキテクチャに関する５つの定説について議論する。
- エンタープライズアーキテクチャは，IT 部門 がテクノロジを計画するために使うものである。Curran 氏の意見によれば，テクノロジはエンタープライズアーキテクチャにおける項目のひとつに過ぎない。
... 優れた EA プログラムでは，最初にビジネスの要件定義 (目標，基準，ある種の戦略) を明確化します。それをベースとしてビジネス上の要求機能を理解した上で，ビジネスと技術に関するブループリント(Blueprint，詳細計画) を立案するのです。
一方で氏は，このようなブループリントの立案に時間を掛け過ぎないよう，警告もしている。
企業レベルの完璧なブループリントというのは，実際には構築不可能です - 規模が大きすぎて，引き受け手がいないでしょうから... 最もよい方法は，企業レベルの方向性を決めるブループリントと，ビジネスユニットをドメインとするブループリントとを併用することです。
- エンタープライズアーキテクチャは評価不能である。Curran 氏の意見によれば，正確な評価ができるエンタープライズアーキテクチャはビジネス駆動だけだ。
計画段階で評価の対象となるのは，重要性の高いビジネス機能の開発提供に関する進捗度です。機能が実際に提供されれば，そのビジネス指標も評価項目として使用できます。
さらに氏は，EA は提供するビジネス機能とコアサービスコストの２面において評価されるべきである，と主張する。
EAを資産として評価してください。サービスの提供に要するコストはどの程度なのか，提供するビジネス機能からビジネスとして何が得られるのか，を測るのです。
- アーキテクトは横柄なだけで仕事をしない。Curran 氏の指摘する技術駆動アプローチの副産物のひとつが，時間の大部分をベンダとのミーティング，白書の作成，決して日の目をみないプロトタイプ実装などで浪費するアーキテクチャグループの存在だ。
アーキテクチャにおいて優秀な企業は，アーキテクトの大半をコアチームのメンバとしてプロジェクトに”配置”します。このような方法で，現場で日々の経験を積み上げさせているのです。
さらに氏は，アーキテクトがプロジェクトの作業を行うべき (平均) 時間の割合を定義している。
アーキテクトの EA フルタイム相当時間 (Full-Time Equivalents, FTE) 合計の 60% 以上は，"アドバイザ" としてではなく，コアチームの一員としてプロジェクトにアサインされるべきです。
- エンタープライズアーキテクトの作業は SDLC (Software Development Life Cycle, ソフトウェア開発ライフサイクル) に含まれない。Curran 氏によれば，
方法論とガバナンスは新たなオーバーレイではなく，既存の作業プロセス (プロジェクト承認やSDLCなど) に組み込まれなければなりません。
そうでなければ，アーキテクチャプロセスは日々の企業活動に組み込まれることもなく，孤立して存在せざるを得なくなる。
システム間のブループリントが，それぞれのイニシアティブの下で想定どおり確実に実施されるためには，EA プロセスは２つの場所に置かれる必要があります。ひとつは高度なビジネス戦略と優先事項の直後であり，そしてもうひとつはプログラムやプロジェクト，SDLC 管理プロセスといったものの内部です。すなわち，EA が機能するためには SDLC のみならず，プログラムやプロジェクトといったレベルの，すべてのプロセスやメソッドとも連携しなければならないのです。
また，氏の経験では，
パフォーマンスの高いグループでは，SDLC と EA の関連性は定型化されています。EA のブループリントを各プロジェクトの詳細な初期アーキテクチャ決定，コストとリソースの正確な見積に反映させることができているのです。
さらに次のようにも書いている。
成熟した組織では，EA リソース時間の 40% を戦略的計画に，60 % を SDLC タスクに割り当てることを目標にします。通常はこれより，SDLC の方に多くの時間を割き過ぎているものです。
- SOA を採用すれば EA は必要ない。Curran 氏の指摘によれば，いくつかの企業ではエンタープライズアーキテクチャをジャンプスタートさせる目的で，SOA やクラウドコンピューティングなどの特定アーキテクチャ方式を採用しようとしている。それは結果として "ひとつのサイズをすべてに当てはめる" ようなもので，すべてのアーキテクチャ選択に同じスタイルを押し付けることになるのだ。
... 適切なコンピューティングスタイルとモデルを選択するためには，ビジネスが EA を主導する必要があります。SOA モデルは技術的アーキテクチャのごく一部分に対応するに過ぎません。EA 詳細計画全体で考えるならば，いくつかのビジネス領域では必要とされないか，あるいはまったく無意味なものなのです。
Curran 氏の意見は，多くの企業のエンタープライズアーキテクチャグループが経験している，多数の問題の核心を捉えたものだ。氏のアドバイスに従うことで，エンタープライズアーキテクトと管理者の苦労が軽減されることだろう。