As the first article in what I hope will be a long and distinguished column, I would like to begin by defining what SOA is and what you need to know about it. In future articles, I will explore some of the challenges and benefits of SOA to the analyst community. Let’s start off with a definition of SOA.
You can, of course, look at a number of definitions of SOA on the Web, but you will find them confusing and contradictory as there are a number of views on this ranging from SOA is everything, to SOA is just Web Services, neither of which is true. So here is my guide to SOA for the BA:
What is Service Oriented Architecture?
- SOA is an architecture principle, not a product or tool
- SOA is comprised of a set of loosely coupled business services
- Services can communicate via standardized interfaces
- SOA masks the underlying technical diversity and complexity
- Composite set of Services viewed as Integrated set of reusable blocks
How does SOA work?
Many of the concepts of SOA have been around since the early days of computing in the form of subroutines, the ISO 7-layer Model, object-oriented programming, etc. In principle, SOA involves separating the traditionally monolithic IT applications into separate horizontal layers - such as presentation (e.g. a portal), business logic (e.g. process logic), application and data logic (services), etc.), - and separate functionality encapsulated into discrete objects (services), that have a defined input, transformation and output.
The idea is that by creating a set of building blocks (I’m sure you can picture the overused Lego analogy), any new system can be built by re-arranging the blocks in a different way rather than having to write everything again. It is the horizontal separation that has most impact on the Business Analysis world.
However, SOA has a business dimension missing from traditional IT n-layer models. SOA works best when married with the needs of the business and describing the service back to users in their terms as business services. This means that the business user or stakeholder will just need to describe what business function or task is required, in the context of key business processes, and SOA should deliver these services in the way the business wants to consume them.
To do this IT services (such as get customer record) are aggregated to composite IT services (e.g. lookup customer details, to get different customer information from different applications), and finally business services which give the user high level functionality (e.g. credit check, taking customer details and validating with both internal and external authentication services), and returning a smiley or percentage to aid the decision the user needs to make.
Why Should I know this?
The main initial impact for Business Analysts tends to be around the changes to the project lifecycle required for SOA. The lifecycle of SOA projects differs from the two other main development methodologies: Waterfall, and Agile. The SOA Lifecycle works as follows:
- Model: Gather requirements using a Process Modelling tool to graphically capture the current processes, along with all the associated metadata (resources, timings, costs, KPIs, risks, etc), and model the proposed optimised processes. These processes may have some business or IT requirements that need to be delivered by services.
- Assemble: Based on the requirements from modelling, existing services are reviewed for potential re-use, and new services are discovered and sourced from other service providers or encapsulated and developed as new services. These services are assembled into a process flow which controls the way in which the services are used.
- Deploy: These services are integrated with the necessary people, processes and information flows. This integrated solution is then deployed through test to live production.
- Manage: If a change is required, the process model is revisited and re-modelled to determine the best way in which the change should be delivered. This could be procedural changes (affecting the behaviour of users), process logic changes (changing the way in which services are invoked), or service changes (where specific services are replaced with other services, or modified to change the functionality of the service). Because the process is more loosely coupled, there should be less impact on the rest of the processes and decrease regression testing requirements.
Does it Work?
Yes and No. When it works it can deliver real value. Unfortunately this has proved more difficult than anticipated, which is where the analyst comes in. I’ll talk you through some examples and more detailed descriptions in later articles.
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.