Software Architecture & Solution Design
We turn business requirements into a sound technical structure. Architecture decisions take into account not just the launch, but also operations, security, integration and the change a system can expect.
Software Architecture & Solution Design at a glance.
The key points for your decision: when it fits, how we approach it and what we pay attention to.
- A dedicated architecture phase pays off when
- multiple systems, sensitive data, high availability or a long lifespan are involved.
- A leaner approach is enough when
- a manageable system is built by one team, with few interfaces and low operational risk.
- Typical trigger
- a new system within an existing landscape, an established system reaching its limits, or an open build-or-buy question.
- Preferred starting point
- a modular monolith with clear boundaries; distribution only where a concrete requirement calls for it.
- Typical risks
- Architecture by trend, distribution without reason, operations as an afterthought and undocumented decisions.
- What we optimize for
- Changeability, transparent operations, clear responsibilities and decisions that remain reversible.
- What we deliberately avoid
- Architecture for its own sake, diagrams without decisions and choosing technology before the requirements.
- What you have at the end
- a target architecture with assessed options, documented decisions and a step-by-step plan.
What it is — and what it includes.
Software architecture is the set of decisions about a system’s structure that are expensive to change later: where its boundaries lie, how components work together, how data flows and how it is operated. Solution design translates business requirements into that structure. Batunet makes these decisions on a sound basis, makes options and trade-offs visible and documents why a particular path was chosen.
Scope of services
- System boundaries, context and responsibilities
- Domains and core business rules
- Components, interfaces and integrations
- Data models and data flows
- Security and authorization concepts
- Scalability, availability, operations and deployment
- Build-versus-buy decisions
- Architecture options and their trade-offs
- Technical debt and modernization paths
- Documented decisions (ADRs)
When it fits — and when it doesn’t.
We recommend the path that fits the project — even when that is an off-the-shelf product.
Good fit
- A new system has to fit into an existing landscape of applications, data and interfaces.
- Security, data protection, availability or traceability are hard requirements, not nice-to-haves.
- An established system is reaching its limits, and it is open whether it should be modernized, extended or replaced.
- Several solution paths are conceivable, and the decision should be made on a sound, traceable basis.
Not a fit
- A small system with one team, few interfaces and low operational risk. There, the architecture rightly emerges as part of implementation, not in a separate phase.
- A prototype meant to test an assumption and then be discarded. Architecture work done in advance would be wasted there.
- The requirements are still largely open. Then a requirements analysis makes sense first — architecture on an unclear basis locks in assumptions.
Decisions before code is written.
Not what the technology can do, but why we use it the way we do.
Boundaries along business lines
We cut systems and modules along business responsibilities, not along technical layers. A boundary is good where rules, data and reasons for change differ — that keeps changes local.
Start simple, justify distribution
For most projects, a modular monolith is the sound starting point. We introduce separate services where differing load, availability or teams concretely require it — not because it is considered modern.
Operations are part of the design
How a system is rolled out, monitored, backed up and restored is decided in the design. That is why operational and security requirements sit alongside the business requirements, not behind them.
Decisions get written down
We record key decisions as Architecture Decision Records: context, options, choice and consequences. That keeps it clear why the system is the way it is — including for those who work on it later.
Risks we catch early.
What typically goes wrong in systems like this — and how we prevent it before it shows up in production.
Architecture by trend
- Why
- Patterns and platforms are chosen because they are popular or new, not because the requirements call for them. The costs only show up in operations and ongoing development.
- Early warning signs
- The rationale for a technology cites trends rather than requirements; nobody can say which problem a building block solves.
- How we prevent it
- Every key decision is justified against the requirements and compared with at least one alternative; mature technology takes precedence over new technology.
- Trade-off
- Cost: less room for the new. Different when: a new technology demonstrably solves a concrete problem better — then deliberately and documented.
Distributed monolith
- Why
- A system is split into many services early, before the business boundaries are stable. The services remain dependent on each other — with network and operational overhead added on top.
- Early warning signs
- Changes require coordinated deployments of several services; the failure of one service takes others down; data is passed back and forth synchronously between services.
- How we prevent it
- Boundaries are first tested within a single codebase. A service is extracted when load, availability or team structure concretely require it.
- Trade-off
- Cost: no independent scaling of individual parts at the start. Different when: parts demonstrably have very different load or availability requirements.
Operations as an afterthought
- Why
- The architecture is designed for the feature set. Deployment, monitoring, backup and recovery are only added shortly before launch — and are then expensive to retrofit.
- Early warning signs
- No agreed recovery time; deployments are manual; when something goes wrong, there are no logs or metrics to find the cause.
- How we prevent it
- Operational requirements are gathered together with the business requirements and addressed in the architecture — including a tested recovery path.
- Trade-off
- Cost: effort before the first visible benefit. Different when: a short-lived prototype is being built — then minimal, but a conscious decision.
Decisions without memory
- Why
- Architecture decisions are made in conversations and recorded nowhere. Later, nobody knows why something was built the way it was — or whether the reason still applies.
- Early warning signs
- Questions about the why are answered with names; changes are avoided out of uncertainty or made without knowing the original reasons.
- How we prevent it
- Key decisions are documented as short ADRs with context, options and consequences, and explicitly superseded when needed.
- Trade-off
- Cost: writing discipline for every key decision. Different when: a decision is easily reversible — then a short note is enough.
Questions we settle before implementation.
Your answers shape the architecture more than the choice of tools does.
Which requirements shape the architecture most?
- Why it matters
- Not every requirement is architecturally relevant. A few — data protection, availability, integrations, expected change — determine the structure.
- Typical consequence
- We name these drivers explicitly and justify every key decision with them, not with preferences.
Where do the system’s business boundaries lie?
- Why it matters
- Boundaries along business lines keep changes local. Boundaries along technical layers spread every business change across the entire system.
- Typical consequence
- We cut modules — and services where necessary — along these boundaries and define which system is the source of truth for which data.
Which decisions are expensive to reverse?
- Why it matters
- Data model, interface contracts and platform choice can only be changed later at great effort. Much else is cheap to correct.
- Typical consequence
- We make the expensive decisions carefully and document them; we deliberately keep the cheap ones open until more is known.
What does the system have to withstand — and what is allowed to fail?
- Why it matters
- Expected load, required availability and tolerable downtime significantly determine the effort and cost of operations.
- Typical consequence
- We define these values together and design no more redundancy than the business actually needs — but no less either.
What do we build ourselves, and what do we buy or use?
- Why it matters
- Custom development pays off where it differentiates. For standard problems, mature products and services are usually cheaper and safer.
- Typical consequence
- We decide per component and record which dependency this creates and what a later switch would look like.
How does the system get from where it is today to the target architecture?
- Why it matters
- A target picture without a path to it remains a diagram. With existing systems, the transition is often harder than the target itself.
- Typical consequence
- We plan step-by-step transitions in which each step can be operated on its own and remains reversible.
From design to operations.
The system doesn’t just have to run — it has to hold up in operation. Every recommendation comes with its cost, and with the case where we decide differently.
System context and components
We describe which systems, users and partners are involved, where the system begins and ends, and which component carries which responsibility.
Trade-off · Cost: agreeing on responsibilities that were previously unspoken. Different when: a standalone system without surrounding systems is being built — then a brief overview is enough.
Data and integrations
We design the data model, data flows and interfaces together: which system is the source of truth for which data, and what happens when an integration fails or delivers twice?
Trade-off · Cost: translation layers and clear contracts instead of direct coupling. Different when: two components are developed and deployed together — then tighter coupling is acceptable.
Security and permissions
Roles, permissions, data and tenant separation, and the handling of secrets are part of the architecture, not a later add-on. The basis is a clear picture of what needs to be protected and from what.
Trade-off · Cost: less freedom for later shortcuts. Different when: an internal tool without sensitive data is being built — then the concept stays lean, but not empty.
Scaling, availability, operations
We ask about the load that is actually expected, the tolerable downtime and the operating model — and derive deployment, observability, backup and recovery from that.
Trade-off · Cost: redundancy and observability that remain invisible in normal operation. Different when: short outages are acceptable — then simpler operations instead of high availability.
Build versus buy
Not every component has to be built. We assess standard products, services and custom development by differentiation, lifespan, dependency and total cost.
Trade-off · Cost: purchased components create a dependency on the vendor. Different when: the process is at the core of the business — then the case for custom development is stronger.
Maintainability and modernization
For existing systems, we name technical debt by its impact and plan a step-by-step path that does not put operations at risk. For new systems, we keep the places where change is most likely easy to change.
Trade-off · Cost: not every piece of debt is paid off immediately. Different when: a piece of debt actively endangers security or operations — then it takes priority.
From the first conversation to a running system.
Every project follows the same four steps. You see and review interim results along the way, not only at the end.
- 01
Understand the goals and requirements
The first conversation, held with our management, covers your project, your processes and the systems already in place. We then write down goals and requirements and tell you openly whether custom development makes sense.
- 02
Plan the solution and architecture
We propose a technical solution, define the scope and the order of implementation, and document the key decisions together with their reasoning.
- 03
Build and review together
We develop in stages, with tests and code reviews. We present interim results regularly so you can review them early and adjust priorities.
- 04
Launch and keep supporting
After launch we take on maintenance, updates, monitoring and further development to the agreed extent. The project-specific source code and the documentation are handed over to you.
What you have in hand at the end.
A target architecture grounded in the requirements
A system and context overview with clear responsibilities
An integration concept for interfaces, data and existing systems
Documented architecture decisions, with context and consequences
Assessed solution options with their trade-offs
Identified technical risks with countermeasures
A step-by-step implementation or modernization plan
Architecture artifacts
Questions about Software Architecture & Solution Design
Does every project need its own architecture phase?
No. The depth depends on complexity and risk: for a manageable system, the architecture emerges as part of implementation. With many interfaces, sensitive data or high availability requirements, a dedicated, documented phase pays off.
Monolith or microservices?
We usually start with a modular monolith with clear boundaries. We extract individual services when load, availability or team structure concretely require it. The decision is justified and documented.
Can you assess the architecture of an existing system?
Yes. We start with an assessment of structure, data, interfaces and operations, name risks and technical debt by their impact and derive a step-by-step modernization path from that.
Which architecture artifacts do you produce — and how do you evaluate technologies?
Typically an overview of the system context, the data flows between components and systems, interface contracts and architecture decisions as Architecture Decision Records (ADRs) with context, options and consequences. Depth and scope follow the risk of the project. We evaluate technologies against these requirements, not the other way around: mature, widely used technology takes precedence, and every key choice is justified.
Related topics.
Guides, decisions, services and case studies connected to this page.
Architecture decisions
Let’s talk about your project.
Tell us briefly about your project. Your first conversation is directly with our management.
