Solution Architecture & Technology Selection
How a proposed solution should be put together, which components it needs, how data moves between them, and which technical approach suits the organisation that will live with it — assessed independently of who eventually builds it.
The situation this service is built for
The decision to build has been taken. What remains is the set of choices that will determine how the software behaves for the next several years: how it is structured, where the data sits, what it connects to, where it runs and which technologies are used.
These choices are usually made implicitly — by whichever supplier is engaged, according to whatever they happen to work with. That is not necessarily wrong, but it is not a decision the client has participated in, and it is expensive to revisit later.
This engagement makes those choices explicit before development is commissioned. It is also valuable when quotations from suppliers are difficult to compare, because it establishes a common technical baseline that every supplier can quote against.
No single technology is treated as suitable for every project. The comparison is between the organisation's situation and the realistic options, not between fashions.
Problems this service may address
- Technology chosen by defaultThe stack will be whatever the chosen supplier prefers, with no assessment of whether it suits the organisation long-term.
- Supplier quotations are not comparableEach supplier has assumed a different structure, so the figures describe different projects.
- Unclear system boundariesNobody has established which system is responsible for what, so overlapping responsibilities will emerge during the build.
- Hosting is an afterthoughtWhere the software will run, who owns the account and what it costs to operate are unresolved.
- Integration assumed rather than verifiedThe plan depends on systems exchanging data, but nobody has checked whether the interfaces support it.
- Scalability discussed without figuresGrowth is expected, but nobody has stated what volume the design must actually accommodate.
- Lock-in risk unexaminedThe proposed approach may make it difficult to change supplier later, and that has not been made visible.
Possible deliverables
Deliverable components
- Architecture outline
- System component map
- Integration considerations
- Hosting considerations
- Data-flow model
- Technology-option comparison
- Scalability considerations
- Implementation recommendations
Typically included in scope
- Requirement reviewReading the functional requirement closely enough to identify what it implies technically.
- Constraint gatheringExisting systems, internal skills, budget shape, security expectations and any organisational standards.
- Component and boundary definitionWhat each part is responsible for, and where responsibility stops.
- Option comparison against criteriaRealistic technical routes assessed on fit, cost over time, maintainability and reversibility.
- Written recommendation with reasoningA position taken and defended, not a list of possibilities left for the client to resolve.
- Walkthrough sessionA discussion covering the design, the trade-offs accepted and the decisions deliberately deferred.
What is not automatically included
- Detailed technical specification for developmentThe architecture describes structure and approach. Screen-level specification belongs to the build engagement.
- Proof-of-concept codeWhere an assumption genuinely needs testing in code, that is scoped and priced as separate work.
- Procurement of hosting or licencesRecommendations are given; purchasing, account ownership and contract terms remain with the client.
- Security certification or auditSecurity considerations are addressed in the design; formal assessment is a separate specialist engagement.
- Supplier selection or negotiationTechnical criteria for comparing suppliers can be provided; commercial negotiation is not part of this service.
- Any guarantee of performanceScalability considerations are informed judgements based on stated volumes, not a warranty of behaviour under load.
Engagement process
Requirement and constraint review
Reading the requirement alongside the practical constraints: existing systems, internal capability, budget shape and any standards already in force.
Criteria agreement and proposal
The criteria for comparing options are agreed before options are developed, so the assessment cannot be quietly steered by the analysis. The proposal follows with deliverables, timescale and price.
Component and data-flow design
The parts of the solution, their responsibilities, the boundaries between them and the way data moves — including where it is created, where it is authoritative and where it is only displayed.
Technology comparison
Realistic options assessed against the agreed criteria, with attention to who can maintain each one and how difficult it would be to change direction later.
Draft review
The draft is shared with the client and, where appropriate, with an internal technical team, so factual corrections and local knowledge are incorporated.
Final pack and walkthrough
The architecture pack is delivered with a session covering the reasoning, the accepted trade-offs and the questions to put to any supplier quoting against it.
Expected deliverables
- Architecture documentStructure, components, responsibilities and boundaries, described for a technical and a non-technical reader.
- Component mapA diagram showing the parts of the solution and their relationships.
- Data-flow modelWhere data originates, where it is authoritative, how it moves and where it is stored.
- Technology comparison tableOptions against criteria, with the reasoning behind each assessment rather than scores alone.
- Hosting and operational notesWhere the software could run, indicative running costs and the implications for account ownership.
- Implementation recommendationsA recommended approach, the order of work, and the decisions safe to defer until later.
Client responsibilities
- A reasonably settled functional requirement — architecture cannot be designed for an undefined product
- Honest information about internal technical capability and who will maintain the result
- Details of existing systems, including versions, hosting and any support arrangements
- Realistic volume expectations: users, records and transactions, stated as figures rather than adjectives
- Any organisational standards, security requirements or supplier constraints that apply
- Prompt review of the draft, involving internal technical staff where they exist
Factors that affect scope and price
Increase scope
- Several existing systems that must be accommodated
- Strict security, residency or retention requirements
- Many integration points requiring individual assessment
- An architecture spanning several teams or business units
- Detailed cost modelling across multiple hosting options
- Formal documentation for an external funder or auditor
Keep scope lean
- A single new solution with few existing dependencies
- A settled functional requirement already written down
- Two or three realistic options rather than an open survey
- One technical contact who can answer questions about current systems
Pricing notice. All prices are indicative starting points. Final pricing depends on project scope, complexity, integrations, documentation, timescale and agreed deliverables. Applicable taxes and third-party costs are confirmed in the written proposal where relevant.
Follow-up options
Tender support
The architecture pack becomes the technical baseline suppliers quote against, which usually makes their responses genuinely comparable.
Development engagement
Where DEVNOVA is asked to build, the architecture becomes the basis of the development proposal without repeating the analysis.
Design review during build
Periodic checks that what is being built still matches the agreed architecture, arranged as a separate advisory engagement.
Questions about this service
Yes — a position is taken and defended, because a report that lists options without recommending one has simply returned the problem to the client.
The recommendation is specific to the organisation's situation, not a universal preference. The same requirement in a company with an internal development team and in a company with none will frequently produce different recommendations.
Often, yes. An independent architecture review gives the client a basis for asking informed questions and for understanding the implications of what is proposed.
The role is advisory to the client rather than supervisory over the supplier, and the arrangement works best when the supplier knows it exists. Competent suppliers generally welcome a client who understands the trade-offs.
Enough that a competent developer could begin without guessing at structure, and enough that a non-technical decision-maker understands what is being committed to.
It stops short of screen-level specification and detailed data schemas, which belong to the build engagement where they can respond to what is learned during development.
The design accommodates plausible growth without paying for capacity that may never be needed. Over-engineering for hypothetical scale is one of the most common ways a budget is wasted.
Where volumes are genuinely unknown, the architecture identifies which decisions would be expensive to reverse and which can safely be revisited later — so the organisation knows where to be careful and where not to worry.
No — they answer different questions. Digital Roadmap & Feasibility Consulting asks whether something should be done and in what order. This service asks how it should be built.
Where the decision to build is already settled, starting here is entirely reasonable. Where it is not, feasibility first is usually the cheaper sequence.
Continue
Services that often accompany this one
Service enquiry
Send the requirement. The structure follows.
Share what the solution must do, what systems already exist and who will maintain the result. That is the material this engagement works from.
- Telephone
- +44 7853 151 992
- support@devnovasolutions.tech
- Registered office
- 66 Paul Street, London, England, EC2A 4NA, United Kingdom