Most analysts are introduced to SOA in one of three ways; two of which are potentially painful and one of which is actually useful. I’ll let you decide which you would prefer.
The first (and most common) is when you start liaising with IT about the high level requirements and are told that IT are now delivering services not applications anymore, so please specify what services you would like. It is normally accompanied by an insistence that from now on all development will be internet-based using Web 2.0 technologies and Agile or Scrum methods. You may be bemused as to how this will help the archiving project you need to deliver.
Also, unless you are well versed in SOA-speak (which as readers of this column you are well on the road to becoming), it may be not be obvious what they are all about and why you should care. They will try to bamboozle you with the SOA acronyms and buzzwords I covered in the last two articles.
The second way, which I’ll call stealth mode, is where IT don’t say anything to you during requirements discussions, but sit there with knowing and self-satisfied smirks on their face, dismissing any detailed questions you may have on how they are planning to go about delivery. The first you will know about SOA is when they present you the first prototype as a set of services running on an Enterprise Service Bus.
However they won’t talk you through this as they believe: 1) You won’t understand what they are all about as they are obviously intellectually superior to you; and 2) SOA knowledge should only be released on a need to know basis. And you don’t need to know. So you don’t gain any insight that can help you in the future.
The third way consists of an ongoing dialogue between you and the IT analysts on ways of improving the translation of requirements into effective and efficient deliverables that are fit for the purpose, timely and appropriately priced. As enlightened analysts you will be providing rich process models containing the meta-data needed by IT to understand and map the business requirements onto the available existing application and information estate. In return IT will be offering standardised, readily available building blocks (services) to help to put together a rapid, agile solution for the business.
This is an iterative dialogue with both parties offering information and options to make the other party’s job easier and the outputs better. By using common and consistent terminology for the requirements (process, service, task, etc.) you minimise ambiguity and provide better insight into the optimal solution.
In many ways, you shouldn’t have to know or even care how IT deliver your project, as long as they meet the functional and non-functional business requirements. You may feel more comfortable knowing, and unless you have built up a trusted relationship with IT based on problem free delivery (well, I’m sure someone must have experienced this) you will naturally be keen to ensure IT are going to come back with the right solution.
Only one of these ways provides the mechanism for better communication and understanding of the options and constraints available. This way also provides better alignment between business needs and IT strategy. And only this way stops you from wanting to thump the smartass techie sitting in front of you spouting acronyms.
Can you guess which one it is, yet?
Let me know your experiences with SOA, so we can share good and bad practice here.
Author: John Moe is Head of Business Consulting at Alphacourt, and writes and presents widely on SOA and BPM. With over 25 years experience delivering application development and business transformation programmes, John has made most of the mistakes you will ever make and is keen to pass on this knowledge to help you avoid them yourself. In return he just expects undying gratitude and free drinks wherever he goes.