He [Accenture CTO Donald Rippert] described the four phases of SOA implementation, which begins at using XML as an interface, then implementing legacy systems as Web services, and then using an ESB to connect Web services and use composite processes. The fourth phase involves using BPEL (Business Process Execution Language for Web Services) in which a business application is revised by making changes to the process model rather than the code.
But SOA, for the most part, is not enabling this yet, said Rippert. "Maybe someday, but not today; I don't see it today," Rippert said.
Wow its still impressively wrong. Hands up everyone who has seen BPEL used in a commercial environment? Does that feel like the fourth and final phase of SOA to you? No me neither. This really is dreadful advice on what SOA is and what SOA maturity is about. I've worked with customers where their first technical SOA project was all about using BPEL (without an ESB) to do something where that made sense.
You can take what Mr Rippert is saying and easily replace WS and XML for some other basic form and an EAI tool, then have that EAI tool be the ESB and put a process engine on the EAI suite. In other words his vision is from a functional and conceptual perspective equivalent to EAI.
If SOA, or any IT change, is just about a series of three and four letter technical words then it will deliver almost no benefits. So has to be about changing the way people think or its pointless.
Technorati Tags: SOA, Service Architecture
9 comments:
I think what he was trying to get at was that .. you need to wrap up anything old as a service, so that you don't loose what you have already invested in legacy systems. After that, think about the business services that you want to offer and BPEL and ESB will allow you to quickly and painlessly join your existing services to offer the requisite business service.
I don't see whats wrong with that ...
Maybe I am looking at it through the wrong goggles.
There is (IMO) everything wrong with that if you are thinking of it as a maturity path. Firstly its the same message as failed with EAI and secondly it assumes that just technology change is what matters.
If you take the bottom up approach of wrap, expose, extend then I'll guarantee it will produce a mess in the same was as EAI did when it was approached this way.
He doesn't actually talk about business services at all, he is still talking about applications. Its EAI talk dressed up as SOA.
hmm, I am still not sure I agree with you .. I am still thinking of SOA as a method of quick integration and composition for rapidly changing/evolving enterprises.
As I said, I think I am looking at it though the wrong goggles
but before I comment more , I am going to go through the book at infoq
As Arnold said ... I will be back :)
Can you please tell me how the Capgemini approach to architecture IAF is different?
http://www.capgemini.com/services/soa/ent_architecture/iaf/
First point: The opinions here are mine and have nothing to do with my day job.
Second bit though is that there is a big difference architecture and a simplistic four phase technology roadmap. Architecture should always start with the business context and then work out how technology can be used to solve it, not start with a simplistic technology roadmap and try and fit everything to it.
Mr. Jones:
Thank you for your perspective on my comments about SOA. However, you are quoting a small part of a (well written) article about my talk last week. As you might imagine, the article simplified my comments which, in turn, simplified my overall view of SOA at large enterprises.
In stark contradiction to your post I take the position that business process definition and change is the key - not the technology (although the technology is very important). I also said that the "bottoms up" approach was the cause of SOA hitting a sticking point at many large enterprises.
In my opinion, many large enterprises have taken the "bottoms up" approach in an IT led SOA program. This worked for a while. From an IT perspective the first projects focused on using XML as an interface technology. These were largely IT-initiated projects and they worked pretty well. The second phase, again from an IT perspective, was to take some logic from legacy systems and create a few web serivces. This worked for a while but exposed a problem in the IT-centric approach. The problem is that companies want more than a few web services. They want entire business processes built as web services, connected though an ESB and joined to the business processes through BPEL.
Many enterprises have a lot of working XML, a few web services and they have bought (but are not really using) an ESB. The web services that have been built were chosen by IT partially to prove the technology would work and partly because the areas that were turned into web services looked like they were functionally "separateable" into individual, logical units of processing.
But the real economic benefits of SOA come when it is deployed at scale, not experimentally. So, now IT has to decide how to turn a whole lot more of the legacy environment into web services. And that's where things get stuck. The only way to do a proper job of service identification at scale is to start with the business' processes and work top down. Once the business processes have been decomposed to a sufficient level of detail the service identification effort can proceed apace. The business-oriented services should be built based on common areas of business logic. This business level logic (critical to effective service identification) is found in the decomposed buiness processes.
IT can experiment with SOA on its own. It can realize some benefits on its own. However, to get the real benefits of SOA a company has to combine IT and the business processes. In my opinion, many comapnies have gone as far as they can go with IT-only SOA development. Further progress (bearing economic benefit) must involve the business owners as well as IT. However, in many companies, the business processes are not documented let alone decomposed or optimized. And the effort to document and decompose the business processes can be daunting. While this definition may take a reasonable number of workdays it requires the efforts of experts within the business areas. These experts are usually in short supply and their time is extremely valuable. But large quantities of their time is required to get the "top down" approach underway.
And that what's causing the sticking point.
I'd be happy to read more of your perspective - understanding that it is your perspective and not necessarily that of your employer.
Regards,
Don Rippert
CTO - Accenture.
Don,
I'm glad to hear what you are saying about the business view. I've got a slightly re-active view about business processes in that I don't think that these are (at the very top) actually that important. If you think from a pure Business Process Re-engineering perspective that first stage is often very similar to what I think of as a Business Service Architecture, i.e. its about the domains and their interactions rather than the ordering or the detail of processes. So I tend to see Business SOA as distinct from Technical SOA (Stefan Tilkov and myself have had many productive discussions on the topic). My experience of BPM driven SOA has been that it tends to create very fine grained services which represent a static and "step" driven view.
I agree that the number of people who can do this Business driven SOA approach is very small. But my experience is that in reality if you take a business service (over a business process) view then you can do this pretty quickly (weeks rather than months). This avoids the "ordering" issue that often confuses and complicates these areas while making clear the services and their hierarchy.
My issue with what I picked out of the article is that it re-enforces a vendor created view that proposes using technology as being the solution to what is normally an issue of effective alignment of IT systems to the business model. I've seen companies claim strong SOA solutions which include BPEL and ESBs and are still a complete mess from a business perspective. This vendor pushed view is causing companies to focus purely on the technical problem and to see SOA as measured in the adoption of products rather than in the delivery of business change and actual agility. This means that IT departments are being guided down routes that will increase the complexity problems and decrease flexibility.
I'd be more than happy to continue the discussion (in my personal capacity) either over a beer when you hit the UK or via email... or even via the blog. And in terms of my thoughts on approach its all in the (non work!) book.
Cheers
Steve
Steve,
It sounds like you are saying very much the same thing as Don said in his rebuttal. Don talks about "decomposing" the Business process --- I understand that as separating out the activities involved in the process, aka clarifying the business services that are involved and their subsequent interactions with other business services. How else do you propose figuring out the "interactions of the domains" besides through the business processes?
I completely agree with you that the ordering can be very confusing and detrimental to actually identifying useful services. I also definitely agree that the technology should be an enabling tool, and in no way a determining factor.
But once you do have the services appropriately identified (whether you take a business process-oriented approach, or the business domain-specific approach you discuss) I can see how XML structuring -> Web Services -> ESB w/BPEL is a logical technological progression for implementation of the SOA.
Great discussion.
Thanks,
Lukas
my answer to SOA's death
http://architecture-soa-bpm-eai.blogspot.com/
Post a Comment