PRACTICE 02 — SOLUTIONS ARCHITECTURE
Technical decisions that hold up as you grow.
A system's most expensive decisions are made at the start, when they still look cheap: the stack, the data model, how modules talk to each other, where it runs. Solutions architecture means making those decisions with someone who has seen their consequences across dozens of systems — and documenting them so the team can sustain what was decided.
DESIGN
Architecture for new systems
From business requirement to complete technical design, before the first line of code.
- Functional and non-functional requirements: volume, availability, security, integrations, timeline and budget
- Choice of stack, architectural style (modular monolith, services, events) and platform, with the trade-offs of each option
- Data and domain modelling, API contracts and integration design
- Diagrams and an architecture document the development team uses as a guide, not decoration
REVIEW
Reviews of existing architectures
An external, independent view of a system already in production, ahead of a big decision.
- Assessment of scalability, security, cost, technical debt and operational risk
- Analysis of code, infrastructure and delivery process, based on evidence rather than opinion
- A report with findings prioritised by impact and a realistic action plan
- Useful before investment, acquisition, audit or a change of vendor
MODERNIZATION
Modernization plans
A staged path to move a legacy system forward without stopping operations.
- Dependency and module map, with extraction order and success criteria per stage
- A coexistence strategy for old and new during the transition
- Effort and cost estimates per phase, so the business can set the pace
- Execution follow-up, adjusting the plan as the work reveals what was unknown
CLOUD
Cloud architecture
AWS and Azure designed by a certified architect, with cost and operations in mind from the start.
- Choice between managed services, containers and serverless according to load, team and budget
- Networking, identity, security and separate environments designed in from day one
- Monthly cost estimate before any resource is provisioned
- Infrastructure as code, so the architecture that was designed is the one that runs
DATA
Data and integration architecture
How information flows between systems and where it lives, decided before it becomes a problem.
- Transactional and analytical data models with clear boundaries between domains
- Integration patterns: synchronous, event-driven, queues and webhooks — each where it makes sense
- Consistency, idempotency and reprocessing strategy for integrations that fail
- Data governance: who owns what, retention, privacy and audit
AI
Architecture for AI
Where a language model fits in the system, what it is allowed to do and how you measure whether it works.
- Defining AI's role in the architecture: assistant, agent with tools, workflow automation or search
- Design of RAG, agents and MCP servers with security, permissions and audit from the outset
- Evaluation, cost and fallback strategy before the first user touches the system
- Integration with the existing architecture, without creating a parallel system nobody maintains