Last month, I shared the reasons why I believe large policy administration systems are a thing of the past. As a follow up to that post, I would like to offer some insight into what I think the next generation might look like.
Certainly, the future solutions will leverage SOA and small re-usable components. Here is an example of a life insurance financial transaction and how it can be constructed using a series of web services sitting on top of standalone components. A series of discrete web services sitting on top of standalone components can be orchestrated to perform the overall transaction. Typically this logic is buried in code somewhere, but by doing it this way, the components are decoupled.
It is fairly easy for people to describe and agree on what is needed, but pretty difficult to actually get there. So, here is a brief explanation of the steps that can be taken.
- Build all new components to be small enough and able to stand alone – All functions your components perform must assume all data is received from the outside. They will only have access to read data that is specific to and contained within the component. All other necessary data should be received as parameters.
- Leverage an existing component when you can - To leverage your existing functionality, functionality needs to be walled off and you need to integrate with it however you can (not one size fits all).
- Separate out orchestration – Using 3rd party software for orchestration forces a discipline to make the components truly standalone and guarantees the isolation of orchestration logic. We use Microsoft Biztalk and IBM Process Server to do this. However, there may be times for performance that you need to write code to have these components truly talk to each other. This code has to be isolated into a separate level.
- Find the right level of granularity, which can be an art – I have debated this point with people over the years. On one hand, you can make every single method its own web service that can be orchestrated. The other extreme is what most people have. Like most things, the answer is in the middle and unfortunately case by case. We draw the line at useful components that can do their own jobs.
- Assume data can come from anywhere –The user interface, orchestration, web services and business process logic should not care where that data came from. The data source should be abstracted from those layers. In addition, the data translation needs to be handled “outside” your core code (either isolated in its own code or preferably in a 3rd party tool).
- Continuously eliminate redundancy – There is no way to completely eliminate redundancy, but you can certainly try. Purchasing existing components that have single functional purposes is the best way to start off with less redundancy. However, you will still have to evolve and continue to find the places where there is redundancy and pull it out.
- Use a modern “technology stack”– Wrapping your legacy keeps some of the older technologies in play, but if you limit its functional purpose, you are also limiting what needs to be maintained. The newer components can leverage more of the modern technologies and get the benefits of development efficiency as well as scalable organization.
- Implement as needed – Keep it simple and only add functionality that’s really needed. It’s important to avoid the “bloat” of having every feature possible. Only add components and functionality that is needed to run the business. By stringing together the components that are needed, you can avoid having to maintain things you don’t use.
In the future policy administration model, companies can incrementally add functionality into their enterprise without major conversions and “big bang projects”. The business can get benefits sooner and when the priorities change, you can adapt.
If you want to learn about the next generation of Life Insurance enterprise components, see www.fasttechnology.com.