Is SOA about the technology?

Posted by Arnon Rotem-Gal-Oz on Sep 05, 2007

Sections

Architecture & Design,

Enterprise Architecture

Topics

Architecture ,

Business ,

SOA

Tags

Business/IT Alignment

Nick Gall wrote a post claiming that discussion of SOA  without  also connecting it to technology is problematic. Nick bases his post on a post by Andrew McAfee that attacks the notion of "It's not about the technology" (INATT).

Andrew suggests that there are two types of INATT. One of the is lacking and the other is flat wrong and misleading.  Andrew says the first kind is "it's not about the technology alone" and that the second kind is "The details of this technology can be ignored for the purposes of this discussion."
 
Applying Andew's definitions to SOA nick says

Like Andrew, I cringe when I hear this argument -- most especially in SOA discussions and most especially in SOA discussions in the Service-Orientated-Architecture Yahoo Group (British spelling). In such discussions, technology alternatives for implementing SOA are dismissed as irrelevant and the discussion floats away on its own hot air.

Burton's Anne Thomas Manes admits she uses INATT  however she believes she uses another meaning which emphasizes the technology is secondary to design.

More specifically, technology is an implementation decision. When initiating a project, the project team should first identify and analyze the project requirements, then select an appropriate technology that effectively supports those project requirements.

Anne says technologies are tools and you need to choose the right ones for the job - the first thing should be to identify what the job is.

At the end of the day SOA is a architectural style and like any architectural work you have to first think about your architectural goals. However once you do make technology choices you have to go back and reexamine your architectural decisions. (see figure below) After all technologies, platforms etc. all come with their own set of architectures, capabilities and constraints.


(Source "An Architectural look at SOA")

In a recent article called "ESB-Oriented Architecture: The wrong approach to adopting SOA" IBM's Bobby Woolf (of Enterprise Integration Patterns fame) warns us :

"Clients often want to build only an ESB because that involves a technology challenge without the need for messy business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It does not create business value. In fact, it incurs cost without reaping immediate benefit. And it does not align IT and the business. The better alternative to ESB-oriented architecture is SOA-oriented architecture. Do not build an ESB by itself; build it as part of an SOA, preferably one that fits the SOA Foundation architecture that IBM recommend"

At the end of the day, technology is important, we cannot afford to ignore it when we design an SOA or any project for that matter. However technology should be places as second chair to business - or should it? What do you think?

1. Back to top

   Two worlds of SOA

   by Jack van Hoof

   I think there are two worlds of SOA: business and technology.
   
   . (soa-eda.blogspot.com/2007/05/two-worlds-of-soa....)
   
   And I think - in general - at the basis of all business lays technology. Technology creates business: first the train, then Dutch Railway made business out of it. First the phone, that the telecom companies came up. First the microprocessor that Microsoft started to rule the world. Thinking the way around is not innovative...

   Reply

2. Back to top

   When, not if?

   by Mike Davison

   To my mind it's a question of when SOA is about the technology rather than if. Is it not the case that technology matters whether we like it or not once we actually implement the architcture? In this case the if question is moot and we're left with when. In that case I agree with your second chair analogy because a good solution to the wrong problem is still wrong.

   Reply

3. Back to top

   Re: When, not if?

   by Julian Browne

   it's a question of when SOA is about the technology

   
   Exactly. And that's precisely where SOA (and I'd argue architectural concepts in general) goes wrong. And why both sides of the argument are, in fact, right. Service Orientation debates per se clearly aren't about the technology, but if they don't very soon lead to practical technical details, there's a real danger they will get hijacked by architecture astronauts who will never land them. Conversely, landing them too early can lead to poorly thought-through ideas that realise themselves quickly into hard-to-change stubborn software, that the business ends up hating. It's often a fine line, and generally it's better to get to code early, but not at the expense of thinking through business alignment properly.
   
   All businesses are subtly different, and therefore each SOA should end up reflecting this. The ESB 'field of dreams' article, referenced in the blog post, talks about a worrying trend that I am seeing a lot these days.

   Reply

• Older >