Insurance workflow platform
Moving a top-ten Indian insurer from manual policy entry to a rule-driven, event-driven workflow platform. I was the architect across four projects over four years.
00 // OutcomesResults
| Measure | Before | After |
|---|---|---|
| Time to enter a new policy | Hours | Under 10 minutes |
| Throughput | About 10–20 applications an hour | About 250 cases an hour |
| Errors in downstream processing | Frequent, from manual entry | About 30% fewer |
01 // ContextContext and my role
The client is among the top ten insurers in India. Over four years I worked as the architect on four projects with a team of 18 people.
02 // BeforeThe problem
New policies were entered by hand. Entering one took hours. Mistakes made at that step carried into later processing, where each had to be found and corrected.
03 // ApproachWhat I decided
- Monolith to microservices. The single application was split into services that can be changed and scaled on their own.
- Event-driven architecture on Kafka. Steps in the policy flow react to events instead of waiting on each other, which is what lifted throughput.
- Rules instead of manual checks. Processing that depended on people re-checking data became rule-based, which is where the drop in errors came from.
The trade-off. This was the first time the team had implemented microservices and an event-driven design. The risk was time and implementation: new patterns take longer to build and get right than extending the existing application, and that mattered more because the deadline was already tight (see below).
Built with Java, Spring, Kafka, MongoDB and PostgreSQL.
04 // LessonsWhat I would do differently
The client set the deadline directly, at about half the time the work needed. I was not in the early discussions. If I had been, I would have raised the scope and the timeline before a date was agreed.
It is the main reason I now ask to be involved before dates are set, and it is on my list of things I will not take on.