Ksquare and Mulesoft: Insurance Industry use case.

Addressing Challenges

The insurance industry has been trying hard to adopt digital transformation but many insurance companies rely on legacy systems with single databases and proprietary architectures, which makes changes hard and expensive to transform and innovate.

At Ksquare we know how hard this can be, that’s why we provide integration solutions for digital transformation using MuleSoft technology.

MuleSoft’s methodology is centered on an approach that utilizes the power of Application Programming Interfaces (APIs). APIs are an immensely powerful method of integration that enables the seamless flow of data between different applications, data, and devices across your entire enterprise. To do this, organizations must move beyond point-to-point integration and embrace a new approach: an approach called API-led connectivity.

Why do we need API-led connectivity?

API-led connectivity is a three-layered architectural approach, that provides insurers with the agility and flexibility they need to keep doing business in this modern era.

Large enterprises have complex, interwoven connectivity needs that require multiple API-led connectivity building blocks. In this context, putting in a framework for ordering and structuring these building blocks is crucial. Agility and flexibility can only come from a multi-tier architecture containing three distinct layers.

Below, we have the three layers of API-led connectivity for an insurance company, where we can have full control over the entire business.

Measuring outcomes

The insurance industry can benefit from this integration strategy in all of its areas, taking technology as the lead by integrating all of its current systems, databases, applications in a single layer of communication to support all the areas of business; like fraud, claims, customers, risk management among others by exposing data assets as services to a broader audience and by allowing the customization of the information that is been delivered to these players.

All these interpretations come from business and technical benefits that we can outline in the next list.

• Technology as the lead: By exposing data assets as services to a broader audience, technology can start to become an enabler that allows lines of business to self-serve.
• Developer productivity: API-led connectivity is consistent with a service-oriented approach whereby logic is distilled to its constituent parts and reused across different applications. This prevents duplication of effort and allows developers to build on each other’s efforts.
• Predictable change: By modularizing integration logic and ensuring a logical separation between modules, IT leaders are able to better estimate and ensure delivery against changes to code. This architecture negates the nightmare scenario of a small database field change having a significant downstream impact and avoids extensive regression testing.
• Distributed and tailored: An API-led connectivity approach recognizes that there is not a one-size-fits-all architecture. This allows connectivity to be addressed in small pieces and for that capability to be exposed through the API or microservices.
• Loose coupling of systems and Greater agility: Within an organization’s IT architecture, there are different levels of governance that are appropriate. The so-called bi-modal integration or two-speed IT approach makes this dichotomy explicit: the need to carefully manage and gate changes to core systems of record (e.g. annual schema changes to core ERP systems) whilst retaining the flexibility to iterate quickly for user-facing edge systems such as web and mobile applications where continuous innovation and rapid time to market are critical. Separate API tiers allow a different level of governance and control to exist at each layer, making possible simultaneous loose-tight coupling.
• Deeper operational visibility: Approaching connectivity holistically in this way allows greater operational insight that goes beyond whether an API or a particular interface is working or not, but provides end-to-end insight from receipt of the initial API request call to the fulfillment of that request based on an underlying database query. At each step, fine-grained analysis is possible, which can not be easily realized when considering connectivity in a piecemeal fashion.