advising on IT-business alignment
IT-business alignment about us blog our services articles & reports resources your profile exposure
blog
blog
Wednesday, July 23, 2008

Businesses aren't machines, and enterprise architecture can't make them so

Via Service Oriented Enterprise, I recently picked up an Infoworld blog post by SOA journeyman David Linthicum, where he makes a couple of very strange points about SOA and ESBs. It may be, of course, that the post is pure link bait: certainly, David appears to have said some relatively sane things in the past, so that might be it. If it is link bait, I'm going to fall for it now.

In his piece David quotes a representative from iTKO, who repeats the now well-understood insight that in some large organisations, there's a challenge that arises because different groups with SOA initiatives find themselves having to integrate different ESBs in order to pull together implementations for cross-silo scenarios. He then goes on to comment (I’ve taken the liberty of extracting elements of his piece below):
First, if there is indeed 'enterprise architecture' and an 'enterprise architect' then the different divisions should not be using different ESBs, or even an ESB for that matter... Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether. Because, call me crazy again, that would be cheaper... just to be clear, you determine your requirements, and then the solutions patterns, and then the technology.
The most charitable explanation I can come up with for David's position is that he believes passionately in the transformational power of enterprise architecture. The problem with this perspective is that even where EA is highly effective (and in many places it isn't), it can at best only be one of many forces shaping the way that IT evolves to support changing business conditions and requirements, and each force has its own vector. Some forces, like a good EA team, try and combine business and technology focus, and promote the value of global optimisations, good practice and standardisation. But most of the most powerful forces are business forces, and in 99.99% of organisations, their power, when something really big and important happens, will trump any righteous splutterings emanating from IT departments.

As any experienced IT staffer who's been on the sharp end of a big business merger or acquisition, or even a radical change of leadership, will tell you, businesses don't act like machines that EAs can simply steer so that they tend towards technology optimisation. In fact, it's the opposite: business change forces (new competitors, new product launches, new market launches, new regulations, mergers and acquisitions, and so on) will always drive entropy, tending to push IT estates towards chaos. The best value an EA team can really provide in this environment is to help the IT organisation to absorb these changes with as little stress as possible, and drive consistent, planned responses.

Still, there's always been a vocal (and quite often technically brilliant) part of the IT industry that seems to misunderstand this, and persists in maintaining that once people see beautiful models, they'll modify their behaviour to enable the models to be made real. They see businesses as deterministic machines that can be algorithmically decomposed, analysed, predicted, and shaped. I can only think that David is one of these people.

Unfortunately, no matter how clever your EA team might be, no amount of architecture astronautics can make businesses change their nature.

Labels: , , ,

Comments:
I completely agree. There is a fantasy that Enterprise Architects are architecting the enterprise, when they are at best architecting systems of systems to support the enterprise.

The people who are really making structural decisions about the business organization itself are not called enterprise architects, they are called CEOs or COOs or something like that. And you can bet they aren't playing Zachman bingo.

Meanwhile, I remain doubtful that the word "alignment" makes sense to describe the relationship between IT and business, and I think your argument just reinforces my doubts on this.
 
Thanks for the comment Richard! As I said in reply to your original argument about "alignment" all the way back in July 2006, when we talk about alignment, we're talking about a continuous process of moving towards better alignment - not permanent fixed synchronisation of IT and business. What's important to focus on is the journey, not the destination. I still stand by that - we've done a lot of work in this area and the thesis still stands up.
 
Post a Comment

<< Home


Burn this feed
Burn this feed!

Creative Commons License
This work is licensed under a Creative Commons License.

Blog home

Previous posts

If you want our take on where Oracle's taking BEA...
New Collaboration Service Launch!
Links for 2008-07-04 [del.icio.us]
Links for 2008-07-04 [del.icio.us]
Collaborative mind mapping
A comprehensive analysis of IBM's BPM Suite
Compuware "2.0" - passion or mis-step?
Two new BPM reports
Links for 2008-06-16 [del.icio.us]
Embarcadero rescues CodeGear

Blog archive

March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009

Blogroll

Andrew McAfee
Andy Updegrove
Bob Sutor
Dare Obasanjo
Dave Orchard
Digital Identity
Don Box
Fred Chong's WebBlog
Inside Architecture
Irving Wladawsky-Berger
James Governor
Jon Udell
Kim Cameron
Nicholas Carr
Planet Identity
Radovan Janecek
Sandy Kemsley
Service Architecture - SOA
Todd Biske: Outside the Box

Powered by Blogger

Weblog Commenting and Trackback by HaloScan.com

Enter your email address to subscribe to updates:

Delivered by FeedBurner