Discovery over technology drives effective software solutions
The effectiveness of software development projects is increasingly determined by solution design rather than the choice of technology, according to Notitia, an Australian data strategy and digital transformation firm. The company highlights that focusing on uncovering the root causes of business challenges is essential to ensuring that technology solutions deliver the intended results.
Addressing the gap
Alex Avery, Managing Director and Founder of Notitia, refers to the common disconnect between business objectives and technical implementation as the "missing middle." He states that projects often fail not due to tool malfunctions, but because the underlying problem was not properly identified at the outset.
"When done well, solution design bridges the gap between intent and impact. It helps clients see the whole picture, define what success looks like, and avoid the expensive mistake of solving the wrong problem," said Avery.
Discovery before technology
Many project teams, according to Avery, are drawn directly to specific tools or technologies under the impression that immediate progress is being made. However, he emphasises the risk of bypassing critical preliminary steps that reveal why an issue exists in the first place.
"Starting with a tool or technology feels productive - and it's exciting for people to dream of the possibilities that the technology holds. But it skips the discovery step that reveals why a problem exists in the first place. Once we start asking questions, 'what's the state of your data?' 'Where does it live?' 'Who owns it?' 'What do these metrics actually mean?' We often find that the real problem is that the data itself isn't ready, understood, or valuable yet," said Avery.
Solution design process
Brett Earle, Lead Web Developer at Notitia, likens the process of solution design to an archaeological dig. He points out that this approach is about revealing the reality beneath surface-level symptoms, shaping projects to address core issues rather than superficial fixes.
"Solution design is like an archaeological dig. You're uncovering what's really going on beneath the surface, not just fixing the first thing you find. Jumping straight into build mode means you end up solving for the symptom, not the cause," said Earle.
He further notes that taking a disciplined approach, which includes deliberate pauses to analyse the underlying situation, sets a more reliable foundation for the development that follows.
"Good solution design slows things down just enough to understand why the problem exists. It provides the right foundation before you start layering on technology," said Earle.
According to Avery, this approach can significantly improve project outcomes. "Taking the time to analyse, before building, leads to stronger architecture, better code reuse, and fewer reworks down the line. It's how you deliver something that lasts," said Avery.
People, process, technology
Avery outlines that every business challenge consists of three main aspects: people, process, and technology. He suggests that technology is not always the answer-sometimes, organisational structure and communication need to be addressed first.
"You've got to understand the business: its culture, in-house skills, goals, and pain points, before you can decide if technology is even the answer. Sometimes, the fix doesn't involve new software at all. It could be a process tweak or a shift in communication, roles or responsibilities. New technology isn't the solution to every problem, and starting there often adds cost and complexity," said Avery.
He adds that having a clear understanding of context helps organisations select the appropriate tools and simplifies the design process.
"You stop playing know-it-all and start playing solve-it-right," said Avery.
Real-world implications
Earle provides an example where considering operational context was critical in defining a project's direction. A client with remote sites and unreliable internet connectivity, combined with tight delivery timelines, required rethinking available options and led to a solution distinct from what was initially imagined.
"We were working with a client who had remote sites where internet access was unreliable. That instantly ruled out a few off-the-shelf tools that depend on constant connectivity. The client also had tight delivery timelines, removing the option of a fully custom build," said Earle.
Avery points out that such insights are only possible through direct conversations with stakeholders on the ground. "It was taking the time to stop, have important investigative conversations with the people on the ground, that meant we created the right solution for the organisation," said Avery.
Importance of conversation
For Avery, honest discussion remains the cornerstone of effective software projects. He argues that unearthing the true issues often depends on open dialogue rather than advanced coding or elaborate systems.
"Conversations, without getting bogged down in technical jargon, spark new insights and, sometimes, clients realise the problem they thought they had isn't the real issue. That's a win. It means we can help them to describe and map their goals. Once that happens, the right solutions start to appear, we get to the root problem and uncover that missing middle," said Avery.