Four Questions to Determine if Enterprise Architect Is a Hit or Flop

Loraine Lawson

There's a lot of confusion and frustration over the role of enterprise architect within IT. If you don't believe me, just read the comments replying to "Enterprise Architects: Who Needs Them?" a May post about the backlash against EA.

But the real question isn't who needs enterprise architects, because the truth is, IT does need enterprise architects. One proof is the mess we're in today with integration.

The questions we should be asking are why is there a backlash and can it be fixed?

In "Enterprise Architecture is More than Engineering," Mike Rollings tackles these questions, taking a critical look at why enterprise architecture is failing. The truth is, there's blame to go around.

Neither organizations nor IT have embraced enterprise architecture. It's pretty darn hard to get people to follow your plan if they're not listening, and few architects have the authority to make them do so, as David Linthicum has pointed out.

Then again, people aren't going to follow a plan that ignores business needs and requirements, and given IT's poor success record with giving business users what they need, it's easy to see why they would distrust an IT person who's been promoted and retitled. EAs don't improve the situation when they develop plans in a vacuum without input from IT or business.

It doesn't take a flow chart to see there's a problem with this loop.

Rollings does the best job I've seen of outlining why enterprise architecture isn't working, but he also offers a list of recommendations for how EAs can fix it without resorting to what he terms "the governance trap of the enforcer" who tries to mandate use of architecture.

How can CIOs and EAs know when they're in trouble? Here are four questions, extrapolated from Rollings' six-page paper, to ask yourself:

  1. Do people understand you? If no one understand how EA works, or the purpose behind your role, or the results, or how you can help them achieve their goals, then you will fail.
  2. Do people see you (ever)? Rollings says you should "vigorously participate in the design process to both learn and advise." If neither business users nor IT people see the EA on a regular basis, then you've got a big problem.
  3. Do you understand the business and how technology -- even so-called technology 'best practices" -- can limit it? Integration and standardization are IT's Holy Grail in the sense that they tend to doggedly pursue these goals without question. But as incredible as it may seem, sometimes the business doesn't want or need either.
  4. If you know how your business and IT systems compare to others -- via benchmarks -- do you know why? IT loves benchmarks, but what's often missing is why you rank where you do. The rankings can mean nothing, or they can provide a valuable clue to problems. You can't fix the problems until you know about them and that means answering why.

If you answered yes to all of these questions -- good for you. You're either doing an amazing job with enterprise architecture or you're deluded. Maybe you should e-mail this post to a business leader for a second opinion just to be sure.

 

If you answered no to any of these questions, go straight to Rollings' white paper and read it. Do not pass Go and do not collect $200.

 

You'll want to hurry, though -- it's only available for free download to guests until June 23. You'll need to register as a guest, but after June 23, you'll need to be a paying Burton Group client to read it.

 

While you're on the site, you might also want to listen to this free podcast with Rollings discussing how the Burton Group defines EA.



Add Comment      Leave a comment on this blog post
Jun 15, 2008 10:37 AM David Wright David Wright  says:
I dunno, sometimes it seems like to EA, everything is a mess, and if you only let EA do what it says needs to be done, then a new day will dawn yadayadayada.... that nanny-state appraoch may never sell.Architecture is necessary for anything complicated that needs to be built from components. That's great for skyscapers and even information systems (at a point in time); but, enterprises are not complicated, they are complex, meaning they are dynamically evolving and changing. I am not sure if Architecture is the right approach for managing a non-static thing, perhaps Enterprise 'Biology' is more appropriate. Life Sciences may be a better analogy than architecture for an organization (organism). Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.