Software architecture decisions become everyday working conditions for the people who maintain a system.
They affect how releases happen, how problems are investigated, what skills the team needs, and how much it costs to keep the application running. A design that looks good during development can be difficult to live with if those responsibilities do not fit the organization.
Choosing an architecture means considering both what the software must do and who will look after it.
Start with the work the system needs to do
Before choosing frameworks, databases, or hosting, describe the requirements that could change the design.
How many people will use the application, and what happens during busy periods? Which operations must complete immediately? What data needs protection? How long can the business tolerate an outage? Which existing systems must it connect to?
Be specific where you can. “It needs to scale” leaves a lot open to interpretation. Expected usage, response-time targets, and recovery requirements give the team something to design and test against.
Then consider the people responsible for operating it. Their skills, available time, and budget belong in the same conversation.
Four questions worth asking early
Who will operate it after launch?
Identify who will handle deployments, updates, monitoring, and incidents. That might be an internal team, a delivery partner, or a combination.
A technology the team already understands can be a sensible choice, provided it meets the requirements. If a different platform offers a meaningful benefit, include the training, hiring, or outside support needed to use it well.
Managed services can take on some infrastructure responsibilities. The application still needs someone accountable for its configuration, access, performance, and behavior.
What happens when part of it fails?
Walk through a few realistic failures. A payment provider stops responding. An overnight import fails halfway through. A release introduces incorrect calculations.
For each one, ask what users experience, how the team detects the problem, and what recovery involves. Decide where retries are safe, how duplicate work is prevented, and when someone needs to intervene.
These questions help reveal whether a design is manageable before the team has to troubleshoot it under pressure.
What will it cost to keep running?
Compare the ongoing effort as well as the hosting bill. Include licenses, monitoring, backups, support, and the time required to release changes safely.
More components can mean more things to configure, update, and diagnose. Sometimes that additional work buys useful independence or capacity. Make the benefit explicit so the client can judge whether it is worth the cost.
How difficult will future changes be?
Consider likely changes, such as adding an integration, handling more traffic, or replacing a provider.
Using a platform's specialized features can save considerable development effort. It can also make a later move more involved. Review data export options, application dependencies, and likely migration work before committing.
The aim is to understand the tradeoff. Building layers of abstraction around every service can create its own maintenance burden.
A practical example
Consider a hypothetical distributor building an internal order-management application. A small team will support it, usage is reasonably predictable, and most changes affect closely related order and inventory processes.
A single application with clearly separated internal modules could be a good starting point. The team has fewer separately deployed services to coordinate, while the code can still have clear boundaries.
Now suppose document processing begins consuming substantial resources and needs to scale independently. That may justify moving that capability into a separate service, after measuring the problem and considering simpler improvements.
Microservices can support independent deployment and scaling. They also introduce challenges around communication, testing, monitoring, and data consistency, as Microsoft's microservices guidance explains.
The decision should follow the workload and the team's ability to operate it. Neither approach is automatically the right answer.
Write down the reasoning
For significant architecture decisions, a short record can preserve context that would otherwise disappear when people change roles.
An architecture decision record, or ADR, can capture:
- The requirement or problem being addressed.
- The options considered and the reason for the choice.
- The tradeoffs and assumptions.
- The circumstances that would justify revisiting it.
Microsoft's ADR guidance recommends recording consequential decisions and preserving their history when choices change.
Keep these records useful and brief. Someone joining the project should be able to understand why a decision made sense at the time.
Making the choice with Canviz
Canviz can help you work through these choices alongside your team, including the skills, costs, and support arrangements they imply.
You should understand what the proposed architecture makes easier, what it makes harder, and who will be responsible for it after launch. That gives you a stronger basis for choosing a system your team can live with.
