Well Accenture don't get SOA

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

1. Use of eXtensible Markup Language (XML) to use application interfaces in a more standard way.
2. Taking some business processes and turning them into web services.
3. Introduction and full use of the enterprise service bus.
4. 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

1. Services
2. Architecture
3. 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

Contract first BPEL to be in eclipse...

Ask and ye shall receive....

Yes, this is definitely in the plan for a 1.0 release. I'll leave this defect
open to track it. I'll move it to BPEL UI instead of BPEL Model, as all of the
changes that need to take place are model-related. - James Moody

Amazing reaction time from the Eclipse BPEL team, and great news on the functionality that is due to be in there.

Technorati Tags: SOA, BPEL, eclipse

Should I use the Logo?

I was playing with POVRay (my favourite SOA renderer) the other day trying to create a picture that represented my view on SOA, and the logo at the top of the page was the outcome. Crystal Ball is about the important bits and all the technology pieces are behind along with the other bits that SOA impacts.

Now I'm aware that a 40k image might be irritating and I'm a big fan myself of clean interfaces. So if anyone has any objections to the logo let me know and I'll take it down.

Technorati Tags: SOA, Service Architecture

Pharmaceutical Mashups

A few days ago Nigel Green commented that much of this "new" thinking actually goes back to general systems theory and the concept of value systems (not value chains which are a different thing completely). Which got me thinking more about how people keep ignoring the lessons of the past as if ignorance and optimisim are a design pattern.

Drinking a bit the other night with Nigel and Sam Lowe (if Sam is the Cliff Richard of SOA then Nigel is Keith Richards, been there done it, but sometimes needs to be told not to climb trees :) we got talking about all these new trendy terms like "Mashup" that are being bandied about. It really is amazing how people who haven't read (or experienced) the different challenges and solutions that have been applied over the years can suddenly leap upon something as being the silver bullet without understanding the challenges. You know the type, its all about Mashups and "Web 2.0" and guess what folks.. yup the old ways are dead long live the new. Same as when in 2000 all those bricks and mortar businesses were going to be destroyed by WebVan, Boo, Clickmango and the like. Its all become simple now.

So the question went up, why isn't everyone just moving towards Mashups in their enterprise, just dynamically assembling and deploying new applications and then seeing what survives. Its the next great hope of IT... Mashups can solve everything, its about how businesses work isn't it?

Err no it isn't, take a pharmaceutical company and apply the model. Don't worry about the FDA or all that regulation and process its just making you less agile, what you need to do is start rapidly assembling new drugs from the pieces you've got lying around, put them out on the market and then what works will be successful. Hell you never know they might start finding new drugs, or at least popular ones, much quicker this way, but yes there is the slight overhead of accidentally killing people on a regular basis, that doesn't matter though its all part of the process.

Stupid idea eh? But why should parts of IT be any different? Do you want your medical equipment to be lobbed together in a Mashup? Or an Air Traffic Control system, flight control system or the boring old HR bit that pays your salary?

People proposing Mashups and such techniques as another "ultimate" solution for IT are just simpletons. They are viewing the world through their own blinkered existence and pretending that all of the complexity that exists is just a result of people not following this great new approach and doing it in some old and fuddy duddy way. One size doesn't fit all, that is one of the great powers of SOA, it aims to help you use different approaches where appropriate. So hell use a Mashup to get that new Marketing Campaign onto the website, but don't use it to process payments from customers or create new drugs.

There is no Silver Bullet, and anyone who hasn't read that book should stop having an opinion till they have

Technorati Tags: SOA, Mashup, Service Architecture

Contract first for BPEL

Okay so I've started having a play with the new BPEL 2.0 tools from Eclipse and Netbeans, and the phrase early alpha certain comes to mind! But it is good to see that the two places where we are seeing these modellers is in the Open Source arena, and they are being developed by people who really know what they are talking about, Edwin over at Oracle in Eclipse and Charles (and Todd) over at Sun doing Netbeans.... it does make me wonder what they could produce together though.

Any how, one of the things that was annoying me is that I've become a big fan of doing contracts early on in projects. This is an incredibly new and trendy approach, designing and defining the contracts before you actually start future development, its so new and trendy that there is a paper called "Design by Contract" that was.... errr written in the early 90s. Don't you love it when people think they've discovered the holy grail that everyone has been missing for all these years? So anyway its a good practice, design the interface, in otherwords the WSDL which should have the operations and the datatypes, but unfortunately unlike Eiffel, the programming language from the guy who wrote Design by Contract, we can't define the formal contract very easily.

So anyway lets suppose that we have a new service doing Campaign Management, its a simple service that aims to automate the links between existing systems and facilitate the approval, release and withdrawl processes. So first off we define the WSDL.... which I won't cut and paste but here is the picture.

Now this is where we have the first set of problems with the current BPEL tools... I can't start with a WSDL. This is plainly rubbish and there really isn't a very big reason for it. So that is the first request: I want to be able to start from a WSDL then implement with BPEL.

Now this leads straight into problem number two. One BPEL = One WSDL but this isn't what makes sense from a services perspective, my CampaignService needs to deliver five capabilities, so I need five BPEL = one WSDL. This makes partner links easier to handle and by grouping these elements together you reduce the complexity and the clutter and provide consistency between your BPEL and non-BPEL implementations (lets face it if you had to deliver this WSDL in C# or Java you really wouldn't be looking to do it in five different classes. This separation of BPEL implemented things from OO implemented things forces more information onto the consumer that they just don't want to know about

This also helps you when you are build the BPEL as you can clearly identify calls to related elements (CampaignManagement) and calls to external things (IdentityManagement), and in the actual BPEL itself it makes no difference whatsoever as partner links are just calls to a WSDL anyway.

So here we have the two processes, one of which (create) calls the other (approve) to deliver on the capabilities of the service.

From a design, development, management, publication and versioning perspective it makes it much easier if you can have a single WSDL to describe what the service should be. Implementation languages like BPEL shouldn't be forcing us to break our service architectures because they can't cope with the idea of a service providing access to multiple capabilities. Which is the reason I raise the enhancement request to the Eclipse BPEL project. It would be fantastic if good practices like Design by Contract could be applied to all types of Web Service implementations, and not just the ones being built in OO langauges. If BPEL really wants to play well in the SOA world then its implementors need to start thinking of the service question rather than the process one.

Technorati Tags: SOA, BPEL, Service Architecture

Selling SOA Again - be clear

Okay I talked a while ago about selling SOA just being about selling, its not magic and all that.

Well I'd like to add another element to the approach...

Understand what the hell you are trying to sell first. Don't start with a vague idea about what the business wants (they probably know) and then talk in vague terms about SOA as being important.

Understand the problem, link SOA directly to the problem and most importantly don't talk about any crap that the business just doesn't care about. So what if you use Web Services, REST, Pink Pixies or a bunch a smack addict monkeys to do it... if you meet their goals then they just won't care. And don't talk about all of the possibilities... just talk about the one that you think they should do.

Be clear, be concise, be definite.

Technorati Tags: SOA, Service Architecture