Skip to main content

How to architect intelligent automation using the Strangler pattern: A real-world example

The Strangler pattern puts an intermediary interface in front of an old system, service, or function to advance digital transformation without losing past investments.
Diagram of circles and lines

Photo by Laura Meinhardt from Pexels

Insurance companies rely on digital technology to provide customers with a satisfying and prompt insurance experience. As digitalization in the technology world accelerates, many insurance companies find themselves in a challenging scenario of balancing the need to modernize against their heavy reliance on old (yet dependable) legacy systems. The technical debt of redundant systems and applications they've accumulated over the years drives up maintenance costs and threatens to make innovation impossible.

[ Download the automation architect's handbook. ]

Modernizing a legacy IT platform can be complex. In my previous article, I presented an overview of how insurance companies can architect intelligent workflow automation. This article describes how an insurance company achieved the full benefits of digitalization, with real-time data access, using open and secured interfaces while introducing artificial intelligence (AI) and automation to reduce manual processing.

Problem: Old, accumulated complexity

Legacy processes and systems are slow, expensive to run and maintain, and do not capture modern customer demands and needs. Insurance companies are rapidly trying to introduce automation, data analytics, and AI to address the large amount of manual work required. It's not as simple as throwing away the old ones and rewriting the whole process. Companies spend years investing in technologies, which can be risky and wasteful. The ideal scenario allows a digital upgrade without losing their past investment.

The insurance industry faces some common burdens, which I'll examine more closely below.

Many manual tasks in processes

Claim intake requires tedious, repetitive work done by human beings. Employees spend hours on simple tasks, like receiving paper claims, organizing them by type, validating submitted materials, and confirming them by pulling data from several places.

Separate systems handle different processes.

Many different systems and technologies have been used to implement automation over the years. However, all product lines are not equal.

Each insurance claim process is unique. This, coupled with new and altered regulations throughout the product life cycle, makes it challenging to use 10 (or more)-year-old technology to meet policyholder demand for a rapid, straightforward claims process. This results in "swivel-chair" syndrome, where employees use several disparate systems to get their job done.

[ Download the eBook: Modernize your IT with managed cloud services. ]

Data replicated in multiple places

Because there have historically been multiple systems involved, data often needs to be replicated for each one. It's expensive to physically store, replicate, and develop high availability (HA) strategies. And synchronizing the data, minimizing data latency, and getting the latest updates is a complex and time-consuming task, requiring coordination across systems.

Solution: The Strangler pattern

So how can insurance companies go about architecting solutions that address these needs? One way is to use the Strangler pattern.

The Strangler pattern is not a new concept for architects, and as morbid as its name may sound, it's actually a good thing. I talked about this all the time when doing monolith-to-microservice migration back when that was still a new concept. The first place I saw this was in Martin Fowler's blog that expressed the analogy of the "strangler fig," where a tree's upper branches gradually grow their roots in the soil to replace the main trunk.

[ Learn more about getting a handle on and alleviating technical debt. ]

The Strangler pattern puts an intermediary interface in front of an old system, service, or function. Over time, the new interface replaces the old part with the new one. There's no interruption in service. The same concept can be applied to complex, process-heavy systems with different granularities.

Co-exist with legacy and accelerate with new

When applying the Strangler pattern in the process, consider the following points:

  1. Determine the current gap in user needs and the ideal user experience.
  2. Identify different processes and where they reside.
  3. Pinpoint repetitive manual work. These are likely replaceable with robotic process automation (RPA) and AI automation.

This example (source: Denzil Menezes, IBM) is based on a successful insurance company and how it applied the Strangler pattern.

schematic to coexist with legacy and accelerate with new implementations
Click image for larger view (Christina Lin, CC BY-SA 4.0)

In the diagram above:

  1. A new process can be accessed with an API endpoint, managed by an API management platform for security and access control. The new process consolidates new and existing processes (this is the interface of the Strangler pattern). When the process starts, it calls the other tasks, services, and processes using API calls or through events.
  2. The digital worker represents software robots trained to perform tasks on behalf of and in partnership with their human counterparts. Depending on the company's needs, activities can be automated with RPA and intelligent automation, such as conversation intelligence. It depends on whether the activity, decision, or operation is made by a predetermined data model, a third-party service from vendors, RPA bots, or existing processes. In the intelligent claim scenario, a combination of conversational intelligence and digital workers that "understand" human intent take action on behalf of the human while keeping the human in control. When applying the Strangler pattern, you can simply reuse the legacy processes and replace them with new AI-enabled ones.
  3. Utilize past investment by leveraging preexisting processes. Translating data formats is a common problem with calling an existing service or process. A connector here helps transform data input and output to the receiver and requester. The processes are frequently built in a closed system, so there are often API or REST endpoints providing access. Sometimes, you might need to use a special connector for its protocols with much older systems. Additionally, many customers have significant investments in code on their mainframes or other legacy systems. These can be exposed to newer cloud-native developments or cloud applications as RESTful APIs and without rewriting underlying code.
  4. Companies often want digital transformation specifically to take advantage of AI provided by AI tools. Through AI, you can enable a digital worker to request predictions and decisions from a machine learning model automatically.
  5. Customized services for specific enterprise needs are common. They're often implemented with microservices. Digital work can call either a single service or orchestrated services.
  6. Red Hat OpenShift provides a unifying dashboard for a seamless user experience. It also provides enhanced real-time features to customers through both a website and apps. An open API gives partners the ability to amplify and deliver better services.

Building new solutions

Upgrading a technology stack is vital to continued success within any industry as companies move to large-scale digital transformation. Most importantly, though, it enables transformation without disruption and focuses on solutions that are right for each company's unique history and requirements. Build new solutions around your old technology, and empower your employees to grow with your business.

Author’s photo

Christina Lin

Christina Lin is a Red Hat Portfolio Architect. She is an advocate for making innovative solutions down to earth and making them easily accessible for everyone. She is a speaker at many technology conferences around the globe. More about me

Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.


Privacy Statement