1. Build parallel landscape instead of renewing existing landscape
At the beginning, there is always the fundamental question of whether the existing landscape should be renewed piece by piece from the inside out, or whether it is better to set up a completely new system from scratch (“greenfield approach”). In most cases, from our experience, it is recommended to clearly build a new landscape from scratch here:
- The new landscape can be built initially as simple as possible, but flexible.
- The new landscape does not need to be integrated into the complex existing structures. The complexity of the existing system is often underestimated and the replacement of individual parts that need to be integrated into the existing, opaque system is very often over 3 times more expensive and lengthy to implement than a consistent new build.
- New construction does not have to take into account the old structures. A comparison to building a house: a renovation is often more expensive than a new construction, because you can never be sure what is hiding behind the next wall.
2. start with as few systems as possible and expand according to needs
A distributed software landscape with several systems involved is always more complex to set up, operate and expand than a purely monolithic landscape – but it is also essential in order to achieve a high degree of flexibility. The recommendation is therefore to build a landscape with as few distributed systems as possible. For the start, the complexity of the distributed system is thus quite low and manageable, but the architecture is designed for flexibility and expansion in the future. This landscape should then be continuously expanded according to the greatest potentials and further systems should be docked in a modular way.
3. build a stable foundation instead of imprinting all functions at the same time.
Before getting lost in the details of requirements catalogs with many desired functionalities, the focus should be on laying the right foundation. When building a house, the basement must first be in place before continuing to build in height, and the parquet should not be laid parallel to the plastering of the walls. The architecture and structure of a system is similar. If too many things are attempted to be expressed in complete depth at the same time, a fragile structure is constructed, which must be repeatedly touched up or, in the worst case, leads to a non-scalable solution.
4. setting up a flexible and dynamic data model as the key to success
The data model must be flexible, as there is no certainty as to what further information will need to be added in the future, e.g. by connecting another system. Classic, rigid database structures with inflexible business objects will quickly push the platform to its limits and stand in the way of scaling as customizations become increasingly complex and costly. A dynamically expandable and adaptive data structure is what makes a modern and scalable architecture possible in the first place.
5. enable event-based communication
Another important success factor is event-based communication between the systems. It is imperative to avoid implementing rigid processes that run across multiple systems. Instead, event-based communication between systems should be used whenever possible. For example, system A can communicate its events to the surrounding systems and based on the events it can be decided which further processes should be triggered in another system.
If you would like to find out whether these approaches are also the right way forward for your company, you can talk to our experts without obligation.