• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

Enterprise Architecture Pitfalls (Crowdsourced version)

September 3, 2009 By brenda michelson

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

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)
  • Click to email this to a friend (Opens in new window)

Filed Under: enterprise architecture


Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • Great share. Subtraction can be additive. // cc: @AngelaYochem https://t.co/q1OgBcqz7N April 9, 2021 2:13 pm
  • Walking along, solving a writing problem in your head, when suddenly you’re an eyelash away from face planting in a… https://t.co/rVJ7QNuF30 April 5, 2021 1:31 pm
  • Arts, tech, education and (much needed) diversity; Portland, Maine. https://t.co/pSshO4VMXv @wearecywoc March 26, 2021 3:58 pm
© 2004-2021 Elemental Links, Inc.
loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.