Channels ▼


Enterprise Architecture: Reality over Rhetoric

Scott Ambler is chief methodologist for Agile and Lean for IBM Rational.

In This Issue

  • Enterprise Architecture: Reality over Rhetoric
  • Participate in the "2010 IT Project Success" survey and potentially win a copy of "Reflections on Management"
  • Hot Links

Enterprise Architecture: Reality over Rhetoric

For several decades we've heard that effective enterprise architecture programs are a critical success factor for medium-to-large size IT organizations. I have been a promoter of enterprise architecture, both in my writings and working with organizations around the world, yet after all these years it seems that the reality of enterprise architecture is nowhere close to fulfilling some of the rhetoric around it. So I decided to find out what's actually working in practice, and what's not working for that matter, in my January 2010 State of the IT Union Survey.

The survey was announced in my January 2010 column and by Dr. Dobb's editor Jon Erickson in a blog. As with previous surveys we had a robust set of responses, albeit with a bias towards North American respondents. There were 374 respondents in total, with 38% identifying themselves as developers, 27% in management or leadership roles, 13% were modelers, and 10% consultants. Four out of five respondents had 10 or more years experience in IT and 23% worked in organizations which had 1000 or more IT professionals. Two-thirds of respondents were from North America, 21% from Europe, and 10% from Asia Pacific. The original questions as they were asked, a summary slide deck, and the source data with identifying information removed for privacy reasons can be downloaded here free of charge.

Room to Improve

A critical issue that I wanted to explore is the adoption rate of enterprise architecture within organizations. Overall, only 47% of respondents indicated that their organizations had an enterprise architecture program currently in place. Of this group, 36% indicated that their program was expanding whereas the other 64% indicated that the program was stable. 9% of respondents indicated that their organizations were thinking about starting an enterprise architecture program and 34% indicated that they had no enterprise architecture program at all. However, when it came to people working in organizations with one hundred or more IT people the results were a bit better -- 63% of organizations had an enterprise architecture program (38% expanding, 62% stable) and 6% were thinking about starting one. It makes sense that larger organizations would be more likely to be focused on enterprise architecture than smaller ones as the need for an effective enterprise architecture program increases in step with the size of your IT department.

I also explored the benefits that organizations were experiencing as the result of their enterprise architecture program. I presented a list of 16 potential benefits and asked people to rate them on a scale of much improved to much worse. Although all of the potential benefits were rated positively, none of them stood out as clear winners. All of them averaged out to being somewhere in between no change and improved, but none approached much improved. However, individual respondents did indicate that some factors are now much improved since the introduction of their enterprise architecture program, so averages can be deceiving some times. The top five benefits were improved system integration, improved IT governance, greater chance that development teams follow a common technology infrastructure, improved business efficiency, and increased data integrity. Considering the low averages, my fear is that we may be over promising and under delivering when it comes to enterprise architecture programs.

What Works, What Doesn't

One of the things that I was hoping to do with the survey was identify the most important success factors for enterprise architecture programs. Not surprisingly, the survey showed that the "soft" people-oriented issues are most critical to your success. In fact, the top five were all focused on people: active involvement of business leaders in the enterprise architecture program, active involvement of IT leaders in the enterprise architecture program, the enterprise architects must be active participants on project teams, the enterprise architects must be trusted advisors of the business, and you need flexible enterprise architects. Coming in 6th, of 11 issues, was having a business case for your enterprise architecture efforts, something which I thought would have placed higher considering the current economic climate.

The survey also explored the potential pitfalls leading to the failure of enterprise architecture programs, with business issues and people-oriented issues being common culprits. The top five pitfalls, in order, were providing insufficient time for the enterprise architecture program to succeed, project teams not taking advantage of the enterprise architecture, it's too difficult to measure benefits of the program, the enterprise architects were perceived as "ivory tower", and development teams couldn't wait for their enterprise architects. Enterprise architecture programs are a long-term investment, granted if you're smart you'll show some tangible results on a regular basis, but the main benefits can take years to materialize. Considering that not giving the enterprise architecture program sufficient time is the leading cause of failure, the implication is that some organizations may not understand that enterprise architecture is a long-term play.

