f3yourmind

Anne Thomas Manes wrote a farewall for SOA in her blog post SOA is Dead, Long Live Services.  InfoQ asked for comment from SOA thought leaders and architects on this matter which created quite a stir and the usual amount of noise as well.  One of the most interesting responses I read was from Stefan Tilkov in his blog post Defending SOA.  Now I cannot resist, but give my perspective.

SOA is an attempt to create an architectural style that embodies the heart of the business – the domain.  In any business the domain is vast and so there are many subdomains or even very distinct domains.  In my workshop on Bootstrapping Your SOA Project, I defined a service very traditionally as providers and consumers connected by some execution context that hides implementation.  Now, I like to abstract it a bit more and think of services as business intentions.  These intentions cut right through the fat and get very close to the bone which is all about the domain.  That’s why I think DDD is at the heart of SOA.

Is SOA dead? Not yet but the vendors are doing a great job of killing it with implementations.

Should SOA die? No.  it’s an architectural style worth cherishing since it deals with legacy and new software at the same time, hence spanning multiple systems (like Stefan Tilkov nicely explains).

Does SOA need an ESB? Not necessarily. I think the ESB is just a pattern that happens to have an implementation called the ESB (vocabulary that sucks!).  I have seen some some really complex solutions with an ESB that would have worked just fine with, for example, a simple RMI call instead.

Is it about Business Process Management? Partially.  When you span multiple systems then you will likely do so with processes.  But it’s all about managing state across multiple systems and what nicer way is there than transferring state, i.e. being RESTful (and I am not talking about REST over HTTP).  This also suggests that you should think asynchronously as well.

Is SOA heavyweight? No.  But the vendors make it very, very heavyweight because that is the core of their economic model.  I like to think about all the little Unix command line tools that you can string together to solve a particular problem, like the FindAndDeleteAllOldLogs capability that is part of the FileManagementService

What is killing SOA? The lack of readiness for existing systems that comes from existing software development thinking in most teams.  SOA demands that you think about state, scalability, ownership, backward compatibility, testability … things that go towards creating decent API’s for your systems.  And the more vendor swagger we have, the less development teams think about API’s.

Is SOA Dead? Yes.  It was still born.  But it will be reincarnated as SOA when vendors focus on tools to help people discover domains and increase automation, and not creating heavyweight obstructions;  and when developers figure out that domain understanding is vital and writing good API’s  still count – more than ever before.

I was talking SOA – again! I was arguing that modeling of services in UML, BPEL, and any other fancy acronym immediately constrains you to a specific implementation.  For example, UML means that your are thinking OO already, BPEL means that your are thinking business processes already.  But are those (and others) the best ways to model or represent a service?

In SOA, I have a suspicion (as yet untested!) that a service is closer to an intention than anything else that I can think of because it describes the latent value of the business that invariably is lost by SOA implementations and product stacks.  Now that leaves us with a problem – how do you describe intentions consistently across any domain?   I don’t know how to do this because to describe intentions in a domain, you need to understand the vocabulary of the domain.  Until we can represent vocabularies then only can we create a metamodel for these business intentions.

So how do we model intentions in a single domain since I cannot use UML (implementation!), XPDL (implementation!), BPEL (implementation!) etc?  Since the domain is constrained by its vocabulary, we need to create a language that uses this vocabulary.  And that, my dear folks, is nothing but a DSL.  If we, therefore, model intentions (the services) with a DSL, then we are in a position to translate or transform that intention into any implementation that we like.  Realistically, we will likely need additional metadata surrounding the intention described in the DSL to satisfy UML, XPDL, BPEL, WSDL, RESTful APIs, etc.

When we think of the business as what they intend to do or achieve, then we are actually working at a higher level of abstraction – at a meta-level.  That is hard to do, but if you do it reasonably well, then you have more freedom when it comes to implementation.

SOA is so screwed up at the moment and most are climbing into or out of rabbit holes because the business intentions are being ignored or forgotten far too early or thought about far too late.  Perhaps the most effective SOA implementations will be realised with a suite of DSL’s and the only toolset that you really need is a language workbench and some very skilled language oriented programmers.

I had a really interesting discussion this morning with two bright people about their SOA journey.  They are responsible in many ways for moving their rather massive company to SOA.  So we chatted about all sorts of things and argued and disagreed and converged and disagreed again and got confused and converged again and diverged again … and then we realised 2 hours had gone by and we all had other things to do.

Driving back to my office, I was bothered by the fact that we were struggling with how to implement this thing called SOA.  And I also have a feeling that there are more SOA failures than successes in the world.  And all these contribute to experiential knowledge for the greater good of our geek community, blah, blah, blah.

But I did not have a clear cut solution, neither did they, neither does their vendor partner (for sure!), nor their management, nor anybody!

So, I am now convinced that a SOA implementation (not theory!) is a wicked problem.  Wicked problems come from social sciences to describe an extremely difficult problem to solve, even impossible because of contradictory or ever-changing factors or incomplete requirements.  Some characteristics of wicked problems include:

• every solution is a degree of goodness (or badness) but there is no distinctly right or wrong solution
• every solution is a one-shot solution because you don’t have room for trial and error
• consequently, every solution attempt counts immensely … positively or negatively
• there is no uber-test of a solution, so the proof is in the execution (my TDD blood froze about now )
• each problem is symptom of another problem, indefinitely, i.e. there is no stop rule.
• stakeholders all hold different understandings of the domain
• there is no solution, but the problem is understood only after a solution has been crafted.

And last, but not least … maybe the most telling is

• Those that are held accountable for the consequences of the solution have no right to be wrong ! Ouch

I think that some architectural things feel like wicked problems.  Read the work of  Jeff Conklin and Robert Horn, two guys that spend a lot of time researching tools for solving social messes.

I’ve mentioned it in bits and pieces before but now that the nice folk at Oredev have more or less finalised their program, I can put the down the talks I will be giving in November 2008.

• Architecture Track: Designing for Modularity – one of my pet frustration and, at the same time, fun challenges.
• Agile Track: Managing Diversity in Agile Teams – based on two years of experiences at a rather tough client.
• Java Track: Solving Domain Problems with Aspects – another big challenge for me since aspects are normally used to solve application infrastructure problems.
• Workshop: Bootstrapping your SOA Project – this is a modified version of the workshop I did for IQPC earlier this year.

I certainly did not expect to be doing 4 sessions!  It’s going to be a busy conference but also immense fun.  I hope that I get the time to attend the other talks and learn from some amazing people.  I certainly will be catching up with old friends as well

Yesterday I had a really fun time running a workshop at the IQPC SOA conference on Structuring your SOA Project.  It was interesting to see that SOA is still not clearly understood and that the “silver bullet” answers are a still being sought after by a few.

The heart of my workshop centered on the theme that you cannot steer clear of business or domain knowledge, even if you try to design your services by wrapping existing software assets.  It just has to align to reality in the business, otherwise you will just create another architecture that has a fractured line to the business needs.

The other interesting theme that arose, unintentionally, was that it may well be easier to sneak in SOA by thinking in services and building some solutions covertly.  Once value is delivered and becomes noticeable, then start spreading out to the next cell … almost virally.

I summarised the main thoughts in the article on DZone at http://architects.dzone.com/articles/top-down-soa-aligning-business.