System Architecture
The chosen system architecture significantly determines the long-term maintainability, scalability, and economic efficiency of a software landscape. A faulty architectural decision in early phases generates Technical Debt, which causes exponential costs in later growth phases.
We promote pragmatic architectures that can grow with the organization — from the well-structured monolith (Modulith) to decentralized Microservices, when complexity justifies it.
Anti-Patterns: The Big Ball of Mud
Many grown IT systems end up as unstructured monoliths in which every change in one place triggers unpredictable side effects in another. These Big Ball of Mud architectures stifle any innovative power, as the team spends more time fixing bugs than developing new features. An ill-considered switch to Microservices without the necessary operational maturity often only leads to a distributed monolith — one that increases complexity without solving the problems.
Evolutionary Design
- Modulith First: Start with a monolithic application that is internally strictly separated into functional modules. This allows simple development while maintaining a clear path for later extraction.
- Microservices When Needed: Decompose the system only when differing scaling requirements, team sizes, or technology requirements make it strictly necessary.
- API-First & Decoupling: Communication between modules or services occurs exclusively via defined interfaces (APIs) to minimize side effects.
- Strangler Fig Pattern: Gradual replacement of outdated legacy systems by building new functionality in new services that successively "strangle" and replace the old system.
- Architectural Decision Records (ADRs): Documentation of all important architectural decisions, including context and trade-offs, to make the history traceable for future teams.
Practice Example: The Strangler Fig Approach
Instead of a risky big bang re-platforming of an old ERP system, invoicing is first moved to a new, modern service. The old system remains in place but gradually loses its responsibilities to the new architecture until it can finally be switched off.
FAQ
Should we not go straight to Microservices to be like Netflix or Amazon?
Only if you also want to manage the same number of engineers and the same operational complexity. For most Swiss companies, a well-structured Modulith is the economically sounder and faster choice.
How do we prevent our new architecture from becoming outdated again in 5 years?
Through evolutionary design. We build systems so they remain replaceable. Modularization matters more than the initial choice of framework.
Reference Guide
- Building Evolutionary Architectures: Neal Ford et al. on systems that can change over time. O'Reilly
- The Strangler Fig Application: Martin Fowler on the pattern for legacy migration. martinfowler.com
- Clean Architecture: Robert C. Martin on the principles of software structuring. Prentice Hall