How A Failed Handover Became A Manageable System

tl;dr

• Context: Insurance
• Opening up a document management system (DMS) for data exchange with external partners
• Carving out an existing application to a new owner
• Documenting the “black box”
• Building business and technical expertise
• Establishing operational capability in the event of incidents and anomalies
• Enabling changes: fixes and further development

Situation: Thrown Over the Fence

The initial situation was a classic “over-the-wall” problem: An internal development department built a service and then handed over operations to another operations department. The transition occurred without any significant knowledge transfer and without reliable documentation. This led to a massive knowledge gap in operations.

Challenge: System Out of Control

In practice, this situation caused critical bottlenecks. In the event of incidents, the operations team was barely able to understand problems in depth—let alone analyze or resolve them independently. The consequences were:

• Unacceptably long response times
• Lack of structured processes for troubleshooting
• Diffuse responsibility structure (no one felt responsible for the application’s stability)
• Massive user dissatisfaction

Solution: Self-responsibility

A metamorphant consultant was brought in to support the business operations. The client’s initial reason for choosing them was their expertise in Camunda, BPMN, and Java/Spring Boot microservices.

As is typical with metamorphants, the consultant also brought many other skills, including:

• Application architecture
• Interface design and evolution
• CI/CD (Jenkins, Spinnaker)
• Distributed container runtimes (Kubernetes)

They ultimately took the initiative to transform the application from a “black box” into a manageable system.

Analysis & Empowerment

Thanks to the consultant’s generalist approach, they were able to quickly grasp the business and technical complexity. He identified the core problem and independently familiarized himself with its functionality.

This was achieved through intensive personal networking with:

• The original developers who had moved on (defying the silo mentality of the existing culture),
• Business users of the connected applications,
• Internal infrastructure and basic service providers,
• Cross-functional departments (e.g., Governance),
• External interface partners.

The implementation took place in four main steps:

1. Knowledge Capture: The colleague created comprehensive documentation of the processes, functionalities, and business purpose of the application.
2. Code-Level Troubleshooting: Unlike pure operations staff, the consultant was able to leverage his development expertise. This allowed him to make targeted corrections directly in the program code in the event of technical or functional failures.
3. Creating Transparency: The employee built a dedicated business monitoring system for the integrated application to proactively detect anomalies and errors.
4. Further Development: After this preliminary work, the implementation of additional functionalities became possible again.

A crucial success factor was communication. By keeping all stakeholders consistently informed and involved, confidence in the stable operation and future viability of the application was restored.

Technologies

• Camunda
• BPMN
• Spring Boot
• Java
• Kubernetes
• Keycloak
• Artifactory
• Jenkins
• Spinnaker
• github
• GitLab