[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!
