Enterprise Architecture Pitfalls (Crowdsourced version)

[Updated: Monday, September 7, 2009 for additional conversations (tweets and posts).  See “Updates” following horizontal line break.]

 

Yesterday, ebizQ published a news article on 10 Enterprise Architecture Pitfalls identified by Gartner.  While there’s nothing wrong with Gartner’s list, the points are best described as “obvious”:

1. Wrong Lead Architect

2. Insufficient Stakeholder Understanding & Support

3. Not engaging Business

4. Doing only Technical Domain-Level Architecture

… and similar ilk. 

In another moment of grumpy architect channeling, I tweeted how this list “stated the obvious”.  That returned many amusing tweets on the role of the obvious in the industry analyst business.  Once we all got over our snarkiness, I asked the enterprise architect types in the crowd to share some “Real EA Pitfalls” and use the #eapitfall hashtag. 

I offered a few starters:

#1: Embark on EA w/o understanding of Why & What; ie pundit said "Do EA and you will be saved"

#2: View your architecture as an end, rather than a means

#3: Practice methodology without anthropology

And then the EA crowd jumped in, including Richard Veryard, Aleks Buterman, Sally Bean, Srinidhi Boray, Mark Griffin, Gene Leganza, Malcolm Lowe, James McGovern, Mike Kavis, and Jon H Ayre.

What follows is a sampling of their Real EA Pitfall Tweets: 

aleksb6: Re: EA Pitfall List #2: Framework is THE answer #eapitfall 

aleksb6: Re: EA Pitfall List #3: Modified waterfall planning: "we have 2 wait 4 biz to define their strategy before we can start!" #eapitfall 

richardveryard: A pitfall is a trap for the unwary or unprepared, not merely a failure to follow best practice recommendations. #eapitfall 

richardveryard: Example EA pitfall - developers persuade stakeholders that EA guidelines are unnecessary redtape #eapitfall

richardveryard: Example EA pitfall - corporate acquisition of enterprise application package preempts EA activity #eapitfall

aleksb6: Add to EA pitfalls: Start/Shutdown Pattern: as in: "we're on our 6th attempt to create #EA in last decade" #eapitfall

aleksb6: #EA Code Trap: "Our EA will build the shared/common applications/frameworks" <- not EA, it's EAppDev #eapitfall

Cybersal: Example EA Pitfall: Running behind a project team waving a red flag #eapitfall 

sboray: #eapitfall : EA is meant to address macro concerns, not micro issues in isolation 

sboray: #eapitfall : EA often is considered to be overburdening theory. In lack of EA planning will be along a straight line http://bit.ly/BupF4

sboray: #eapitfall : Treating EA as procedural. > While, EA stimulates & creating fertile landscape for imaginative work http://bit.ly/izzSY

richardveryard: And it's hi-ho silver lining anywhere you go, well, baby I see your sun is shining but I will make a fuss Though it's obvious #eapitfall

sboray: #eapitfall > EA is not restricting regulation, it is regulated creative liberation. Else it leads to prisoner's dilemma http://bit.ly/19z358

sboray: #eapitfall : Not applying design mind to study enterprise behavior and only creating static un-integrated artifacts. http://bit.ly/XhQr2

grifmon: EAPitFall: not knowing what a chupacabra is. #eapitfall 

gleganza: #eapitfall: Thinking one-size-fits-all is the ideal for all scenarios (Jeanne Ross' "Unification" operating model)-makes EAs standards cops 

malcolmlowe: EA pitfall - EA is just about technology #eapitfall 

malcolmlowe: EA Pitfall - EA is TOGAF or Zachman or another method/framework. It is about delivering real business value #eapitfall

malcolmlowe: EA Pitfall - EA is 80% architecture 20% communication/buy-in #eapitfall. It is more like 20% architecture 80% communication/buy-in 

malcolmlowe: EA Pitfall - EA is created by a few Enterprise Architects #eapitfall. It is a participative, collaborative endeavor. 

Cybersal: #eapitfall thinking that knowledge can reside purely in artifacts (they need ongoing stewardship) 

richardveryard: RT @mcgoverntheory 8 out of 10 enterprise architects suffer from #hypertension. (Now that definitely counts as an #eapitfall ). 

