Although you can do ‘standard’ requirements gathering for Service Oriented Architecture (SOA) projects, there is now an evolving a set of analysis techniques, methods and approaches that purport to be better suited to information gathering and design specification. I will call these generically Service Oriented Analysis (which I won’t shorten to SOA as this will only lead to excessive confusion). I should also make clear that I am talking about business analysis not technical specification, for which there is a more detailed version of this that code monkeys and technocrats use to design and deliver their services.
Image © Joachim Wendler - Fotolia.com
So what is different about Service Oriented Analysis? To start with, it comes in many flavours, like quarks: I’ll be talking about Top Down and Bottom Up – I’ll leave the Strangeness and Charm flavours for you to work out.
The Top Down approach is similar to your normal business analyst activity. Identify which business processes are affected by the requirement. Do impact analysis of predicted change, highlighting risks, gaps, bottlenecks, etc. So far, so standard. However, we diverge from classical analysis at this point. We next look to see what processes or business services exist already (in the Service Registry or Repository) that could provide some or all of the functionality to meet the business requirements. We should also understand what current business policies and business rules are available (typically in a policy repository or Business Rules Engine). These existing processes & services are then put together in a high level ‘straw man’ design, and workshopped to agree how to supplement what exists, or change some of the characteristics of the current services to fit (providing they can still meet the current functionality for the original applications they support).
The Bottom Up approach takes a more pragmatic view of maximising current investment in services (and maximising reuse) by mandating the use of pre-built services to deliver the requirements. If it looks like there is not a good fit, then the requirements would be reviewed to see if the business objectives could be achieved by changing the requirements to meet the available services. Although this may seem less than user (or business) friendly, it has two strengths that are worth considering: lower cost and shorter time to deliver. The time savings come from the reduced development and testing lifecycle required by re-using existing services. Although there may need to be a new high level process or workflow to meet the business need, this is a much smaller effort. In terms of cost, lower timescales coupled with lower resources required lead to significant expenditure savings. Of course, we come back to the eternal triangle of cost-quality-time to agree their relative importance to the business.
My experience of both these approaches is that the choice depends upon a number of factors:
-
The SOA maturity of the organisation. Without a set of core services and the service oriented infrastructure it is difficult to take the Bottom Up approach. Top Down is possible in unreconstructed environments – you just have less existing services from which to choose.
-
A strong programme governance culture. Telling a business sponsor that his pet project will need to use (and conform to) someone else’s processes and services takes the Teddy Roosevelt approach – “speak softly and carry a big stick; you will go far”. This is essential for the Bottom Up approach, and useful for Top Down.
-
Business Analysts comfortable with SOA. Bit of a Catch-22 here, in that you need to do these types of projects to get the experience. Many good analysts will get this intuitively if they can see the benefits to themselves and the business users. Some general education on SOA (see my previous articles) will provide the context and terminology. The BAs will need to decide if it is an approach they are willing to pursue.
Another advantage of the Service Oriented Analysis approach is that it fits well with lean management techniques aimed at streamlining business processes and reducing waste activity. Enforcing the service approach helps to embed and extend a shared services approach and adoption of consistent and repeatable best practice across the organisation.
Obviously, for Service Oriented Analysis to really deliver you need to have the existing services, a service repository and a strong governance culture that will enforce the behaviour required to make this approach work. I suspect you may have some of this in place, but not all. Even so, you should now be able to understand how and when Service Oriented Analysis could and should be used.
To stretch (or possibly murder) the quark analogy further, Charm will get you a long way on the road to making this happen. I’m sure none of you are charmless, but your powers of persuasion will prove invaluable when the governance (i.e. protection from above) starts wobbling, as it always does in high pressure projects. Strangeness, however, may make you memorable, but not always in the best way…
Author: John Moe is Head of Business Integration at Tori Global, 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.