Via the folks over at Infoq and their article on defining the ESB I came across a link to an interview from Accenture's CTO. Now if there was a company I'd expect to understand that SOA as a technology approach won't work it would be the people who used to be accountants. But it turns out if you turn accountants into IT professionals then they become technology geeks.
Infoq's summary of Accenture's position is
- Use of eXtensible Markup Language (XML) to use application interfaces in a more standard way.
- Taking some business processes and turning them into web services.
- Introduction and full use of the enterprise service bus.
- The generation of Business Process Execution Language(BPEL) --the ability through business processing modelling tools and BPEL to create different application behaviour without changing the software
Good god, did this man STUDY to become this wrong? Yes folks, SOA isn't about thinking differently, or architecture or anything actually different its just about using XML, whacking on some Web Services, lobbing in a Bus and then if you are REALLY brave using BPEL.... oh and guess what folks, according to the CTO at Accenture changing BPEL doesn't mean you change the software, because BPEL is of course some sort of magic language.
Now from one side this of course makes me amazingly happy, but from another its just depression. Some people have already done all of these steps and found out that the technology doesn't matter half as much as the practice.
If SOA is just about adopting XML, lobbing web-services on processes, using an ESB and then trying to use BPEL then its not going to deliver on the promises. If you deliver in the same way, thinking about the problem in the same way and only change the technology then all you are doing is putting lipstick on the pig, and not even at the front where it will have some impact.
It does stun me how people, particularly people at an SI, can talk about SOA and fail to mention three things
- Services
- Architecture
- The Business View
Instead they concentrate on the technologies that exist today and how people can use them in the future. Even for a technology view this is brain dead. FIVE YEARS before people are using BPEL? Don't you think just for a second that something else will have been introduced above BPEL that will become the next hot thing? Taking a technology view of today's products and assuming it will remain pretty static for five years is 100% against what history has told us.
SOA has to be about the business and changing the way we think. IT for the sake of technology is what got us in this mess in the first place.
Technorati Tags: SOA, Accenture, Service Architecture
7 comments:
This is so true - and how often do we see SOA as just a set of technology and leave the business out of the picture.
And the idea that you can follow three or four simple steps to achieve SOA is crazy - and only fuels developers knocking up code for no other purpose than to 'implement SOA'.
Steve, I've gotta agree. Putting lipstick on the (arse) end of the pig, really only works when you are integrating a single system into a single business process. That is 'point' integration, not SOA. Which of course can be OK to get a process up and running fast, as long as you bear in mind that this may require rework when your full SOA vision kicks in.
I'm in the middle of writing a (too lengthy) post about SOA/BPM applied to a specific business process, so I'll definitely make sure I have the words XML, ESB,... oh no, Services, Architecture, the Business View in there.
Cheers!
Phil
All the rubbish being written about SOA lends me to think, whats the point. What is it giving us apart from confusion. So SOA about changing the way the business engages with IT.
Well how about this novel idea. Lets call it an exercise in business transformation and leave out software related terms such as "service" and "architecture".
Nico
I am often disturbed when Service- Oriented Architecture is abbreviated, the word "infrastructure" is never mentioned, there is the "strange absence" of a business problem description, but a solution using "SOA" is touted. Before you get to use the acronym SOA, you have to look at the organization and map out the existing business process map(s). That is the only way you are going to figure out a viable road map. Before you get the roadmap, there has to be a road.
You reference an article where somebody was asked to describe their position on ESBs and then mis-represent this as their view on SOA.
SOA is not an ESB. Period.
SOA is an approach. An ESB is one part of implementing this but by no means all of it. Remember ESB is a bit of technology and we all know technology doesn't solve problems. A good and successful SOA implementation will involve a lot of process work and business change around the technology piece.
I would hope that your book that you shamelessly plug on the blog provides more clarity than your blog.
The original article
Most companies were in the first phase of adopting SOA and using eXtensible Markup Language (XML) to use application interfaces in a more standard way, Mr Rippert said.
Sounds like he is promoting XML (a technology) as the first phase of SOA.
He mentions ESBs towards the end but every step is a technology only step. Its hard to see how I'm misrepresenting it.
I agree with your position on the importance of business vision over the focus on technology. This is nothing new. Prior to the bubble burst many IT organizations were focused on the latest technology and not on business value that they may or may not bring.
I think when someone is interviewed about SOA, there is a tendency to think about the technology first, so I guess I wouldn't be too hard on Accenture's CTO. However, your point is well taken.
The organization I work for is primarily a technology services company. Yet when we are asked to help build Web Services or SOA infrastructure or implement an ESB, our objective is to turn the discussion to business value,strategic planning,identifying pain/gain opportunities, identifying repeatable processes,governance and planning. All of this prior to writing any code. Unfortunately, many companies are reluctant to do the planning necessary and are only interested in point solutions.
Post a Comment