Ambysoft Logo

Enterprise Architecture: 2010 Open Research

This open research into enterprise architecture was performed during the month of February 2010 and there was 374 respondents. The survey was  announced in my January 2010 DDJ newsletter, Tragic Mistakes When Adopting Test-Driven Development (TDD), in Jon Erickson’s blog, and on the IT Surveys page.

The Survey Results

The survey results were summarized in my March 2010 Agile Update in Dr. Dobb’s Journal.  Some findings include:

  • Existing EA programs were rated as being effective, as you can see in Table 1, although they aren’t “roaring successes”
  • The most important success factors for EA programs, in general, are the softer people-oriented ones as you can see in Table 2
  • There are many potential pitfalls with EA programs, as you see in Table 3, but a failure on the part of enterprise architects to interact effectively with development teams was very common

Table 1. Reported effectiveness of existing enterprise architecture programs (ratings -10 to +10).

Benefit Rating
Improved system integration
Improved IT governance 3.3
Team follows common technology infrastructure 3.3
Improved business efficiency 3.2
Improved data integrity 3.2
Continuity of organizational knowledge 3.0
Improved business governance 3.0
Improved audit compliance 2.9
Improved risk management 2.9
Increased technical integrity 2.8
Reduced operating costs 2.5
Improved enterprise decision making 2.5
Reduction of waste 2.3
Improved support for multi-vendor projects 1.8
Improved outsourcing initiatives 1.3
Reduction of technical complexity 0.8


Table 2. Reported importance of success factors for existing enterprise architecture programs (ratings -10 to +10).

Success Factor Rating
Active involvement of business leaders
Active involvement of IT leaders 5.7
Enterprise architects are active participants on project
Enterprise architects are trusted advisors of the
Flexible enterprise architects 5.1
Having a business case for EA efforts 4.5
Continuous improvement/evolution of EA artifacts 4.5
Architecture reviews 4.1
Appropriate governance 4.1
Cost reduction 3.5
Master data management (MDM) 2.8


Table 3. Reported reasons for cancelling enterprise architecture programs (ratings -10 to +10).

Reason/Problem Rating
Insufficient time provided
Project teams didn’t take advantage of the EA 3.2
Too difficult to measure benefits 2.5
Enterprise architects perceived as “ivory tower” 2.5
Development teams couldn’t wait for enterprise
No perceived benefit of EA program 2.0
No executive endorsement 1.7
Enterprise architects weren’t sufficiently flexible 1.5
Enterprise architects perceived as impediment to success 1.5
Insufficient funding 1.5
EA perceived as not viable 0.0
Cancelled due to political issues -0.6
EA program successful but terminated -1.9


The Survey Questions

Raw Data

Summary Presentation


What You May Do With This Information

You may use this data as you see fit, but may not sell it in whole or in part. You may publish summaries of the findings, but if you do so you must  reference the survey accordingly (include the name and the URL to this page). Feel free to contact me with questions. Better yet, if you publish, please let me know so I can link to your work.


Discussion of the Results

  1. I should have asked more questions around the relationship of the business with enterprise architecture. For example, are the EAs coming from the business side or the technical side? Are they business focused or technical focused? How do EAs communicate/collaborate with the business?
  2. People didn’t know the purpose of the survey, so that likely removed some bias. My strategy for the DDJ surveys is to send out a short survey every two months entitled “State of the IT Union, DATE” but to not indicate what the topic of the survey actually is (other than an IT topic of course).
  3. This survey suffers from the fundamental challenges faced by all surveys.


Links to Other Articles/Surveys

  1. My other surveys


Why Share This Much Information?

I’m sharing the results, and in particular the source data, of my surveys for several reasons:

  1. Other people can do a much better job of analysis than I can. If they publish online, I am more than happy to include links to their articles/papers.
  2. Once I’ve published my column summarizing the data in DDJ, I really don’t have any reason not to share the information.
  3. Too many traditionalists out there like to use the “where’s the proof” question as an excuse not to adopt agile techniques. By providing some evidence that a wide range of organizations seem to be adopting these techniques maybe we can get them to rethink things a bit.
  4. I think that it’s a good thing to do and I invite others to do the same.