madgreek65: #eapitfall Spending a year creating documents with no tangible benefits to show the business. 

aleksb6: #eapitfall Soft Gum Syndrome: continuous recreational whining re: ppl circumventing EA ergo EA suffers from lack of teeth

aleksb6: and of course the opposite #eapitfall: Soft Spine Syndrome: continuously approving exceptions to EA guidelines due to fear of saying "No" 

mcgoverntheory: @bmichelson How many process-compliant #EA documents would need to be created to build Hello World in #CMMI shop? #eapitfall 

mcgoverntheory: Most developers have no clue what project plans even say.Why bother to read them. 90% done, 2 years remaining on 6m project #pmp #eapitfall

sboray: #eapitfall EA in Federal masquerading compliance has done more damage than anything transformational 

EnterprisingA: @malcolmlowe Gartner #eapitfall 5 Doing Current-State EA First. me: So true, so why do so many not get this? Easy way out, perhaps?

To get the real-time list, do a twitter search on #eapitfall. 

Given the “good enough” 140 character limit of twitter, these tweets contain some good insights.  I laughed as I read Sally’s “Running behind a project team waving a red flag”, who hasn’t been there.  Shuddered in a nightmarish flashback on Richard Veryard’s “corporate acquisition of enterprise application package preempts EA activity”.  As for Aleks’ “The framework is THE answer”, my view is well documented in response to a comment from chupacabra-architect, Mark Griffin:

"I share your concern that EA can be (sometimes deserving) viewed as an ivory tower. I'm encouraged by the modularity of TOGAF 9 and the related messaging from the creators that EAs should pick and choose the TOGAF steps, artifacts & practices that make sense for their business situation. Used this way, TOGAF (and any other framework) becomes a tool rather than a mission in itself.

For the reasons you mention, I've never been an ardent framework follower. Too often that leads to excessive documentation and little implementation. I'm more of a "sampler", on the look out for artifacts, guidance, practitioner ideas I can apply to my work in the context of delivery.

As I dig into TOGAF, I'll be testing for value within my "sampling" point of view and sharing those findings for real-world folks like you."

But that’s just my experience.  How about you?  Do these EA Pitfalls resonate?  What would you add?  Comment here, or join our twitter conversation #eapitfall.

As I was pulling the most recent tweets into this post, I noticed Richard Veryard’s related post discussing “pitfalls, practices and misconceptions”. 

---

UPDATES

September 7, 2009

Since my EA Pitfall summary post on Friday morning, more folks have joined the conversation, contributing #eapitfall tweets, comments, related blog posts and conversations. 

Some of the new EA Pitfalls:

aleksb6: Couple of more #eapitfall this morning: Analysis Paralysis - i.e. need to talk to every analyst alive before doing anything 

aleksb6: and 2, a related #eapitfall : expecting analysts (e.g. Gartner) to give you concrete 'how to' steps to successfully build #EA 

leodesousa: missed #eapitfall fun and enjoying @bmichelson blog post summary http://bit.ly/I5lnL - Me: Implement EA w/o dedicated resources=fail 

sboray: #eapitfall: Introducing EA after making investment decisions and after initiating the project. EA does not work hindsight and retrofit 

richardveryard: RT @chrisdpotts avoiding pitfalls not = success #eapitfall 

mcgoverntheory: Calling up an industry analyst for cost savings advice and remaining blissfully ignorant when they don't suggest any open source #eapitfall

mcgoverntheory: Stop worrying about what happens if you train and they leave. Start worrying about if you dont train and they stay. #CIO #eapitfall #CEO #IT 

EnterprisingA: @malcolmlowe Not liking the link - talks about distributed EA. EA by committee - ouch. Crowds good for innovation - bad for EA #eapitfall

EnterprisingA: Q. What's wrong with EA? A. Most doing EA are actually still doing IT Architecture or IT design. Not the same thing. #eapitfall 

To get the real-time list, do a twitter search on #eapitfall. 

Related Posts

On his Chief Architect blog, Alan Inglis takes on the topic of the relevance of Industry Analyst research for enterprise architects:

