Monday, 28 December 2009

Doing SOA the right way


Here are my 4 points:

1. Understand the diversity, and the evolutionary law: everything will always change. You might think that you achieved a lot by homogenising today's mess, but just wait 5 years and then have another look. Thou must always translate - and leaveth that to professionals. There is no one-size-fits-all

2. Diversity as in applications, but also as in languages spoken. In Europe, 2,000 years ago Greek and Latin were cool, then vulgar Latin took over, French was okay since 1600, English rules since 1900.
And I'm just talking global political / economical languages. Within every country there'll always be spoken native languages, and within those, dialects. Your enterprise business language should be flat file, unless there's real reasons to deviate from that

3. Focus on the business. How do we ensure interoperability? How do we agree on semantics? How do we prevent our SOA from being utterly incompatible with any other SOA implementation in the world, because we just tailormade our own IT? Communication starts with agreeing on the topic, not with the language or devices used

4. Copy and paste, don't reinvent the wheel: Royal Mail, SMTP, queueing sytems, those all have proven the simplicity of enveloping any message. Why even try something like SOAP? Why hammer at XML? Why let your life depend on volatile debates around WS-anything? And why should all that be in WSDL? To keep out the business? Plain old-fashioned EAI with a canonical, that's what a SOA should look like

That does indeed look like I'm advertising for old tech. And I am. Let's see how you can SOA your enterprise with old tech. That's one problem down, one to go. Life's complex enough as it is, no need to make it complicated.
Of course, having done that, you'll find that speaking any "foreign language" is just a matter of opportunity.
You'll speak XML if that comes in handy, just translating your canonical business language into that. You'll happily throw away your envelope and wrap a message into another, if business requires such

Service-oriented architecture? How about business-oriented IT?

0 reacties:

Post a Comment

Thank you for sharing your thoughts! Copy your comment before signing in...