Integration starts before the tool is bought
Integration is forgotten in transformation projects surprisingly often. A new tool gets selected, the budget approved, the go-live scheduled. Only late in the game does someone ask the decisive question: How does this system actually fit into the existing landscape?
At that point an architecture task turns into a pressure situation. Shortly before the planned go-live, data flows have to be clarified, interfaces built, security requirements met and responsibilities negotiated. Under time pressure, interim solutions emerge, and far too often they become permanent.
Those who plan integration last turn architecture into crisis management.
My approach: integration belongs in the decision
That is why I like to be part of the decision process early. Before a product is chosen or a date is promised, we clarify together which processes are affected, which data flows, which systems remain leading, and what operations, security and governance require.
This makes dependencies visible, lets effort and risk be assessed realistically, and turns the necessary integration work into a reliable part of the overall plan. That protects more than the go-live. It creates an architecture that still carries after the project ends.
The best integration team is not the one that reacts fastest right before launch. It is the one that is also at the table early enough.
Robert FelsHamburg · 2026