Avoiding the "I'm Spartacus" Scenario in SOA
Remember the movie “Spartacus” – the Stanley Kubrick classic starring Kirk Douglas? In the movie there’s a famous scene where the bad guy’s (the Romans) want to capture Spartacus (Douglas) who’s the leader of a Slave army. After a huge battle the Slave army is defeated and the Romans promise that no further punishment will be dished out as long as the slaves identify their leader, Spartacus. “Who among you is Spartacus?” ask the Romans. To which, one by one hundreds of guys each reply in turn “I’m Spartacus” thereby protecting their leader by creating a huge array of ‘false positive’s‘ so that the Romans can’t properly identify the one true Spartacus.
What’s this to do with SOA?
In large SOA programmes I’ve seen a similar scenario where all of a sudden, multiple in-flight projects each start to claim that they are delivering ‘the SOA’. However, in reality very none of them are because it all hinges on how you measure ‘SOA’.
This ‘SOA Spartacus’ scenario usually occurs quite soon after SOA is articulated as the primary strategic direction of the programme, but before the organisation’s SOA capability is mature enough to understand what is meant by SOA, and how it should be designed and delivered. The problem occurs because people are inherently good, and they want to be seen to be doing the right thing even when exactly what constitutes ‘the right thing’ is not terribly well understood.
The risk for these SOA programmes is that should this situation be allowed to continue, the organisation may ultimately deliver none of the strategic benefits of SOA because the project teams are not properly coordinated and each ends up doing SOA very differently.
The solution to the problem is in two parts. Part one is to have a clear understanding of what constitutes SOA in your environment by creating a single set of SOA Design Standards. Part two is to provide robust SOA Governance so that adherence to the standards is universally enforced.
1. SOA Design Standards.
Business-aligned and intrinsically interoperable service-oriented architecture can only be created by widespread adherance to a consistent set of SOA design standards. It needs to be made very clear what does constitute good SOA within your domain and what doesn’t. Your service design standards should support the SOA design principals and ensure that the goals and benefits of SOA can be achieved. The overall policy of the SOA programme should be to enforce the SOA standards using SOA Governance…
2. SOA Governance.
In order to avoid deviation from the SOA standards and policies, you need to introduce an element of governance & control across the whole SOA programme that can ensure that the SOA Design Standards are applied consistently by each project team. If you do this it’s far more likely that you’ll get the outcomes you want and that the resulting SOA will meet the strategic goals of SOA.
Finally, a simple shortcut.
If you’re planning a SOA programme, quickly obtaining maturity in SOA design and implementation will save you a small fortune and help you avoid these simple gotcha’s. If you don’t have a SOA expert on your team, then my advice go and get one as soon as possible. It could be the best decision you’ll ever make. I’m confident you’d see a respectable return on that investment in a very short space of time.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)