Richard Pryor says if you change the structure of work processes you can keep your legacy systems
Service oriented architecture, or SOA, is a much talked about term in both the IT and business departments of many, if not all, insurance companies today. In fact, it has often been a topic in the boardroom. So is it all hype or is there some real business value to be gained from this 'new wave' thinking?
What exactly is SOA? The term 'service' is best explained as a repeatable business task that is supported by a technology implementation. Service orientation is as a way of supporting business operations by linking together these services in different ways to underpin different business processes.
SOA is an architectural style that supports service orientation. It is not a specific software product or business application.
So what does all this give you? In simple terms, it enables IT systems to better support an agile and flexible business. It also makes IT systems cheaper and easier to build and change. It is a bit like a pre-fabricated construction method, where reusable components are used in various ways to develop different sizes and shapes of building that serve different needs at different times, without having to build those components from scratch each time.
One important aspect of developing in this style is that a company does not have to throw out all its old systems and implement new ones to move towards SOA. Indeed, the ability to integrate and combine legacy and heritage applications within an SOA is a key benefit of the approach.
SOA can deliver real business value. Insurance companies tend to have to operate within constraints that result from their existing systems. Most tend to have several systems that support operations, sometimes as a result of mergers and acquisitions and sometimes due to new systems being deployed around new product launches.
Often these systems were developed years ago when business was transacted on paper, and thus were designed for back office use only. The fragmentation of the insurance value chain now demands web capability for many new business and servicing transactions and many organisations struggle to develop integrated web solutions for end-to-end customer service.
So, from an operational perspective there may be manual process steps that should be automated or web enabled. Or maybe a simple activity like a change of address has to be done in multiple systems - say once for a car insurance policy and separately for the customer's term assurance policy. And to cap it all maybe it has to be done by different call centre specialists.
But SOA can help remove some of these constraints and drive business efficiency. If done well the SOA approach enables business processes to be standardised and simplified across product lines - leaving only the product area specific processes to be executed in a unique way.
To the end-user, it would appear they have new systems, but in reality, what has happened is that the old systems have been broken down and 'wrapped' into discrete business services upon which a new user interface has been applied.
But underneath it all the legacy systems remain - remodelled admittedly - but not replaced wholesale and most importantly not having gone through a large multi-year development project, or having completed a complex, risky and expensive data migration.
Those same underlying business services can be reused within different processes with relative ease.
For example, consider a new product launch or opening a new channel to market. As many of the service building blocks for the new product or channel may well already exist, it is often possible to radically improve speed to market and reduce the amount of new IT development required.
All of this speed and agility drives out operational cost from the back-office and can improve market share, margin and market perception.
Furthermore, the SOA approach allows for a clear separation of responsibilities as it enables the IT department to focus on delivering the required business services, and the business operations to focus on developing efficient and effective business processes that use these services in the best possible way.
SOA also provides the framework for a common language between the two aspects of the organisation and joins them together in a way previously difficult to achieve.
So can IT really deliver more quickly in the SOA world? The answer should be yes. A common problem faced by IT today is that monolithic systems make even the most minor change complex and requiring a major testing effort - thus the delivery cycle can often be 9, 12 or even 18 months.
The componentised nature of SOA allows for less invasive development and focused testing, resulting in a faster turnaround of change - often as short as three or four months.
Another option that SOA opens up is the ability to replace parts of existing systems with newer more flexible solutions in a structured and lower risk way.
A good example is looking at how the SOA approach could facilitate the replacement of a document composition capability.
Typically this function will be embedded into each of the existing systems, often with hard-coded layouts - all of which make for expensive, time consuming and IT dependent changes when, for instance, regulation changes or a company moves office and changes address.
Significant cost savings can be achieved by isolating that function from within each existing system, and moving it to a new toolset that enables control of the layout to pass to the business user - again delivering real benefits, a clear separation of responsibilities and minimising the need for IT support for basic layout changes.
Ultimately, as pieces of the systems are broken out, updated and standardised, the dream of systems consolidation and replacement starts to become a feasible reality. The once huge monolithic systems can each be reduced down to their core components and then the task of replacement and migration becomes a less onerous and risky one.
The ultimate IT operational benefit of decommissioning legacy platforms can then be achieved. This leaves the business with fewer systems to learn and with systems which are more modern and usable.
So how should you tackle SOA? Well there are certainly pitfalls to avoid and it is very important to ensure that the approach is well thought through up front. You must have a good understanding of your business processes, at least the major ones, as they will influence how you design your SOA solution.
Also, don't look at SOA as just a project - it is a journey and needs to be tackled step-by-step. A good mantra to keep in your mind is: "Think big, start small and deliver quickly."
Business operations and IT should work together to identify small areas to start on that will deliver quantifiable benefits rapidly, the so called "low hanging fruit".
There are some other key considerations when embarking on the journey. Do not underestimate the need for effective governance from a combined business and IT perspective.
There are typically many business and IT stakeholders who need to be involved and communicated with. Given the more rapid pace of delivery, both parties need to give due consideration to identifying and managing the benefits that accrue ensuring they are delivered at each stage of delivery.
Adopting an SOA approach can deliverbusiness flexibility and IT agility, sought for so long by the insurance world. But beware - it is not a "cure all" or a "silver bullet". The SOA journey needs to be driven by strong business and IT champions, each with a clear vision, and supported by an effective roadmap and good change disciplines. If done well the SOA journey can deliver real and tangible business benefits including those all important early wins. IT
' Richard Pryor is the UK insurance delivery director at Unisys