Camunda > Case Studies > Deutsche Telekom's Agile Transformation with Microservices-Based Architecture

Deutsche Telekom's Agile Transformation with Microservices-Based Architecture

Company Size

1,000+

Region

Europe

Country

Germany

Product

Camunda BPM
Oracle BPEL engine

Tech Stack

Java
SPRING
Kubernetes
Microservices
Cloud

Implementation Scale

Enterprise-wide Deployment

Impact Metrics

Cost Savings
Productivity Improvements

Technology Category

Application Infrastructure & Middleware - API Integration & Management
Platform as a Service (PaaS) - Connectivity Platforms

Applicable Industries

Telecommunications

Applicable Functions

Business Operation
Discrete Manufacturing

Use Cases

Predictive Maintenance
Process Control & Optimization
Real-Time Location System (RTLS)

Services

Cloud Planning, Design & Implementation Services
Software Design & Engineering Services

About The Customer

Deutsche Telekom IT GmbH is the internal IT service provider of Deutsche Telekom AG. With around 9,700 employees globally and a total budget of around €1.9 billion, it’s responsible for the design, development and operation of all its own and transferred IT systems to support business processes at Deutsche Telekom and its subsidiaries. In 2007, Deutsche Telekom IT began using an Oracle BPEL engine to build and run BPM workflows and process automation. However, this monolithic system created a number of issues that affected both the business and user experience. In 2017, running a 10-year-old monolithic system, Deutsche Telekom IT took the first steps towards modernising its processes by adopting a ‘partially agile’ development approach, working in three-month sprints.

The Challenge

Deutsche Telekom IT, the internal IT service provider of Deutsche Telekom AG, was facing several issues with its monolithic Oracle BPEL engine that was used to build and run BPM workflows and process automation. The monolithic system resulted in a lengthy time-to-market, lasting more than 12 months. Vendor lock-in limited the implementation of new features and it took five days to set up or make changes to environments. Releases took, on average, 1000 people-days or roughly three months to realize, and regression testing took around two days to process all test cases. In 2017, Deutsche Telekom IT adopted a ‘partially agile’ development approach, working in three-month sprints. However, all fixes had to be delivered together with larger change requests, which took considerable people-hours to accomplish. In addition, they were still struggling with the monolithic BPEL system, which didn’t allow for true agility.

The Solution

In 2017, Deutsche Telekom began investing in fiber optic cables to deliver a better user experience. With this significant upgrade in hardware came the opportunity to revolutionize Deutsche Telekom IT’s outdated systems. This saw a complete change in both the operating system and DevOps approach, guided by three goals: Speed up, Cross-functional teams, and Efficiency. With these three goals in mind, Deutsche Telekom IT implemented a microservices-based architecture, in the cloud, with Camunda BPM engines running in many microservices. The new system is comprised of Microservices, Cloud, SAFe agile framework, and DevOps philosophy. One of the greatest advantages of Deutsche Telekom IT’s Camunda revolution has been enabling ‘compliance-bydefault’. As a globally distributed business, with teams working across the world with multiple vendors and sensitive data, this highly automated solution was required. The result is an architecture that enables compliance-by-default and ensures data security.

Operational Impact

Visualize complex logic in one place
Easily align human and automated tasks
Use the same language for business and development, along with native Java support
Visualize real-time operations with Camunda Cockpit, seeing at-a-glance the progress of any process
Enable compliance-by-default across global distributed teams, multiple vendors and sensitive data

Quantitative Benefit

Reduced time-to-market from more than 12 months to significantly less
Reduced the time to set up or make changes to environments from five days to significantly less
Reduced the time for releases from 1000 people-days or roughly three months to significantly less
Reduced the time for regression testing from around two days to significantly less