Reference Technology Solutions: Bringing Architectural Coherence to Victorian Government ICT

The Environment

Victoria’s government ICT landscape had the characteristics common to large public sector environments that have grown organically over decades: substantial legacy infrastructure, strong departmental autonomy, overlapping capabilities built independently across agencies, and procurement decisions made within departmental boundaries rather than across them. Each agency had its own technology investments, its own vendor relationships, and — in many cases — its own version of capabilities that other departments had built separately at their own cost.

The challenge was not unique to Victoria. It is the default condition of any Westminster-style government where departments are genuinely autonomous, where secretaries are accountable to their own ministers, and where cross-departmental coordination requires political as much as operational alignment. Understanding this structure is the starting point for any architecture strategy that intends to work rather than merely exist on paper.

My mandate was to develop a series of Reference Technology Solutions — an architectural framework that would bring strategic coherence to this environment without eliminating the departmental flexibility that the structure of Victorian government legitimately requires.

What Reference Technology Solutions Actually Are

The term “Reference Technology Solution” is precise in a way that matters. It is not a mandate. It is not a standard that departments are required to adopt. It is a reference — a well-reasoned, well-documented architectural approach to a class of problem that departments encounter repeatedly, available for adoption when it fits their context and adaptable when it doesn’t.

This distinction was the foundation of everything that followed. Imposing a rigid architectural standard on Victorian government departments would have generated the compliance theatre that most government architecture initiatives produce — departments nominally adopting the standard while continuing to make independent decisions in practice, with an additional layer of governance overhead and resentment. A reference model, by contrast, gives departments something genuinely useful: a credible starting point that reduces their own design effort, reduces procurement risk, and creates the conditions for shared services where the economics justify them.

The RTS framework covered the full stack of government ICT — infrastructure, platforms, integration patterns, data architecture, security, and service delivery. For each domain, we documented the current state of Victorian government practice, identified the principal architectural patterns in use, assessed their fitness for purpose, and produced reference architectures that represented the recommended approach. These were not theoretical constructs; they were grounded in what was actually working in the Victorian environment, with clear reasoning for the recommendations and documented trade-offs for the alternatives.

Mapping the Current State

Before any reference architecture could be credible, it had to be based on an accurate picture of what existed. The current-state mapping exercise covered servers, networks, applications, data flows, and integration patterns across the major Victorian government departments — a comprehensive audit of a technology landscape that had never been documented at this level of coherence before.

What that mapping revealed was instructive. The most significant finding was not technical — it was economic. Redundancy was substantial: departments had independently built and maintained capabilities that were functionally equivalent, procured similar technologies at different price points without the leverage that collective procurement would have provided, and accumulated integration complexity between systems that, in several cases, existed primarily because nobody had assessed whether the underlying capabilities needed to be separate.

Mapping this landscape against a capability model — describing what the government needed to do rather than what technology it currently operated — made the redundancy visible in terms that finance and policy stakeholders could act on. A technology inventory tells you what you have. A capability map tells you how much of it you actually need, and which parts of it you are paying for multiple times.

Governance as Enablement

Architecture governance in government environments is frequently experienced as bureaucratic overhead — a review process that slows decisions without materially improving them. The reason this perception is so common is that it is often accurate. Governance frameworks that attempt to control every technology decision, that require architectural review for choices that are routine, and that produce compliance documentation rather than genuine guidance earn their reputation.

The approach we took inverted this. The RTS provided intelligent guardrails: clear recommendations for the decisions that most significantly affected the government’s architectural coherence, and explicit freedom for departments to make independent choices outside those boundaries. The governance mechanism was not a review board that departments had to satisfy — it was a framework that departments could use to make better decisions on their own, with escalation paths for the genuinely cross-departmental choices that required coordination.

A breakthrough in this framing came through the technology investment mapping work. By overlaying departmental technology portfolios against the capability model, we could demonstrate to department heads where their investment was producing unique capability and where it was replicating something already built elsewhere. This shifted the conversation from architecture governance as constraint to architecture governance as intelligence — a function that gave departments better information about their own investments and the broader ecosystem they operated within.

The Cultural Dimension

The technical framework was the easier half of the work. The harder half was the organisational change required to make cross-departmental architectural thinking a normal part of how Victorian government ICT operated.

Victorian departments are known for their distinct operational cultures. IT leaders had, in many cases, built their careers within a single department and their professional identity was closely connected to that department’s technological independence. The suggestion that shared architectural principles might serve their department better than full autonomy was not self-evidently welcome.

The cross-departmental workshops we ran were designed to address this directly. Rather than presenting the RTS as a policy to be implemented, we framed them as forums where IT leaders could examine their own architectural challenges alongside peers facing similar problems. The shared problems created the space for shared solutions. Capability models that transcended departmental boundaries became compelling not because we argued for them in the abstract but because department heads could see, concretely, where those boundaries had cost them.

Over time, the framing shifted — from technology as departmental operational overhead to technology as a strategic capability for delivering public services. That shift in how technology investment was understood and discussed at the leadership level was, ultimately, more significant than any specific architectural decision the RTS produced.

The Outcome

The RTS framework delivered measurable reductions in infrastructure redundancy across Victorian government departments. Procurement costs decreased as shared architectural standards created the conditions for collective purchasing leverage. Inter-departmental technology collaboration — which had previously required significant political effort to initiate — became progressively more routine as the shared architectural language reduced the friction of working across departmental boundaries.

The repeatable framework for architectural standardisation that emerged from this work outlasted the initial engagement, providing a foundation that departments could apply independently as their own circumstances evolved.

This work was recognised with the IBM Australia Bell Award for outstanding leadership — an acknowledgement of the impact that a well-executed architecture strategy can have when it is designed around how government actually works rather than how it is supposed to work in theory.

What Government Architecture Strategy Actually Requires

Three things that this engagement made durable in subsequent work.

The reference model is more powerful than the mandate. A well-reasoned architectural recommendation that departments can adopt voluntarily produces better outcomes than a standard imposed through governance. The voluntary adoption signals genuine fit; the mandate produces compliance without understanding. In an environment of genuine departmental autonomy, the reference model is not a compromise — it is the right tool.

Map capabilities before mapping technologies. A technology inventory describes what you have. A capability model describes what you need. The gap between the two is where the architectural opportunities live — the redundancies, the gaps, the investments that are producing capability nobody requires and the requirements that nobody has invested in. The capability map is the instrument that makes those opportunities visible to the people who can act on them.

Governance that produces intelligence is governance that gets used. The frameworks that survive in government environments are the ones that give departments better information, not the ones that add process overhead. The RTS succeeded partly because it was technically sound and partly because the technology investment mapping work gave department heads insight into their own portfolios that they could not easily have obtained any other way. That utility is what makes architectural governance sustainable.