Customer snapshot
Durr (Durr Group) is a German mechanical and plant engineering firm that focuses on automation, digitalization and energy efficiency. Durr has over 18,000 employees across 32 countries generating 4.7 billion Euros in 2024.
An international integration team (5 internal developers across Germany and India) running integrations on SAP Integration Suite wanted a more reliable, governed way to move changes from DEV → QA → PROD without manual without “surprises” in production.
How did we talk with Patrick Haug SAP Integration manager about why he enjoys Figaf.
Key Quote(s)
With Figaf our team could easily transport and configure integration. We could even reuse Dev system as Test with the same process. Allowing us to save costs.
- Patrick Haug, Integration Manager
We could setup Figaf based on the public documentations without extra help.
The challenge
- Manual or weak transport handling increases risk (errors, missing configurations or, inconsistent workflows).
- Reuse Dev tenant for testing with out impacting governance.
- Production access needed to be restricted so changes only go live through an approved, repeatable process (stronger separation of duties and audit readiness).
- Developers needed faster troubleshooting (trace/development experience for scripts.
- SAP native options were not enough. Durr had explored other options for transport but it required too much extra work to ensure cloud transport options as less mature than classic on-premise and wanted more control and a clearer workflow for Integration Suite changes.
The solution (capabilities used)
The team adopted Figaf DevOps Suite to implement a standardized tool for Integration Suite change delivery and governance, including:
- Transport management to automate promotion of integration content across environments where a key component is automated configuration.
- Virtual tenant concept to create a practical DEV/QA setup using fewer tenants (they described effectively running three “environments,” with QA implemented as a virtual tenant).
- Git backup integration to keep iFlows and other artifact backed up to their in a git repository daily.
- Developer productivity tooling: Groovy editor enabled faster development of groovy scripts with easy access to run on Durrs integration suite.
- Testing: started using Figaf’s testing capabilities more to validate changes and improve quality after modifications.
Business case
The business case for using Figaf was enough just to support the transport use case. The virtual tenant and the limited requirement for manual work. The time saved on this was sufficient to justify Figaf.
Then all the extra features were just nice bonuses for the integration team, like the requirement for auditors to investigate what is going on.
Implementation approach
- Self-onboarded: the customer team set up the solution largely by following documentation (with Figaf support available for questions).
- Locked down production: day-to-day developers no longer access the productive tenant for changes; deployments are performed via Figaf (admins retain emergency access). Monitoring stayed consistent: they kept monitoring in their existing central tool (Cloud ALM) for consistency across products.
Outcomes
- Reduced operational risk by removing manual transport steps and enforcing a consistent deployment workflow
- Reduced cost for building and maintaining integration.
- Structure by restricting production access and ensuring deployments go through a controlled mechanism.
- Faster troubleshooting with easier context for iFlows
- Improved developer experience using a better Groovy editing
- Better resilience through routine backups of integration artifacts to Git.
What’s next (planned/considered)
Not everything as been a part of the current scope. There are new features Durr would be implementing later as a part of this journey to improve SAP Integration.
- Approvals for audit trail: not currently used, but seen as a likely future step as governance requirements mature.
- Expand automated testing few tests cases as currently been made but more is expected to be created.