Tuesday, June 19, 2007

There is no one-size-fits-all approach to SOA

Are you seeking for that one most suitable approach to SOA? An approach that covers all your needs, respecting (the lack of) your company's IT governance, the (im)maturity of the IT staf, your heterogenous application landscape, the (lack of) innovation forces (including budget)? You won't find it.

Some projects will focus on new software for old processes, and others on new processes with old software. Or both new processes and new software (lucky you!). Or old processes with old software (bug fixing, poor you!). And then there are proprietary SAP-solutions and eSOA-based SAP-solutions and combinations of proprietary and eSOA-based SAP-solutions. Some ownerships are crystal clear, others are political disasters. Managers may not support innovation, looking forward to the bottle of champagne at the date of the deadline. Others don't like champagne, but may or may not be very stubborn on architectures they are not educated in to understand. Developers may or may not be averse to things that are new to them. Every project has its own context characteristics with regard to people, knowledge, motivation, business and technology. Not all projects are ready for new things; if you have bad luck, MOST projects are not ready.

And all of this within one single company or even worse: within one big project. So, no, you won't find that ultimate SOA approach of which the guru's let you know to put all the right things in place as a prerequisite to the success of SOA. You just can't get all the right things in place. That's not our world and will never be our world. We will have to deal with chaos. Also when in comes to SOA approaches. Take it or leave it.

But what can you do to succeed in SOA? Well, my suggestion is:

Stop trying to convince averse project teams and averse or cynical managers of the benifits of SOA. But look for curious innovative managers with charisma and seek to empower your project teams with passionated new age developers; no matter the technological or business context. And then start doing the things you think (know) you should do with an approach that fits the project context. That's how to step-by-step contribute to SOA in the context of chaos. And you don't even have to mention the word SOA. It's the teams respected - and trusted - craftsmanship, that leads to SOA and to the company's SOA-heroes of the future.

1 comment:

Anonymous said...

Excellent post, Jack. You are right: when building a SOA, find the ones that already want one and provide guidance. Building SOA where it is not desired is a diversion that few can afford.