“If you read the blogs of the community of practitioners then you will find not only the pitfalls but the solutions to them.  These solutions have been discovered through the sweat and tears of those who have been there, made the mistakes, and got the scars.

The Twitterverse and Blogosphere has enfranchised the “doers” who previously didn’t have a voice.  But more importantly, the current generation of decision makers and key influencers understand the value of the information that is out there and freely available.

If you read the blogs, you won’t get a neatly package “answer” to your problems.  But you will, after some time and effort, get insight.   You will have to work out for yourself what is relevant and what is not. You will have to work a little harder to get to a plan to take your organization further.  But you will learn, and you may just have a plan that can deliver meaningful results.

The criticism of the identification of EA pitfalls follows very close behind similar criticism by the EA community of Tweeters of “Emergent Architecture”.

The analysts need to demonstrate that they talking to the right people, that they are gathering the right information and finding genuine insights based on the experience of practitioners.  If they can deliver better results quicker and cheaper than doing it yourself then they will have a valuable offering.  The recent Twitter discussions suggest that they are behind the curve.”

Alan’s post generated a twitter (side) conversation for me with Jon H Ayre on what analysts should provide for enterprise architect types.  Jon’s point is that failure stories and pitfalls alone won’t advance the EA cause.  In fact, failure stories most often are worthless.  Jon calls on analysts to only speak of pitfalls and failures when framed within an overall success case.  Knowing how to overcome obstacles is critical.  The final tweet in our conversation:

“EnterprisingA: @bmichelson Absolutely. Failure without solution teaches nothing as generally this is a failure to do EA rather than a failure to do good EA”

Related to that side conversation is Richard Veryard’s post on pitfalls, practices and misconceptions and a tweet from Chris Potts:

“richardveryard: RT @chrisdpotts avoiding pitfalls not = success #eapitfall” --- [Twitter speak RT = retweet another’s tweet for amplification/comment]

In addition to the EA pitfall contributors, many folks helped spread the word on our conversation, including Tom Graves, Ric Phillips, Bart Leeten, Andrew Townley, A Jangbrand, Bas van Gils, A Travanti, JP, Ali Sohani, Alexj Freund, the Community Roundtable, Dion Hinchcliffe and Joe McKendrick.

In response to Joe’s ZDnet post, one commenter questioned the value of “140 character EA pitfalls/conversation”.  And that’s certainly a fair question.  As I warned in the original post (above), the 140 character limitation gives us "good enough” answers.  But, more important (for me) than the individual tweets that flew by, was the rapid and broad sharing of insights and all the new connections made. 

Enterprise Architects have a tough (and sometimes thankless) job.  The more connections we can make within our community, the stronger each organization’s EA practices will be.  Tweet on!

Comments

[Rob Aalders]

IMHO one reason is that The CIO or Head of Architetcure fails to ask a critical question BEFORE they establish an EA team.

The question should be addressed to the CEO and other senior executives as a body and it is 'How do you INTEND to USE the architecture?"

Maube Strassman (Politics of Information Systems) showed on way to nobble this issue was to get the Senior Executives as a body to agree what he termed an ITC Constitution which is in fact a small set of high level principles govering the management of ITC. Over. Rob

[Marc Rix]

I didn't see anyone mention poor ROI analysis as a pitfall, and of the suggestions I did see (through 9/6), many could be remedied with a disciplined approach to measuring and tracking the performance of EA investments. Asking yourself if every decision you make is good for the company, and tracking it empirically over time, may come off as overly Lumberghian (think Office Space) and earn you a good ribbing at the water cooler, but it will put you in the right mindset for quality EA.

[Jon H Ayre (The Enterprising Architect)]

An interesting exercise in how twitter can contribute to a meaningful discussion on a topic (even with the 140 char limit), as a counterpoint to its use as a means of sharing uninteresting trivia.
I firmly believe that one of the main confusions in the field of Enterprise Architecture is the number of people who use the title and refer to what they are doing as Architecture, when in fact they are doing something entirely different (but simply want to use the title to escalate their credibility). This in itself should be seen as a success for Enterprise Architecture, as others want to use the title to raise their status.

Regards
The Enterprising Architect