You would think that for many SOA evangelists and practitioners the current challenging business climate would be the perfect opportunity to walk the walk on the main promise of SOA – business agility. Agility is defined as: “Nimbleness in the face of unexpected obstacles”. Well, we certainly have a whole bunch of those at the moment.
Although the vendors are pushing this value proposition heavily at the moment, the take-up is still hampered by a lack of real business success stories. And, of course, lack of budget. So I am going to look at the reasons for the paucity of real world success, and how we can still achieve business agility without having to invest too heavily in a new infrastructure.
Challenges:
There are a number of challenges for SOA to provide organisations with the flexibility that they desire and need to survive tough market conditions and even tougher competitors muscling in on their customers:
What is a Service?
By hijacking the term ‘service’, some architects have confused their business sponsors, who probably had a different interpretation of the word e.g. Customer Service, Service Level, etc. Throw in the terminology that the BPM, Process Improvement, and Lean/Sigma initiatives have introduced (task, activity, etc.), and you have a serious communication issue. Sorting out the language to be used is a key determinant of how successful an SOA-based initiative will be. Of course, this has been a perennial problem of most IT driven projects.
Infrastructure vs. Outcome
Many SOA initiatives are focused on tidying up the application and data infrastructure by reducing duplication and maintenance costs for IT. The large programmes I have been involved in were based primarily on cost-saving, with re-use and flexibility secondary considerations. Agile business projects, characterised by a tight time window of opportunity and rapid scalability requirements, tend to require specific tailored solutions delivered quickly. Many SOA teams have been unable to respond within the time and architecture constraints, leaving the business frustrated and either buying a point solution (with back end integration challenges) or an Agile development, that does not fit the Service Oriented Architecture mandated.
Opportunities:
To actually help the business achieve business agility with SOA you have to go back to basics and look at the specific behavioural changes that would need to happen in the organisation, and look at what enablers SOA can provide:
Process Driven SOA
An effective strategy we have used recently is to adopt some of the more traditional BPM tools and techniques to provide a clear bridge between the business needs and drivers, and the service delivery by IT. We have specifically used process mapping to identify the current issues and process modelling and simulation to create the desired business scenario allow. This allows the business to define their requirements in their terms, but also captures the specific services required at a high level, along with the data model, KPIs, metrics and non-functional requirements needed to define and deliver the services. To do this you will need to use a repository-based process modelling tool, that allows the detailed metadata to be captured and made available to the solution architects and development teams.
Think Big, Start Small, Move Fast
The other way we are seeing SOA finally deliver some business agility is at the tactical project level, rather than the strategic architecture pitch. Here we have found that the introduction of an iterative approach (similar to Agile techniques used in software development), applied to business problems enables the key processes and associated business services to be defined, modelled and simulated to gain clarity on the value, cost and risk of the project. Having an existing service registry and repository will speed this exercise up, and can show the benefits of SOA to the business sponsors involved by reducing the cost and delivery time. Note that this works best if the users and sponsors are just exposed to the business or high level composite services rather than the host of atomic services (data access, web, etc.) you may have.
Master Data and SOA
To further accelerate the value of SOA, a strategic view of the key data structures for the organisation is required. Too many times an afterthought or separate initiative to the SOA strategising, a streamlining of the information and data requirements, particularly the Master Data view, provides an important context for the process and service discussions. On recent SOA projects we have seen, the lack of a clear information or Master Data Management strategy has hampered the ability of SOA to provide quick and effective support for business change. This is because both the source and destination of important data are ambiguous and confused by the many data repositories spread across the organisation, and the difficulties in keeping them in sync. The common lack of a corporate data dictionary (come back Information Engineering!) means that separate project and development teams are re-inventing definitions and naming conventions, leading to significant maintenance and change headaches.
So, overall, SOA can support and promote business agility – but only when a SMART approach is taken. And for those who have forgotten what smart stands for: SMART = Specific, Measurable, Agreed, Realistic, Timely. This Five Letter Acronym is not always associated with SOA. Make sure in your organisation that it is.
