Software as a Service and Service Oriented Architecture – Why they fail to meet the hype in execution

The hype factor has done it again. We are all left starting at each other for just what in the world we all mean by SOA. ENOUGH! It’s not that hard, and consultants, (myself being one so I will not be overly critical), vendors, the media, etc. have DESTROYED yet again any meaning in language. N-Tier, Message Bus, etc. etc. it goes back 20 years! The pattern never ends..

Not to be a terrible bore, but brush up on your Wittgenstein lately?! Ok don’t go that far just yet…(grin).

 First, a Pattern Language (P.L.) is not some academic concept, although many would like you to believe that.

 

NOTE: I take issue with the word design below… It should be far more broad in most cases, but it often gets boxed into the design aspect of a problem. I would say ‘best practices’ which brings up its own semantic mess…

A pattern language is a structured method of describing [best] good design practices within a field of expertise. It is characterized by

  1. Noticing and naming the common problems [and positively executed solutions proven over time] in a field of interest [domain in my words]
  2. Describing the key characteristics of effective solutions for meeting [one or more] some stated goal[s], [Often patterns are combined and are multi-faceted]
  3. Helping the designer [domain stakeholder] move from problem to problem [and challenge to challenge] in a logical way, [in an attempt to reduce and even eliminate ambiguity] and allowing for many different paths through the design process.

- Wikipedia 

  1. This ties in perfectly with my claim that complex software engineering is a ‘wicked problem’. If you disagree then you can stop reading, as none of my assumptions will work. However, I would love to hear your arguments since only around 20-30% of all software projects ‘succeed’…. There is no doubt there is dreadful crisis which I know you know about so enough said.

If the fundamental issue here is NOT that people cannot/will not see software engineering for what it is, then what?!

Wicked Problem

FYI: This is also why your pretty much nuts to not be Agile at this point, with some critical exceptions.

OK just to get you started chew on these 10 basic characteristics and tell me how any of them and the failure of senior stakeholders to understand that indeed software fits these characteristics is likely a key systemic disaster which we see and live every day in this industry. Click here for more.

 Before I was able to ‘take this deck on the road’ which I have done now with success (and why I am revisiting this post to offer insights), I had to get the audience (I hate to call them that… The collaborators is better) knowing (for example) that SOA was not a damn bunch of web services! I had to get people understanding exactly how distributed objects and components ARE NOT THE SAME but are similar. etc. etc.

That ASMX pages in .NET are not even close to what you want to be doing, even with WSE 3.0 and ‘Contract First’ techniques (most notably the WSCF add-in from the always amazing thinktecture).

There is nothing more necessary than truth, and in comparison with it everything else has only secondary value.
This absolute will to truth: what is it? Is it the will to not allow ourselves to be deceived? Is it the will not to deceive?
One does not want to be deceived, under the supposition that it is injurious, dangerous, or fatal to be deceived.

Friedrich Nietzsche, 1890

Thanks Herr Nietzsche… None of us want that. So “Listen for the speakers intended meaning, not your perceived definition”.

In this rather philosophical vein, I offer you here an attempt at the beginnings of a unified P.L. covering many best practices we have evolved in the SOA/SaaS space.

As stated, this presentation is born from necessity as it has become almost impossible to have a meaningful conversation on many topics in this domain due to ‘definition overloading’.

This presentation not only attacks that issue, it also brings together into a cohesive pattern language Object Orientation, Distributed Objects, Components and Services while being careful to not make overly broad generalizations that would harm any SaaS initiative.

For example, it is a best practice to evolve a Domain Driven API which is (at a minimum) the core APU which your services will use to fulfil their contracts.

The presentation is here and feedback is encouraged. This also assumes you have embraced either the SCA environment (for Java development) or WCF for .NET. These are (in our guidance to clients) the only relevant implementation frameworks for strategic large scale organizational transformations to SaaS.

Otherwise in real-world terms there are not resources (developers, or the dramatically increased effort with very little benefit) available to support other approaches. Many ‘purists to the extreme’ might attempt a hand-crafted ‘build it all over again’ approach with hand-crafted contracts (typically XSDs).

As these environments support full extensibility, indeed it is incredibly rare that one of these environments will not completely address your needs. Of course there are always exceptions, but this is addresses to 95% of the market.

Due to the immaturity of this space, it is alarming how many companies believe they are not part of that 95%!! Typically they are being driven by parties (internal or external) that have motivations not in line with the business drivers.

 

Post a Comment