Issues such as project teams not taking advantage of the enterprise architecture, the enterprise architects being perceived as ivory tower, and development teams not being able to wait for the enterprise architects can all be addressed by taking a more agile approach to enterprise architecture. Effective enterprise architects collaborate directly with development teams, rolling up their sleeves and helping the development teams to implement the solution. Yes, this may imply that the architects get involved with actual coding. One of the unfortunate aspects of developer culture is that many developers don't respect other technical people who don't write code, so if the enterprise architects aren't willing to get their hands dirty every so often to write code it can lead to them being perceived as ivory tower. Furthermore, the concrete feedback of seeing code actually run, or not run as the case may be, can help to bring architects down to earth. The enterprise architects also need to invest some of their time mentoring people in architecture skills, work closely with the business to understand their needs, evolve the enterprise architecture artifacts, and share learnings with one another so that they can evolve the enterprise architecture appropriately.

Exploring the Hype

Technology platforms and strategies are first and foremost the most hyped topics when it comes to enterprise architecture. One of the questions presented a list of platforms and strategies and asked respondents whether their enterprise architecture included them. In order respondents indicated:

  • Service Oriented Architecture (SOA) 65%
  • Common Frameworks 55%
  • Business Process Management (BPM) 52%
  • Components 43%
  • Software as a Service (SAAS) 37%
  • Product Line Architecture 31%
  • Cloud Computing 22%
  • Semantic Architecture 14%

I suspect that several of the platforms -- particularly SOA, frameworks, and components -- rated highly because they are mature and proven technologies. Cloud computing did surprisingly well considering that it's a relatively new strategy and I suspect its adoption will grow over the next few years. I was surprised that product line architectures rated as highly as it did considering that they require a fair bit of sophistication to implement effectively. Semantic architecture was likely rated low due to the difficulty of coming to a consensus around, and then actually implementing, common data definitions.

Architectural frameworks can be a contentious issue within the enterprise architecture community, with several to choose from and ardent supporters in each camp. This survey should shed some light on this debate because it explored framework usage within the context of successful and unsuccessful enterprise architecture programs. When it came to successful enterprise architecture programs, 39% of respondents indicated that they didn't know if their organization had adopted an enterprise architecture framework, 38% believed they had created their own, 19% were TOGAF, 9% Zachman, and 6% M/DODAF. On the other hand, for unsuccessful enterprise architecture programs, 60% created their own, 27% didn't know, 13% adopted Zachman, 7% adopted TOGAF, and nobody was following M/DODAF. Although there isn't sufficient evidence to determine causal relationships, it may be that adoption of a proven enterprise architecture framework increases the chance of success for your enterprise architecture program. Furthermore, it may also be that adoption of M/DODAF or TOGAF is more likely to lead to enterprise architecture program success than adoption of the Zachman Framework, something that frustrates me because I prefer the Zachman Framework. More investigation is needed on this issue, and your mileage may vary (YMMV) depending on the culture of your organization.

A relatively minor issue that I explored was what modeling notations people were using to describe their enterprise architectures. I've noticed over the past couple of years that the notation war was starting to rear its ugly head again, with people arguing between Unified Modeling Language (UML) and domain specific languages (DSLs). In the survey, 53% of respondents indicated that UML was being used in their enterprise architecture, 36% created their own notations, 25% were using Business Process Modeling Notation (BPMN), 13% had no visual models at all, and 11% were using DSLs. So, although UML was being used by the majority of organizations it clearly doesn't dominate the enterprise architecture landscape, contrary to the claims of some UML bigots. Furthermore, for all the hullaballoo about DSLs they're not as popular as "standard" notations such as UML and BPMN. I'm happy to see these results as for years I've promoted in Agile Modeling that you should use the right model type for the situation that you find yourself in, and it appears that many organizations are in fact doing that when it comes to enterprise architecture modeling.

In conclusion, the survey appeared to show that a large percentage of organizations, particularly larger ones, are trying their hand at enterprise architecture. Many of these efforts are doing well, although on average enterprise architecture programs in practice don't seem to be living up to their promises. I hope that this survey has helped to shed some light on the current status of enterprise architecture, and better yet provide some insights for improving your approach.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.