How We Simplified Use Case Development

System integrations aren't exactly what developers dream about at night (unless we include nightmares). Our team, responsible for internal business process automation, has dozens and dozens of services our bots (referred to as use cases) connect to on a daily basis. Now the problem wasn’t just having dozens of integrations – it was having implemented each integration over and over again for every single use case we developed.

Every time we built a new use case, our developers performed the same ritual: copy some existing code, tweak it just enough to work, sprinkle in some logging and hope for the best.

And when a single integration changed? You found yourself pretty quickly being Arthur Dent trying to figure out just what on quantum earth Ford Prefect was babbling about.

This isn't just a story about building yet another framework - it's about how we transformed our development process from an integration nightmare into something that didn't make you wanna quit your job when an API endpoint changed.

The Integration Nightmare We're Solving

I remember a time when developing a new use case felt like trying to solve a Rubik’s cube, one handed (the other one is obviously used to drink from your coffee mug), blindfolded, while riding a unicycle. Every system integration in every use case required custom code. Changing a single URL meant a time- consuming, error-prone expedition through multiple files and repositories. Our team’s development process was a minefield of potential breaks, inefficiencies, and an ever-growing technical debt.

This left us with only two viable options: find a solution or buy more coffee. So we did what every good agile team would do. We procrastinated. And then, when we ran out of coffee, we started out on a journey. We needed a library that would provide ready-to-use packages to connect to other services with minimal effort.

Introducing Coral: Not Just Another Framework

On our journey, we conquered all the engineering nightmares – from supporting different environments to configuration, from logging to authentication. But the challenge that took us the longest, which caused the most heated debates, was naming the damn thing. After days of intense discussions (and several empty coffee pots) we named it coral (Short for CORe Automation Library). And what exactly is coral? Imagine it being a private library. Each book representing another system, standardized, structured and neatly organized. Whatever service you need to connect to, there’s a book for that you can just check out.

Why Coral is a Game-Changer

What makes coral really easy to use is the broad availability of packages (books). Thanks to that, we were able to increase the speed to develop new use cases by about 80% while simultaneously reducing about 40% of human (developer) induced errors. Additionally, the framework unified logging, metrics and statistics across all use cases.

* Disclaimer: these numbers are totally made up

The Evolution of Our Approach

Our journey however wasn't linear. We transformed through three critical stages:

Stage 1: At first we had a single Repository. A basic, monolithic starting point. But that meant, if you only wanted a single package, you had to install everything else as well. Imagine going to a library, asking for "The Hitchhiker's Guide to the Galaxy" and the librarian brings you a copy of each and every book they have.

Stage 2: Our next approach were separate repositories. One for each package. But that created more problems than it solved because we had to manage the dependency constraints in what felt like a hundred places.

Stage 3: Our breakthrough came with the mono-repository approach. This gave us the best of both worlds, the independent packages but a centralized management.

Where We're Heading

And so, what started as an attempt to solve our integration nightmare has evolved into a solution that fundamentally changes how we approach new use cases. Coral has become our hitchhiker’s guide to the system integration. Our team’s journey is not yet finished. Right now, we are diving into monitoring, leveraging OpenTelemetry and Prometheus to help ourselves find critical issues faster in a standardized manner.

And speaking of finding things - To make the developer’s life even simpler, we plan to create an AI-powered documentation. No more trying to search a needle in the infinite haystack (so-called technical docs). Just a simple prompt field to ask the chatbot “how to do x in coral” or “what do you get when you multiply six by seven?”. Ask, and your prayers will be answered.

As for Arthur Dent, he would probably tell us that no journey is without its share of confusion, wrong turns, and occasional Vogon poetry-level code. But with coral, at least, we’ve ensured that when an API endpoint changes, the panic button stays firmly untouched, and the coffee pots remain full. In the end, the answer to life, the universe, and everything might still be 42, but the answer to developing new use cases? That’s coral.