Is SOA about the technology?
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?
Two worlds of SOA
Jack van Hoof
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...
When, not if?
Re: When, not if?
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.
Todd Montgomery Dec 19, 2014