Skip to Content

SOA what?

For more then 20 years, I’ve been branding myself a developer. Or systems analyst. Or both. My focus has been on one simple principle: enabling my clients to get the work done. Whether this involves creating a new report for the finance department, or importing master data into a new system, or enabling two applications to share the same information, the focus has always been on one goal: to get the job done.

Reduce costs. Reduce complexity. Share and collaborate, as opposed to ensnare and segregate.

I’ve seen a few paradigms come and go along the way. I initially regarded, with mild disbelief, the advent of BW some 20 years ago. Disbelief, because the idea of actually using these accumulated loads of data for something as prosaic as business decisions, was, to me, a perfectly transparent, implicit reason for storing the same data in the first place.

Or not?

Then, along, came CRM. CR what? Aren’t we all in the game because of our customers? Did the advent of CRM simply imply that a large number of businesses, for whatever obscure reason, did NOT recognize their clients as the only reason d’étre for their own existence (or bottom line)?

Apparently not. Until some bright heads finally decided to turn around and see the light (or, more to the point, formalize and cash in on the concept).

Now, the buzzword is SOA. Or was, until it’s proclaimed death on January 1.

Don’t get me wrong; as with all paradigms, SOA springs out of the accumulated momentum created by some hitherto unarticulated need, finally crystallizing itself in an explicit concept and crowned with its own acronym (phew. I need to restrain myself. Sorry guys).

The principle behind SOA is, as with most paradigms, at least those not intertwined with politics, good. Companies need to communicate. They even need to talk to themselves (something that at times can seem as even more of a challenge). And they need to do so without the complexity of designing and setting up millions of interfaces or acquiring intimate knowledge of each other’s technological underw…, er, infrastructure.

(Digression: if we all spoke English, ran Windows on our PCs and used MS Word for our documents, the world would be a far better place. And Bill Gates would have more cash on his hands to help fighting strange diseases in remote countries).

Instead, to achieve our goal, we create Services. Services to hook up and integrate processes, facilitate the flow of data, making business better. Improving life. Not to mention reducing costs.

And here’s my point.

It seems to me that, somewhere along the way, we forgot how to KISS.

Keep it simple, stupid.

SOA sounds simple. It should be simple. And yet, along comes the army of techno-geeks with their ever-persistent intention: to complicate. To confuse. To bewilder and obscure. To transform those clear, spring-like waters into murky pits with no bottoms.

I may just be technology-sceptic. For me, technology has always been the means to a measure. The way to get there (even if “there” has, sometimes, been an elusive and fluid concept). Or maybe it’s just my long-standing aversion against the sheer tediousness surrounding everything even remotely related to Java and J2EE, with their hundreds of components and procedures needed just in order to scream your Hello to the World, that shows here, but some times the sheer complexity and opaqueness of the new paradigms just, sort of, leaps in my face.

The evangelists of these new ways to solve that one simple, underlying need of Business, namely Communication, some times behave like young adolescents in a chat room, wielding an ever-growing range of new, shiny gadgets whose functionality creates ever more possibilities of doing things you didn’t ever perceive as being even vaguely relevant in ways you’d never thought you wanted to have to learn.

Or maybe a better parallel is the real evangelists, each preaching the supremacy of their own flavour of institutional superstition, cheering their gods, feverishly proclaiming the only way to salvation lies within reach by adopting their own brand new version of the scriptures. Heaven 7.0, here we come.

The blog series on how to provide and consume web services is just one example of how, in my humble opinion, what should have been a focus on simplification and productivity enhancement simply seem to transcend itself into a giant wave of technological muscle-flexing, completely overshadowing those very same goals.

Here’s a list of steps from the 360° View on enterprise SOA: Provide and consume your own enterprise services – Enterprise Service Provisioning on SAP NetWeaver Using Apache Axis Web Services Framework (Part 7b), describing how to prepare thyself for the consumption of enterprise services, the SAP way:

