As many insurers have discovered, the risks entailed in core system modernization are not what they used to be. There are still plenty of risks, of course, but in many cases these have less to do with new software implementation and more to do with systems integration.
Any large software program has tentacles that stretch across the entire insurance organization. These dependencies are often undocumented and overlooked—until such time when a new system is rolled out and promptly begins to break other systems in unexpected ways. To correct and prevent this, the integration effort may require as much work as the new core system itself.
How then to achieve these integrations in the most efficient manner possible?
One byproduct of all the core system modernization efforts underway is that many specialized integration tools are now available. And, to take advantage of them, many insurers have established an "integration team" that groups related technical specialists together.
This approach, however, can cut against the business view of the project. From a business standpoint, what the user sees on a front-end screen is the visual representation of one or more business processes or user stories, and this is where some integration is often required. But this requires great coordination and communication. To avoid this, the agile approach emphasizes treating the user-story as a cohesive unit.
But a good systems integration approach is to combine these strategies. This keeps the integration work close to the other work being done for the user story, while also bringing specialized knowledge to bear.
Let me explain in a little more detail.
When a team works independently on a project, the structure of the software they produce will often reflect that separation. This is sometimes called Conway’s Law: that software structure often reflects organizational structure.
Likewise, when the team working on a user-story does integration work, there is a risk that the integration software will also reflect that team’s orientation and assumptions.
Having a separate team develop the integration software can lead to more independently structured and universally applicable integration.
However, this approach also comes with a risk: The generic solutions created by a more independent team can fail to fully support the different user stories and require costly rewrites.
Instead of creating a separate integrations team, one way to avoid both types of problems is to treat the integration software as an extension of the business process software with an adaptable layer between one system and another. In effect, this approach creates an integration layer between the core system and the insurer’s other systems, even though the software is developed by the core team. This helps to mitigate the adverse effects of Conway's Law. And the dedicated integration team can provide a single point of contact with the rest of the organization, thus reducing the risk of any communications falling through the cracks.
In a follow-on article, I’ll explore further how the two approaches can be successfully wedded.
