4. Technology and solution design
Technology and solution design form the backbone of effective digital project implementation, enabling scalable, secure, and fit-for-purpose solutions that support policy and service outcomes across the APS.
Successful design requires a clear understanding of user needs, operational environments, and long-term sustainability, spanning from selecting the right tools or platforms to integrating them in ways that are adaptable, interoperable, and resilient to change, ensuring technology serves as an enabler, not a constraint.
The SRO plays a critical role in ensuring design decisions are aligned with project objectives, user needs, and long-term operational viability, whilst championing early engagement with technical experts, integrating solution design into governance structures, and promoting a whole-of-government approach to interoperability and reuse. By embedding technology considerations into early planning, SROs can help ensure systems are not only technically sound but also scalable, secure, and responsive to evolving delivery contexts. SROs should encourage iterative design, testing, and feedback to adapt to evolving needs.
For delivery teams, effective system design requires collaboration across disciplines, clear articulation of functional and non-functional requirements, and a shared understanding of how technology supports service outcomes. Challenges often arise when design decisions are made in silos, or when technical constraints are not adequately considered during planning. Poorly integrated systems, unclear ownership of technical components, or late-stage design changes can introduce complexity, delay delivery, and increase risk. In large-scale or multi-agency projects, these issues are amplified, particularly when solution design is treated as a technical afterthought rather than a strategic enabler of public value.
Key lessons
Technology suitability
Early assessment of technology and platform needs was essential to confirm they were fit for purpose and value for money. Re-use of existing platforms that could meet business needs without excessive customisation helped reduce cost, complexity and long-term maintenance.
Real life learning
The project included regionally dispersed user groups working across various environments and situations, requiring the solution to meet a wide range of user needs. This required a clear understanding of how users worked day-to-day and what would improve efficiency.
A robust user research approach was conducted across multiple project phases to understand user behaviours, needs and constraints. This research supported stronger stakeholder relationships and helped surface key user requirements through productive user reference groups, building the project’s reputation for understanding and listening to stakeholder needs. Insights from these groups shaped proof of concepts, designs and MVPs, helping ensure the solution met diverse user needs, was fit-for-purpose, and supported the intended benefits.
“As far as scope and requirements management and that sort of approach, I’ve re-fallen in love so much with the concept of MoSCoW [prioritisation method] and so much of the value of that would assist SROs. There is tremendous power in calling out explicitly the ‘won't’, never underestimate the power of that.”
Related actionable insights:
1 - Create a technology roadmap | 2 - Choose fit-for-purpose solutions | 5 - Involve business users in testing
Technology foundations
Technology environments, infrastructure audits and hardware readiness need to be in place before build starts. Allowing time in the schedule to fix issues early helped reduce operational risks and avoid workarounds for users
Related actionable insights:
1 - Create a technology roadmap | 2 - Choose fit-for-purpose solutions | 4 - Prioritise testing
Design oversight
Maintaining consistent architectural oversight throughout the project lifecycle was important. It helped manage complexity, reduce rework from design changes and keep the solution aligned with approved patterns.
Real life learning
The project, which involved uplifting an online application to a cloud-based solution, experienced ongoing changes to the detailed solution design during delivery, with iterations occurring after development had commenced.
These changes led to technical redesigns, development rework, and impacts to schedule and cost. The issues were the result of a lack of clear, consistently applied architectural principles and approved patterns, and the absence of structured architectural review points as the design evolved.
Having a dedicated architect throughout the project lifecycle would have ensured the approved solution design was adhered to and architectural changes were processed through appropriate review channels.
“How does this [the IT investment] align to your chief architect’s technical roadmap? If you’re in these bigger projects that are taking years to deliver, how is that application going to fit into the target environment when you get there in years?”
Related actionable insights:
3 - Embed continuous improvement | 4 - Prioritise testing
Business continuity
Building business continuity in system design and costings was essential. This included options such as redundancy and failover. These measures helped services recover quickly, minimise customer impacts and support operational resilience.
Related actionable insights:
1 - Create a technology roadmap | 2 - Choose fit-for-purpose solutions | 3 - Embed continuous improvement
Actionable insights
Have a clear whole-of-product technology roadmap.
Set a long-term roadmap that aligns with product strategy and delivery milestones. If the build will run for several years, plan for technology advancements and new product offerings. This supports scalable design, more consistent advice to government and simpler system architecture. Poor dependency management can lead to outages, disconnected services and failed integrations.“Having an architecture roadmap lined up with an investment roadmap is really helpful, ideally you should be continuing to work through the investments year-after-year.”
Practitioner perspective
Plan strategically when selecting or designing fit for purpose solutions.
Do not assume an available or popular solution is the right one. Test whether the technology fits business needs, long-term value and the operating context. Beware of unproven trends or individual preferences. Make sure technology decisions are grounded in business requirements and architectural alignment.“What is fit-for-purpose? Just because you can do it, doesn’t mean you should do it.”
- Build active monitoring and continuous improvement into solution design.
Include system checks and independent verification in the schedule to confirm the solution will be used as intended and staff capability is developing to use and/or support it. Review system performance regularly to identify risks and gaps and use interim workarounds where needed to minimise disruption to users. Treat testing as a value driver, not a cost burden.
Testing is often seen as expensive but skipping it or reducing it creates technical delivery and user acceptance risks. Position testing as essential to delivery assurance, not just another progress or payment milestone.“Testing, like security, is often seen as an expensive activity that doesn’t really produce value, but it couldn’t be further from the truth.”
“Tailoring testing effort to solution complexity is a great point but it’s very complicated and expensive. Look around to see whose got dummy data – it’s a bit like costumes on a movie set, when they finish making a movie, it goes in the warehouse somewhere for when someone else makes an equally appalling remake of a film, they can go and get it.”
Involve business users early in ICT testing.
Business engagement and participation in workshops and walk-throughs before user acceptance testing (UAT) helps identify issues early and improves business confidence that the solution will meet real operational needs.“If you don’t understand truly the context, and again the deviation of the test environment and test conditions that you apply, then you can’t give that kind of assurance. One of the major things that I come back to is accountability – people need to be accountable for this.”