1. Download and install Axis2 from http://ws.apache.org/axis2
2. Download and install Ant if you don’t have it (http://ant.apache.org/)
3. Use the WSDL2Java tool to create the skeletons for you service from the WSDL
4. Implement the service in the generated Java class
5. Generate the *.aar file with “ant jar.server”
6. Package the resulting file in a WAR and then EAR file
7. Create a J2EE Library with the NetWeaver 7.0 Developer Studio for Axis
8. Deploy both the Axis2 Library and the EAR file containing the service
9. Validate and configure the Axis2 runtime
10. Upload the *.aar file created earlier with the Axis2 web frontend

I’m sure this process is a piece of cake for anyone proficient in J2EE concepts and technology, just as I’m convinced I’m putting my head on the block by writing this, but my main point still stands: are we, in the process of transitioning to, and adopting, these frameworks, these concepts, these vastly superior solutions, simply missing what was supposedly the main objective of this technological paradigm shift, namely getting the job done?

Or, otherwise put: simplicity for whom? The developer? The architect? The systems administrators? The end user? The Business?

The world?

For me, the above roadmap looks, as if not the SOA sibling of the Karakoram Highway, then at least something uncomfortably close and just as perilous to navigate. True, the author asks the rhetorical question “why is this so complicated” at the end, and answers that the reasons partly lie in Netweavers current lack of integrating and generating the necessary functionality in its 7.0 version.

Which, of course, could be defended by stating that we’re still in a transitional phase, technology-wise.

(We’ve been enduring that particular phase for a few decades, now.)

Maybe my long-standing scepticism stems not so much from the (mainly) Java-based concepts themselves, but the cloud of complexity surrounding them? As a developer, my preferred attitude has always been to seek out the simplest, most elegant solution to any problem, disregarding its complexity. The ultimate motto of Keep it simple, stupid, seems to have evaporated somewhere along the transitional way to our Brave New World. It seems to me that what we achieve using the “traditional” tools of the trade, namely ABAP and it’s ever-enhanced box of pragmatic utilities (BSP, Web Dynpro, XML transformations, Web services…) can only be replicated on the Java stack by increasing the sheer amount of work (not to mention the number of components) by a factor of something well above 2.

Questions of performance, stability, and accountability springs to mind, too. Reliance on open-source products is an interesting discussion in itself; add to that version control, compatibility, support, interoperability, and you may (at least theoretically) envision even more issues and problems. When you start building a beast out of assembled pieces from a range of vendors, you do so at your own peril. Possibly. Or, as i tell my son: whatever you do, don’t mix Lego and Meccano. Won’t work.

Who’s gonna manage all these interlaced bits and pieces?

Of course, I’m ranting to no avail here. Whenever there are new tools in town, there will be new schools of people flocking to use them. Like the new breed of “alternative” rock bands (where are the real rockers these days?), they pop up overnight, peak at noon, and wither away before sunset, just to be replaced with a new bunch. And, of course, as camps and lairs flavours and attitudes multiply, there will be tribal wars, changes of course, new paths to follow, some leading nowhere, some leading, well, somewhere else.

Which, in and by itself, is good. I’m not against the tools, nor the need to change. Change is good. Sometimes. Diversion is good. Sometimes. Being able to choose from a wide palette of tools is good, more often than not.

But I’m still not sure I want those Ants crawling around my system… 😉

(This blog was written during a complete lapse of consciousness, and should therefore not be held against the author in any way)

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Geoff Sadler
    As a Business Analyst designing a SOA methodology that has to work in a diverse product range landscape, (i.e. not just SAP) I totally agree.

    SOA is a simple concept confused by vendors and technology.  As a developer I was creating a form of reusable services 19 years ago on a Unisys mainframe, (great for reuse from inside the mainframe, bad for outside). 

    The concept of reuse is not new, the concept of standard messaging is not new, so why is SOA painted as this complicated techo thingee???

    When I want to reuse something why can’t I just point and click?  Let the vendors product work out the rest. 

    Good Blog

    (0) 

Leave a Reply