Software Architecture Fundamental Principles – System Integration & Legacy Systems

This article is a glossary entry on software architecture fundamental principles – including exam questions and tags.

In a Nutshell

Software architecture means structuring applications so that they remain maintainable, extensible, and adaptable to existing IT landscapes – especially when integrating legacy systems and switching environments.

Compact Technical Description

Software architecture defines the basic structure of a system: components, their relationships, and the technologies used. In operational practice, “greenfield” development is rarely the case – existing systems must be taken into account or extended much more frequently. Integrating legacy systems poses special requirements for interfaces, data formats, and protocols. Modern architectures often need to interact with monolithic or poorly maintainable applications. When switching environments (e.g., from on-premise to cloud), portability is central. Technical debt, modular decomposition, layered models, and clear interface definitions are key aspects.

Exam-Relevant Key Points

• Architecture defines structure, communication, dependencies
• Considering legacy systems = mandatory in extension projects
• Interface capability = central design requirement
• Refactoring instead of redevelopment for stable legacy systems (IHK-relevant)
• Practice: frequent integration via REST, middleware, adapter pattern
• Security aspects: data formats, API security, access to legacy databases
• Cost-effectiveness: reuse vs. new development
• Documentation with diagrams, interface specifications, and migration strategy

Core Components

1. Analysis of existing system architecture
2. Identification of technical debt
3. Alignment of requirements with current system
4. Interface concept
5. Selection of integration strategies (wrapper, proxy, adapter)
6. Definition of target environment (operating system, cloud)
7. Migration strategy (big bang vs. incremental)
8. Refactoring of legacy components
9. Test concepts for compatibility
10. Documentation of architecture decisions

Practical Example

// Extension of inventory management with REST API for web frontend
1. Legacy system (monolithic, local database access only)
2. Goal: modern web UI → REST API as middleware
3. Adapter between legacy data structure and JSON response
4. API documented with OpenAPI/Swagger
5. Reuse of existing logic, no duplication

Explanation: The existing logic remains intact, new clients communicate via REST with an intermediary API layer.

Advantages and Disadvantages

Advantages

• Using existing systems saves time and costs
• Integration extends the lifespan of legacy systems
• Architecture awareness reduces later migration costs

Disadvantages

• Old systems are often poorly documented
• Interfaces difficult to implement retroactively
• Environment switches can create security risks

Typical Exam Questions (with Short Answer)

1. “Consideration of existing systems”? New solution must be compatible with existing IT landscape.
2. What is a legacy system? Old system that continues to be used, often without current support or documentation.
3. Connect legacy systems? Via interfaces, adapters, wrappers, or data replication.
4. What is middleware? Software acting as intermediary between legacy and new systems.
5. Risks when switching environments? Incompatibility, data loss, security gaps.
6. Document architecture decisions? With component, layer, interface diagrams and textual justification.
7. Refactoring vs. reimplementation? Refactoring makes sense with stable core logic requiring modernization.
8. “Loose coupling” in context? Components are independent, changes are localized.

Most Important Sources

1. https://arc42.org/
2. https://www.heise.de/thema/Legacy-Systeme
3. https://refactoring.guru/de
4. https://martinfowler.com/eaaCatalog/
5. https://c4model.com/