Forget who has the smartest model. I think the Agentic AI platform war must ultimately become an infrastructure benchmarking problem, not just a model quality problem. Businesses are really looking for who can prove the most efficient execution fabric for orchestrating work at scale. Based on what I saw this week at ServiceNow’s flagship event, Knowledge 26, we’re a long way towards that goal.

For context, consider the mainframe era. The brands that dominated did not do so because people initially loved or understood mainframes. Or for that matter could easily differentiate. They won because enterprises needed confidence that mission-critical transactional workloads could execute reliably, repeatedly, and economically. AI is yet to arrive at that moment.

To achieve that confidence, a key measure of differentiation for mainframes was MIPS. It was the measure of computational throughput for the transactional era that helped businesses see that the technology coupled with their implementation model of it, was competitive. There is not yet to be an equivalent for the agentic era.

But I think TAPS (Tokens Attributed Per Second) could be that measure. And unlike raw token counts and costs which are understood, let’s call them TRU (token resource units), TAPS would allow the measurement of orchestration, flow, sequencing, exceptions, and execution efficiency across a business process.

Read on if Servicenow’s hockey stick moment is of interest.

Share

I just spent another week in the US at another amazing AI event. And while it was compelling, from all the conversations I had with both execs and regular customer delegates on the conference floor, it was also more evidence that there is still something strangely incomplete about the current AI market.

Every week we hear another declaration that one model is now marginally better than another. No better example than while I was at Knowledge, Anthropic separately announced “dreaming” as a new feature. And then there are the ever more agent announcements, and more autonomy opportunitues, more OOTB workflows, and more partnerships. It’s like wading through mud.

The market is behaving as though intelligence and scale and feature adoption alone will determine success and adoption. But it won’t. Enterprises do not really buy intelligence. They buy execution.

That distinction matters more than most sellers currently seem to realise. Because buried underneath the noise of the current AI cycle is a much older pattern that has played out across every major transition in technology history.

The early phase of every infrastructure market is dominated by excitement, expansion and marketing narratives as vendors chase adoption velocity. Investors on the other hand chase enormous growth curves. Buyers are left with possibility, through conversations dominated by potential rather than operational reality. That is exactly where AI sits today.

That matters because pre-IPO and hyper-growth environments reward very different things than mature infrastructure markets do. ServiceNow CEO Bill McDermott calls this the AI blind spot.

Right now the market is rewarding model capability, developer adoption, ecosystem gravity, consumer awareness, token growth, and perceived inevitability. Operational efficiency is discussed but still secondary though it will ultimately matter more once the dust from the big $1T IPO bubbles hopefully settles this year.

In many ways this mirrors the early days of the mainframe era. Mainframes were not initially sold because enterprises deeply understood computational theory. Years ago I worked with a guy who escorted ANZ Bank executives on a multi-month delegation through the United States ahead of their very first major mainframe purchase.

The stories were wild. Endless vendor briefings, demonstrations, dinners, dude ranches, and political theatre. But underneath it all was a very serious question. Could this new technology platform reliably run the bank’s critical transactional workloads repeatedly, safely and at scale? The trip was ultimately successful not because the executives suddenly became computer scientists, but because they gained confidence that the operational heart of the bank could execute on this new infrastructure.

What followed was transformational. Banks needed payment processing. Then airlines needed reservation systems. Then Governments needed records management and retailers needed inventory control. The mainframe became the operational backbone of the modern enterprise because it created confidence in execution. But not all mainframes were created equal. So eventually that confidence became competitively measurable. Through MIPS. Millions of Instructions Per Second.

I also worked with one of Australia’s pre-eminent benchmarking specialists who was still generating millions of dollars a year for analyst firms well into the early 2000s doing benchmarking projects for the country’s largest telcos, banks and state governments.

Anyone that has ever seen a benchmarking engagement up close knows MIPS were never perfect. There were endless arguments about weighting, workloads, utilisation patterns and what was really being measured. But that was never really the point.

What MIPS gave the market was a comparative language for discussing throughput, scale and operational capability. A way for organisations to compare not just machines, but the transactional confidence underpinning their organisations. Importantly for this story, enterprises were not really buying mainframes. They were buying confidence that the business itself could execute better. That same transition is now emerging with agentic AI.

Today the market still talks about AI primarily as though it is software, largely because it is abstracted through modern PaaS architectures and wrapped in applications, copilots and conversational interfaces. But true end-to-end agentic systems are operational infrastructure.

And like every major infrastructure shift before them, their value will ultimately be judged against the thing they are seeking to replace or outperform. That’s not humans. It’s decision chains and transactional processes and more.

The real promise of agentic infrastructure is not that it thinks better than people. It is that it executes work across complex organisational systems more efficiently, consistently and adaptively than the operational models we have built during the previous technology era.

What organisations actually care about is whether work flows more effectively through their value chain which, at some point through decomposition, standardisation and transformation, ultimately arrives at workflows. And workflows, including yours dear reader, are ugly things ripe for disruption.

They are not neat diagrams in strategy decks. They are living operational compromises accumulated over years or decades. They contain approvals, escalations, retries, integrations, policies, exceptions, governance controls (hopefully), human intervention, shadow processes, duplicated decisions, historical baggage and institutional chaos layered on top of one another through successive generations of technology and management thinking.

That’s how we are arriving at a consensus that the hard problem is not generating intelligence through models. It is actually orchestrating the work those models support. Which is why I increasingly suspect the AI market eventually needs its own MIPS moment.

It needs to be something capable of measuring how efficiently tokenised work moves through complex, multi-functional orchestrated operational environments. Something like TAPS. Tokens Attributed Per Second. Not as a metric for models, but as a benchmarking input for workflows executing across agentic platform environments.

Because the real challenge is not isolated prompts or single-agent interactions. It is the coordination and orchestration of work flowing across functions, systems, humans, policies, APIs, approvals, exceptions and decision layers in real operational environments. TAPS would attempt to measure how effectively tokens are consumed, routed, contextualised, validated, transformed and completed as work moves through these interconnected execution chains.

Not just “how many tokens were used”, but how efficiently the operational fabric itself converts tokenised reasoning into completed outcomes across the enterprise. That’s the unproven point of differentiation and why the current market conversation still feels incomplete. And part of the reason financial analysts are gutting software stock (the blind spot).

Right now the industry is obsessing over token pricing, and model scale, and inference costs. But enterprises run workflows which create entirely different economic pressures.

What happens when agentic systems begin running finance, procurement, HR, customer operation, compliance, field services and government processes at scale? Suddenly the important questions become which platforms minimise retries, and which orchestration layers, regardless of architectural partnerships, reduce token waste. Or as was evident at Knowledge 26 this week, the current red hot moment is which AI platforms govern complexity and risk most effectively? That is not a model intelligence conversation anymore. It is one purely focused an operational throughput.

I thought Paul Fipps, Servicenow’s President Global Customer Operations had a good message. CIOs don’t want ungoverned custom software running around the enterprise. But it doesn’t stop there. CEOs expect that as a baseline, but they are actually looking for something more.

In the transactional era, measurable packets of data moved through enterprise systems. In the agentic era, packets of tokens move through orchestrated workflows. And each of these workflows involves a complex model of multi-vendor agent approvals, retrievals, escalations, classification events, retries and contextual handoffs

All of it becomes part of a living token economy where attribution and not unit cost will unlock the difference between good and great agentic infrastructure. The enterprise itself will slowly transform into a token-routing environment. And once that happens, measurement and benchmarking becomes inevitable. Not because analysts like me invent new acronyms but because procurement eventually demands operational comparability.

Boards and CFOs will not tolerate fuzzy economics forever once these systems become embedded into critical operational processes. They’ll want to know if this new tech can execute work more efficiently than the alternatives. That is when the market changes. That is when the hockey stick happens for ServiceNow. When they don’t just orchestrate and govern better than anyone, but when they unequivocally show they minimise operational drag across tokenised workflows.

In other words, the winners may end up looking less like AI companies and more like operating system companies. And I think that is something that suits a company like ServiceNow. That’s operational reality and totally aligned with the base that propelled them to #1 in category.

So perhaps we simply are not there yet. But I think we are very close. Perhaps the market first needs to pass through this expansion-era phase where narrative dominance matters more than operational efficiency. Perhaps we need to get through the growth cycle, the valuation cycle and the platform land grab before the harder industrial questions (and answers) arrive. Because history suggests they always do.

Eventually every infrastructure market matures. And when it does, the conversation shifts from what can this tech do to how efficiently can this technology run the world?

That was the real story behind mainframes. And I increasingly suspect it will become the real story behind agentic infrastructure platforms too. MIPS helped sell the transactional age. TAPS, or whatever its equivalent may be, may yet define the agentic one.

Today’s AI narrative has been dominated by model breakthroughs, funding rounds, and product launches. It has felt like a glitzy, fast-moving, parallel universe. At times, more like watching the Oscars than understanding how work will actually change. Understanding, not shaped by Silicon Valley or Wall Street, has taken time to arrive.

I think what is starting to shift now is not the pace of innovation, but the quality of market thinking. The centre of gravity is moving away from the builders and toward the users who actually have to make this work.

From that perspective, whether you are an enterprise buyer or an institutional investor, these are ten observations about where I think the real AI market is heading, and why they will matter far more than the next model release or benchmark comparison.

1. The model is no longer the centre of the story

It initially looked like the model was the product. I think we are past that. Models are becoming powerful components. But they are increasingly interchangeable, increasingly abstracted, and increasingly hidden behind other layers. The centre of gravity is shifting upward into how models are applied, governed, and embedded into work, and the platforms that allow this to happen.

2. Software is still the distribution mechanism for AI

No matter how advanced the model becomes, the customer won’t just interact with a model. They’ll interact with software that relies on interfaces, workflows, approvals, forms, notifications, and dashboards. Bascially the same things that have always defined enterprise value. Nothing about that has changed yet. Because AI is an amplifier. It reinforce not replace the importance of the software systems through which work actually happens.

3. The “death of SaaS” is overstated, but the weak will disappear

We can debate the scale of the SaaS apocalypse, but surely all agree that there will be (and should be) casualties. A decade of proliferation has created a long tail of thin, single-purpose tools that exist largely because they could. Many of them will not survive. I’ve described this phase as “the application frat party” or “whatever-as-a-service.” Core systems, however, are not going away. If anything, systems of record become more important. They provide the structure, authority, and constraints that AI needs to operate safely. What disappears is not software itself, but the fragmentation. And that is long overdue.

4. The real enterprise problem is no longer integration. It is coordination

Connecting systems has been an observable challenge for most of my career, from the early days of “what the hell is middleware?” to today where APIs have largely solved that problem. But the harder challenge was never just about connecting systems. It was about following how work actually moves through a business. Defining who approves what, what triggers the next step, where decisions branch, how exceptions are handled, and how multiple functions interact in real time is still incredibly difficult. Where integration connects systems, coordination connects work, and delivers coherence back to the business. So to be valuable, AI has to sit inside a coordination layer.

5. Context matters more than data, and most organisations have lost it

At the exact moment AI arrives as a context-driven capability, most organisations have never had less clarity about themselves. Over the past decade, the rise of as-a-service has fragmented ownership, spread decision-making across functions, and steadily weakened enterprise architecture. Systems have multiplied, the CIO’s influence has diminished, and organisational coherence has declined as a result. At the same time, organisations have invested heavily in data lakes, warehouses, and pipelines, assuming that centralising data would unlock value. AI is now exposing the limits of that thinking. What remains is data without structure, systems without alignment, and organisations that struggle to explain how they actually operate end to end. That is the context gap, except it no longer a gap. It is a chasm.

6. Enterprise architecture is coming back, whether organisations are ready or not

The rise of SaaS decentralised technology decision-making (see #3). Buying groups emerged everywhere. Systems were acquired function by function. Architecture, as a discipline, quietly weakened. But AI does not tolerate that fragmentation. It forces organisations to confront how everything fits together and it exposes gaps, duplication, and incoherence. Architecture, that lost art, is no longer optional. It is being reintroduced by necessity.

7. The service layer is not shrinking. It is moving up the stack.

The belief that AI will shrink the services market and that automation will replace people, and the need for services will decline is just plain wrong. The service layer is actually becoming more valuable than the model layer. So the familiar pattern still holds. The one where the product arrives first, but the real value follows in services. The organisations that understand this will capture far more value than those focused purely on building models. Because AI doesn’t simplify the enterprise but it does make its complexity unavoidable. So the work moves, not disappears. It shifts toward far more demanding activities like stitching together models, workflows, governance, identity, and data into something that actually works inside an organisation. It is not implementation in the traditional sense but still services engineering.

8. Closed ecosystems will persist longer than expected

The case for open ecosystems built on a soft core and hardened shell has always been clear. But the market is not rational. Closed systems continue to win because many organisations are not equipped to manage multi-vendor complexity, so they default to simplicity. I see this consistently, particularly in government environments. That creates a paradox. Closed platforms are structurally weaker, but commercially durable. It is what keeps ERP vendors in the game. That durability buys time, but it is also finite. As the market evolves, remaining closed becomes harder than transitioning.

9. The AI bubble may need to dim before real progress accelerates

Right now, the model spotlight is too bright. It is drawing attention away from the harder, slower work required to make AI useful. That work is not in the models. It sits in process redesign, governance, data meaning, and organisational alignment. These are not headline topics, but they are the ones that determine outcomes. So the constraint is no longer capability, but focus. Progress will accelerate when the spotlight shifts, either because it fades, or because buyers (and investors) start dimming it themselves.

10. Most organisations are being sold the penthouse, not the front door

Vendors are pitching end-state visions replete with fully autonomous workflows, agentic enterprises and self-optimising systems. But organisations do not start there. They have always needed entry points in the form of clear, grounded, level one use cases that light the pathways into more mature adoption. Without that, the gap between ambition and execution remains way too wide (commercially and technically). The next phase of AI adoption will be defined by those who can show customers where to begin, not just where they could end up.

That’s it for now. So despite the tendency to believe that everything has changed (because this technology is so amazing), in reality, what is happening in the real economic markets, Monday to Sunday, is far more subtle. Almost recognisable?

What sits underneath these shifts is not a technology story at all, but a clear decision framework about where to invest, what to rationalise, how to architect, and how to execute. Things like “treat models as components, not strategy”, and “shift services investment up the value chain” and “rationalise the long tail of SaaS” are very practical steps to take.

AI extends what is possible, but it doesn’t rewrite the story. The fundamentals of software still apply, the complexity of organisations still matters, and the difficulty of execution hasn’t gone anywhere.

If anything, this may be the crowning achievement of the last 50 years of technology. It gives every organisation the potential to be great. But what happens next is not a technology question. It’s an organisational one.

One of the more interesting dynamics in the enterprise AI and workflow market is how it is beginning to reshape established ecosystem relationships. Take, for example, that between IBM and ServiceNow. This is not a marginal partnership. It spans resale, implementation, co-selling, and increasingly joint positioning around AI and workflow. While no single value is disclosed, the economic weight is significant. In APAC alone, IBM’s influence across these channels is likely in the range of $200–300 million annually, with the global figure considerably higher. More importantly, the downstream value through transformation and services is materially larger.

With offerings like watsonx Orchestrate, IBM is increasingly able to challenge ServiceNow in sectors such as banking, telecommunications, and the public sector. Particularly in APAC, where complexity, legacy integration, and architectural control are critical. This introduces the potential for meaningful headwinds, possibly approaching $1 billion over five years at the upper end of scenarios.

I’m not saying this should be interpreted as a direct loss. But we should see it for what it is. An ongoing contest over who owns the execution layer. To be successful IBM does not need to displace ServiceNow wholesale. It only needs to win in environments where workflow is inseparable from data, infrastructure, and legacy control.

In APAC, where ServiceNow’s revenue base is approximately $1.5 billion and growing toward a $3–4 billion opportunity over the next five years, the battleground is not just Net New ARR. It is also NRR under pressure. Not just who owns the installed base (which is the old business model), but who captures the next layer of spend within it (the new business model). IBM’s architecture-led, distributed execution model creates a very credible techncial pathway to intercept new regional spend that might otherwise default to ServiceNow.

The likely outcome is a selective diversion of high-value growth segments, particularly in industries where architectural authority remains contested. Framed this way, a $300–700 million shift over five years could be a reasonable expectation, with a $1 billion scenario representing the upper bound if IBM consistently captures complex, AI-led transformation programs. Of course, that’s just head-to-head and doesn’t factor other major players in the AI and workflow ecosystem aggressively positioning for market share.

Regardless, the strategic implication is clear. This is less about platform competition and more about who defines how work is executed in the next generation of enterprise architecture. That is exactly IBM’s point of entry. Let me explain the breakdown.

I recently spent a few days in Bangalore at IBM’s Asia Pacific analyst event, Insights 2026. They apply transformation across a set of capabilities that, in reality, operate in multiple directions at once. So it included a broad sweep across AI, data, and hybrid cloud, alongside extensive conversations with consulting teams and enterprise clients, including captive centre operations customers.

These sessions are always valuable because you get close to the thinking and hear how the company wants to be understood. But they don’t present a fully resolved picture. They don’t explicitly show how the pieces fit together. That part is left open. And that creates a familiar challenge. The more comprehensive the briefing, the harder it becomes to see the underlying shape of the real strategy.

So while IBM didn’t frame it this way, sitting there it was already starting to become clear to me that what I was hearing wasn’t just about the convergence of their AI, Hybrid and Data portfolios. It pointed to something more structural. A convergence towards the same layer of the enterprise that platforms like ServiceNow have defined.

Then, on the flight home, somewhere between Singapore and Brisbane, that picture sharpened in an unexpected way. A targeted email campaign promoting discounted SME offers across IBM’s core portfolios.

At face value, it was unremarkable. Just low-cost entry points into watsonx, data platforms, and hybrid cloud. But in the context of the previous few days, it changed the question from “what does IBM sell?” to “what are those pieces designed to become when you put them together?” Because that’s no longer a product question. It’s a platform one.

And when you look at it that way, the answer becomes clearer. An SME would typically buy a packaged application from an ISV. IBM is now selling the components to build that application. So while I’ve been critical in the past of its liberal use of the word “platform”, in 2026 I saw clear evidence that it is starting to execute in a way the PaaS market, and its enterprise consumer base, will recognise.

At enterprise scale, IBM is not easy to read cleanly. The most useful signals don’t come from how it describes itself, but from how each layer of the portfolio is now being positioned. It spans too much of the market to fit neatly into a conventional category. In my own filing structure, it effectively sits under “Vendor” and then “Mega Vendor,” because anything more precise quickly breaks down. It is not just a cloud provider, not just a software company, and not just a consulting firm, even though all three remain central to how its capabilities are delivered and realised.

So rather than trying to categorise it, the better way to understand IBM is to look at how it is organising itself. Increasingly, that comes down to three core domains that the market typically treats as separate.

AI, represented through platforms like IBM watsonx, promise not just model access but governance, auditability, and control. Data, increasingly anchored in offerings like IBM watsonx.data, which attempt to unify structured and unstructured information into something that can actually support decision-making. And hybrid cloud, underpinned by Red Hat OpenShift, which provides the execution environment across on-premise and public cloud infrastructure.

Seen together, the portfolio has, for some time, felt like a collection of adjacent bets. Coherent at a strategic level, but more of a vision than an operating model. The “old” IBM, viewed through the lens of a large enterprise, typically required translation, alignment, and a level of architectural intent that only existed in pockets.

This is why IBM has often appeared complex and fragmented. Not because the pieces didn’t logically fit, but because, without the involvement of IBM Consulting, they were rarely brought together as a unified system.

That’s the enterprise view. But what happens when you strip all of that away? The SME lens forces a different question. What would I actually use here? And when you look at IBM through that lens, the portfolio stops behaving like a set of products and starts behaving like a system.

Because while an SME might ask, “what would I actually use?”, the reality is they are still dependent on everything that sits beneath it whether that is identity, data, workflow, integration, and governance. So the platform doesn’t go away. It just becomes invisible, and unavoidable.

Increasingly, those dependencies are being organised around how work is actually executed. From a distance, the inclusion of AI in these SME offers looks like a standard market move. Discounted access to models. Credits for experimentation. A pathway into generative AI. But through the same lens, the dependency becomes obvious.

In the IBM model, AI is not intended to sit on top of work. It is designed to operate where work is already structured, observable, and governed. And that is the catch. Because creating that environment still requires significant process and data alignment. And these are areas where IBM Consulting has been deeply involved. The platform may now be visible, but it still needs to be assembled.

Without that, the models have nothing meaningful to act on. The outputs become inconsistent, the risk becomes unmanageable, and the promise collapses into novelty. So what looks like an AI entry point is actually another platform signal. AI is not something you add. It is something that emerges once work is already structured, observable, and governed. In other words, it operates at the level where work is actually executed.

The same pattern holds when you look at the data layer. At enterprise scale, the language of data fabric and lakehouse architecture suggests consolidation and opportunity. It offers a pathway to unify data and unlock value through analytics and AI. But at SME scale, it feels very different.

It exposes fragmentation, inconsistent definitions, and multiple versions of the same truth. Systems that were never designed to speak to each other are now being asked to form a coherent picture.

In that scenario, what is being offered is not just a platform, but a confrontation with reality. Data, in this context, has little value because it exists. It becomes valuable only when it can support execution and when it can inform decisions in a way that is consistent, auditable, and repeatable.

And then there is hybrid cloud, through platforms like Red Hat OpenShift. Outside of enterprise, the ability to run workloads anywhere and move between environments is often framed as optionality. But even from an SME perspective, that framing eventually breaks down.

You don’t just need hybrid cloud when your environment is already complex. Or when you are operating across multiple systems, multiple vendors, and multiple constraints. Or when control becomes more important than simplicity. You also need it through outages, geopolitical disruption, or supply chain failures like we’ve seen in recent weeks across the middle east. In that sense, hybrid cloud is not about infrastructure flexibility. It is about maintaining control over how work is executed in the presence of complexity.

Across all three layers, the pattern is the same. The value only materialises when it connects to how work is actually carried out. But then when you bring these three layers together, something shifts. AI, data, and hybrid cloud stop behaving like separate portfolios and become interdependent. All of a sudden this is not a collection of software infrastructure tools. It is an operating model.

So what does this mean in practice for the enterprise buyers and architects currently redefining their AI and platform strategies? Because once you strip it back, the market is no longer organised by products. It is organised by where work begins, where it is executed, and who controls it.

Microsoft still owns the broadest entry point for now. It sits where people interact with work. It makes AI immediate, accessible, and embedded in the tools that organisations already use. That position is not under threat in the near term. If anything, it is expanding, albeit with some opaqueness around its new AI-enabled E# licensing models.

ServiceNow has spent the last decade building something different. Not productivity, but execution. And the last two years re-establishing around being the platform where work is defined, routed, governed, and completed. Its language is increasingly consistent across workflows, data models, and systems of action. More recently, promoting the idea of a control plane for how work moves through an organisation.

What became clear in Bangalore is that IBM is now speaking a language that is uncomfortably familiar. Its framing is no longer confined to infrastructure, data, or models, but is now led by workflows, orchestration, and control towers. It is moving into observability of the execution layer and into the domain of how work itself is coordinated and governed. This is not a coincidence. It is a signal.

Because it means the market is no longer cleanly segmented into layers. It is converging around the single question of who owns the system that defines, governs, and executes work? ServiceNow were first to get that right.

In that context, IBM is no longer a deep architectural layer. It is reaching upward, attempting to connect its strengths in AI, data, and hybrid cloud into a model that can participate directly in execution. At the same time, ServiceNow is moving downward by strengthening its data foundations, expanding its AI capabilities, and positioning itself as more than just a workflow engine. Microsoft continues to expand laterally, embedding AI and automation into every surface where work begins.

So how does it stack up? I think IBM’s integrated portfolio spanning AI assistants and agents, middleware, data services, hybrid cloud, infrastructure, and its broader ecosystem, brings something genuinely distinct to the agentic workforce discussion. You can also read some of my earlier thoughts on IBM here (Agentic AI’s Narrow Door).

Right now, its strength lies in environments where complexity, regulation, and scale demand control. Where governance is not optional, and where execution must be observable and auditable across fragmented systems. As the conversation shifts from data sovereignty to AI sovereignty, that positioning becomes increasingly important.

Even more so when you consider that, according to IBM’s own recent CEO study, fewer than 16% of organisations have deployed AI at an enterprise-wide level. But the direction of travel is clear. It is no longer enough to provide the layers beneath work. Rather, every major platform is now moving toward owning the system through which work is actually carried out.

If a further proof-point was needed, IBM’s rollout of the watsonx.data Context Layer, effectively a context graph and semantic ontology layer, is another clear signal of where it is heading. This is a great move by IBM and is not just about improving data access or analytics but about defining how data relates to work.

And that moves IBM directly into territory that has historically been owned by ServiceNow. Because at its core, ServiceNow’s strength has never just been workflow. It has been the ability to model the relationships between services, systems, and processes in a way that allows work to be consistently executed.

What IBM is building through its context layer is not just a data capability. It is an alternative path to the same outcome ServiceNow has been pursuing. ServiceNow started with workflows and built a data model (CSDM) around them. It is an area I’ve long thought they have underplayed and under-promoted so it will be interesting to see how hard and visbily IBM will push Context Layer. They seem to be starting from the opposite direction by establishing the relationships between data, systems, and entities, and using that to inform how work should be understood and executed.

It is a subtle shift, but an important one. Because while literally everyone is now talking about workflows, the platform battle is shifting from “who runs workflows” to “who defines what things mean.” So it clearly spotlights that whoever orchestrates work must be able to define the ontology of the enterprise itself. That is the layer that ultimately determines how work can be executed, governed, and scaled. I’ve previously written about that here.

IBM’s approach to identity within this model also becomes critical. Whether it aligns to an existing framework or establishes its own will determine whether it converges with platforms like ServiceNow, or creates a parallel model of enterprise control.

Returning to the original arc, for most small and mid-sized organisations reading that marketing email, IBM’s SME offers would feel like overreach. Too much capability. Too much implied complexity and too far removed from immediate needs. And in many cases, that instinct will be correct. That’s why IBM Consulting features so prominently in so many IBM enterprise deals. But that is not the point.

Because what appears excessive at small scale is necessary at medium to large scale. And more importantly, it reveals the direction of travel. We are moving away from a world where organisations buy software to support tasks. Towards a world where platforms define how work is structured, governed, and executed.

So at this inflection point, the easiest way to consider IBM’s relevance in the platform market is not to start with its largest customers, but to strip the problem back to its simplest form. Because when you do, what remains is not a story about AI adoption or cloud migration. We are well past that. It is a highly trusted and capable transformation blueprint for what work will look like in the next decade.

I’ve been asked a lot about TechnologyOne’s AI offering, PLUS, since it was announced in October last year. Most of the questions start in a similar place. How does it compare on price? What does it actually cost to run? And increasingly, how well does it fit, architecturally and commercially, against other AI platforms? They’re good questions. But the moment you start pulling on PLUS, you’re analysing something slightly deeper than an AI product. You’re analysing the business model underneath it.

It has taken a while, but everyone is comfortable calling TechnologyOne a SaaS company now. They offer a form of cloud delivery, they have built into a subscription revenue business model, and they provide continuous updates. On the surface, it fits. But there has also always been a quiet mismatch sitting underneath both the architecture and the economics, and AI will increasingly expose it.

TechnologyOne doesn’t price like SaaS in the way the market now understands it. It anchors pricing to the economic footprint of the organisation (rateable properties), not the consumption footprint (users) of the system. That has allowed it to avoid the classic SaaS mechanics of seat expansion, licence optimisation, and user churn. It behaves less like a SaaS platform and more like a utility tied to the size of the council. That has allowed it to be stable, predictable, and highly effective in the ERP era.

The infrastructure architecture reinforces this position. Running on Amazon Web Services with managed environments is not the same as operating a fully shared, multi-tenant runtime. Platforms like Salesforce and ServiceNow are designed to share everything except the data. That’s what allows them to align product, pricing, and scale so tightly. TechnologyOne sits somewhere different. A single code line, delivered as a service, but with enough separation in the environment to justify a different economic model.

None of this is a flaw. If anything it explains their success both in the customer and equity markets. In fact, it even explains something more important. It explains why they haven’t had to change. Local government is a market defined by stability, low risk tolerance, and slow structural change. TechnologyOne’s model has been almost perfectly tuned to that reality.

They’ve captured stable customers and delivered predictable growth by leveraging high switching costs. It has allowed them to modernise delivery in their own way and at their own pace, but without needing to modernise economics. They moved to cloud, adopted global SaaS language, and evolved the product without fundamentally disturbing how company (i.e. investor) value was captured. That has worked while the unit of value has remained stable. But now AI is changing the unit of scale.

In a traditional ERP environment, system activity is a rough proxy for organisational size. More properties equals more transactions equals more staff interactions. You could price against the size of the council and be broadly aligned to the amount of work being done. But in an AI-driven environment, that link breaks.

A council with 10,000 properties could generate vastly different levels of system activity depending on how aggressively it adopts automation. One might use AI to assist staff at the margins. Another might automate entire decision pathways, compliance processes, and customer interactions. The difference in system workload is no longer marginal. It’s exponential. That creates a structural tension inside the current model.

Therefore if pricing remains anchored to properties while the volume of work being executed by the system increases dramatically, the cost to serve rises without a corresponding increase in revenue. That’s why the cost question about AI is so important. AI can pretty quickly stop looking like a margin enhancer and start to look like a margin risk. Not because the technology doesn’t work, but because the commercial model isn’t designed to capture it. That is, unless those costs are pushed on to the client.

This is why the shift we are seeing from vendors like Microsoft and ServiceNow and Salesforce is so important. Their pricing models are moving, however imperfectly, toward consumption signals like per-user copilots, per-workflow execution, and usage-based constructs. They are aligning to the unit that actually scales in an AI world. That unit is “the work”.

Which naturally leads to the question many are now asking. Can TechnologyOne partner its way through this? On the surface, it’s a compelling path. Let Microsoft, ServiceNow and others provide the high-frequency AI execution layer. Let TechnologyOne remain the trusted system of record. Integrate the two and move forward without disrupting the core model. And in the short to medium term, that works.

In fact, it’s already happening. In many cases, it appears to be driven by the customer base themselves, rather than centrally led by TechnologyOne. Councils are experimenting with AI well beyond PLUS. Whether that be through Microsoft layers, or automation through ServiceNow, or marketing or customer engagement through Salesforce, or even content coherence through Glean. All of whicvh give broad access to every LLM available in the market, at the pace of the market.

Meanwhile TechnologyOne continues to defend its anchor position in finance, regulatory, assets and core records. This is creating a clean conceptual split between systems that store the truth and systems that act on it. But while that split holds for a long time if architected by the client, it doesn’t hold forever in a partner model.

Because the system that sits in the flow of work becomes the one handling requests, and decisions, and the automation, and the interactions and inevitably becomes the centre of gravity. It begins to own the experience and shape the workflows and captures the operational data that increasingly defines value. It becomes obvious to everyone where the value lies.

Over time, the commercial fear is that the system of record risks becoming a dependency rather than the platform. So partnerships, in that sense, don’t resolve the tension. They do defer it, and in other cases, amplify it.

Regardless, the volume of work still increases and the cost to serve still rises. But the value created by that work begins to accumulate in the partner layer. Which means the conversation about PLUS, and about AI more broadly, cannot stop at capability or partnership but has to come back to the operating model.

TechnologyOne will continue to introduce AI capabilities. And it follows that every successful AI capability will increase the amount of work being executed by the AI system. In the current model, that increased activity has no natural economic expression (because TechnologyOne’s model doesn’t price activity). That creates a disconnect. System usage can scale rapidly, while revenue remains anchored to relatively static measures like the rate base.

In the short term, we see what’s happening now. AI modules drive an uplift in ACV and ARR at contract renewal time. But without a mechanism to price the underlying activity, that uplift risks being episodic rather than structural.

Over time, this puts pressure on both Revenue Per Customer (RPC) and Net Revenue Retention (NRR). Revenue per customer becomes even less reflective of actual system usage (broadly tracked today as module access), and expansion depends more on discrete pricing events than on organic growth in workload determined by cost.

That leaves two options. They absorb the increasing cost to serve, or introduce new charges to recover it. Neither is comfortable when undertaken as “make good” or “reckoning” provisions in the contract. Especially where pricing predictability has been a core tenet of the sector. But also in a market where competitors are aligning pricing more closely to consumption, it’s definitely not a position that holds indefinitely.

Which means the question is no longer whether TechnologyOne can “do AI”, we’ve already seen it can at some level. The question is whether its current model can absorb it. And that’s where the idea of “reinvention” starts to appear.

But this isn’t reinvention in the way people instinctively think about it. There will be no collapse of the current platform or a sudden pivot away from ERP. It can be something far more subtle, albeit more difficult. And that is realignment from how value is captured to how value is now created.

Because for most of its history, TechnologyOne has been able to anchor value in what a council is based on its size, structure and footprint. But AI shifts that anchor point. Value will increasingly sit in what the system does and the decisions it makes and the work it executes and the interactions it automates.

That shift doesn’t require TechnologyOne to stop being what it is. But it does require it to finally evolve and improve how it participates in that work. It could be a commercial model that introduces a second axis tied to usage or automation. Or a product narrative that moves from system of record to system of execution. And over time, an architectural direction that supports better higher-frequency, lower-friction work across the platform. So also improvements in the underlying content, service and identity ontologies.

Partnerships can help accelerate that journey by bringing capability and keeping TechnologyOne connected to the flow of work. But they are only a bridge, because ultimately, this is not a question of capability but one of realigning from pricing based on what a council is to pricing based on what a council’s systems actually do. That is why property-based pricing, which once looked like a perfect fit for the sector, now starts to look less like a strength, and more like a constraint on its future.

The important thing for councils to understand is that vendors will evolve because they have to. But councils don’t need to wait for that evolution to be complete. The ones that move early won’t just adopt AI faster, they’ll define where value sits in their environment before someone else does. And in relation to AI, that may be the most important decision of all.

Agentic AI works today. But for most organisations it remains in a narrow band of work. The net result is that the market is misreading the signal. Because it is focused on the destination, the level 5 or 6 maturity benchmark, and not the entry point or the path to get there. Enter Salesforce’s SMB play.

Agentic AI looks like it’s working, especially in smaller organisations. It is quick to deploy. It is easy to demonstrate. And it can deliver immediate gains in productivity. It also fits neatly into some workflows where speed matters more than consequence. It’s the kind of model I wrote about in TechnologyOne’s PLUS Moment.

And if you read that as the starting point, not the end state, the current wave of success tells you something important. It does not tell you that agentic AI is solved. But it does tell you we’re seeing the earliest stage of a much longer progression. One that will take years to unfold as organisations move from low-consequence efficiency into work that carries real consequence and accountability.

I feel like this is the part of the story the market continues to gloss over. Not just because we’re misreading the results, but because of how the story is being told. Vendors are conditioned to sell the future. The fully autonomous state. End-to-end orchestration. Agents operating confidently across the business. That’s what I refered to as Level 5 and 6 maturity in an article last year called Have You Tried Our New AI Agent?

And it’s not just a marketing choice. It’s a market expectation. Boards want market share, and category leadership and to know they are going to win. So the narrative gets pushed forward where the destination is clear and the vision is compelling. But it sits orders of magnitude ahead of where most organisations actually are. And in doing so, the middle gets lost.

We jump from aspiration to demonstration, without spending enough time on what meaningful entry points look like. Where do you actually start? What kinds of work can be trusted first?

That’s where the confusion creeps in. The harder the market pushes the future, the less clear the starting point becomes.

Early success is too often interpreted as capability (for both the customer and AI solution provider), when in reality we’re just seeing what happens when you apply autonomy to low-authority workflows. It’s not that every AI technology being pitched is mature. It’s that the client work isn’t demanding enough to expose where it fails (at scale or higher levels of workflow complexity). Now, after a few years of headline-grabbing announcements, it feels like things are starting to settle down in 2026.

In a recent briefing with Salesforce, what stood out was their emphasis on strong AI adoption in the CRM SMB segment. Even allowing for some variation between Salesforce and ABS definitions, that’s a TAM of over 2.5 million businesses in Australia.

The smaller deal sizes in this segment make it easy to dismiss, especially for enterprise-focused sales teams. But that misses the point. If agentic capabilities are landing quickly and sticking, that’s a signal, not something to write off.

What if this wasn’t just the easy version of the problem, but the honest one? What if it shows where agentic AI actually works today, and not where a keynote says it should.

In smaller organisations, most workflows sit in a low-authority band. Fewer systems. Lower consequence. Lighter governance, often implicit rather than defined. That’s the space where agents work easily. They can summarise, draft, trigger, and respond. They can take small actions without needing a deeply structured model of the organisation behind them (see Whatever-as-a-Service). Identity exists, but it doesn’t need to carry much meaning. It’s present, but it’s very thin. In that technical environment, agentic AI feels easy. But what if we stop seeing this as a weakness and start seeing it as a starting point?

With its latest SMB offerings, Salesforce is demonstrating through commercial expression, something much of the market is missing. Agentic AI is not something you install. It is something you grow into. It is a maturity curve. And one of the most important of this time. Yet vendors continue to sell the destination. Yes, it’s technically valid and an exciting place to be, but also practically out of reach for most organisations today. Largely because we are in a transitional age of computing, and once again in too much of a rush to get there.

What’s missing is simply clearer starting points. And I can’t for the life of me understand why more vendors don’t take a beat and realign around this fundamental assumption. It’s time to rebalance the rhetoric. Less about where the plane or train is going and more clarity on the airport or platform where I can step on.

Share

When it comes to AI, it’s more useful to think of SMB not as a cut-down version of the enterprise, but as the starting point of one. That matters even more today, as enterprise buying centres have become increasingly fragmented. That is why the AI platforms that will define the next operating model are the ones built to carry organisations through that journey, as their work gains complexity and consequence.

Take identity as an example. A business might begin with a simple login, minimal governance, and little or no integration. At that stage, identity doesn’t meaningfully constrain agentic capability. Because both are naturally limited to low-consequence workflows. So you can adopt a solution that will allow you to perform Level 1 or 2 AI.

Now as the organisation grows, so does the complexity of its work. More systems are added (swivel chair work begins). More customers. More transactions. More exposure. Identity starts to evolve. From simple login, to managed access, to SSO, to a fully governed identity platform. Workflow becomes more structured. Decisions begin to carry a lot more consequence. That requires AI at a Level 3 or 4 maturity, perhaps now in the form of an Agent, to remain useful, and evolve with it. Ideally without changing the underlying AI platform.

That is a pathway. From point of entry to escalating maturity.

And I think this is the quiet logic behind Salesforce’s tiered SMB model. From free to starter, to professional, to enterprise, to more advanced agentic capability, the platform and its licensing model, is not just scaling features. It is scaling the step conditions, up to a tipping point, from which AI in the form of agents, can be trusted to execute.

For big or small organisations, that journey can take years and reflects something deeper about Agentic AI. That it is not just about what the agent can do but about what the organisation is ready to let it do.

This is where the broader market narrative starts to quickly break down. Because we’ve become conditioned to look for immediate proof of value of high-maturity capabilities. Where only fast adoption and instant capability can deliver visible impact within a reporting cycle.

But that’s not how platforms like Salesforce create value. They create it over time. As organisations grow into them. As their work becomes more structured. As identity matures. As governance strengthens. As more consequential workflows move onto the platform. The value compounds. Not because the technology changes overnight, but because the conditions for using it evolve.

That kind of progression doesn’t show up cleanly in quarterly narratives. But it is exactly the kind of pattern long-term investors have always looked for. The ability to build with the customer, not just sell to them. In that sense, the slower journey is not a delay. It has always been the model.

In the early stages of that journey, the scope of what can be trusted remains narrow. Which is why most of what we are seeing today is still operating in the efficiency layer. AI can remove some friction and speed up some navigation. Maybe even reduce the effort required to move between systems. But it is still operating around the edges of work.

This doesn’t change the view that the real AI shift begins when agents move into workflows that carry consequence. At this level of maturity (5 or 6) a payment is no longer just a transaction, but financial authority. A service request is no longer just a ticket, but a commitment tied to service levels, risk, and compliance. And a system change is no longer just an update, but a controlled alteration to a live operating environment (managed behind the scenes by a service ontology).

Now the agent is no longer assisting. It is participating. And participation requires structure. This is where identity changes form. It stops being about access and becomes about authority. Who can act, under what conditions, with what level of accountability. Without that, the agent can suggest but it cannot execute. This is the boundary most organisations, nor technology vendors, especially legacy ERP vendors, have not yet crossed.

Not because they lack technology, but because they have never fully defined how work actually happens. It sits fragmented across systems, buried in process documents, or held in the heads of individuals. More mature Agentic AI exposes that immediately. It doesn’t fail because the model is weak but because there is nothing coherent for it to act within.

But nobody starts there. And this is why the SMB success stories matter right now. Not because they prove agentic AI is simple. But because they show where it starts. The real test is for both the vendor and the client is still going to be what happens as those organisations grow. Because that is where agentic AI stops being easy. And starts becoming accountable.

So the winners will not be the platforms with the simplest generative interface or the most capable agents. They will be the ones that understand where to start. The ones that can meet organisations at their point of entry and grow with them over time. The ones closest to the flow of work. The ones that can bind workflow, identity, and data into something that can actually hold responsibility, without requiring constant reinvention (or system replacement) as that work matures.

Two comments came up in an analyst call this week that immediately stuck with me.

“Customers want a neutral, independent identity platform
that can be easily deployed and support the maximum number of use cases,
particularly as they begin to introduce AI into workflows and business processes.”

“Agents are emerging as a new identity type,
and organisations now need to figure out how to govern them.”

It took me a few minutes to work out why they didn’t quite land with me. When taken in isolation both are true. But I think they also make it too easy to assume the problem begins with identity. And that’s the part worth challenging upfront, for the benefit of both customer organisations and technology providers.

The first could lead someone to assume that organisations are ready to drop AI into workflows, as if those workflows already exist in a coherent, structured form. They don’t. The second could lead someone to assume that agents are primarily a governance problem, as if their existence is what creates the need for control. They are not. In reality, I think both are downstream effects of something else entirely. Work.

Organisations do need a neutral identity platform. But not because they’ve decided identity is important. They need it because work has become fragmented across systems, channels, and now increasingly across humans and machines. The moment work starts to span boundaries, identity becomes operationally difficult. The same applies to agents.

Agents are not interesting because they are a new identity type. They are interesting because they are a new form of work execution. They take actions. They trigger processes. They make decisions, or at least simulate them. That is what forces identity into the conversation. Not their existence, but their behaviour.

If an agent never acted, it wouldn’t need an identity. It would just be software. The identity requirement emerges the moment the agent participates in workflow. This is the context that often goes missing. No work, no identity.

The identity platform market is not expanding again because identity is evolving. It is expanding because the nature of work is changing. The last time identity surged was with SaaS, when the problem was access. It was all about getting the right people into the right systems.

This is very different. AI is not increasing access. It is increasing action. More interactions, more autonomy, more delegation. Identity is being reintroduced as a problem because something now needs to govern all of that movement.

That’s why the idea of a neutral identity platform resonates and why platforms like Okta are a strong day one choice. Not because neutrality is inherently valuable, but because organisations are struggling to maintain control across an increasingly heterogeneous environment. Multiple systems, multiple vendors, multiple execution layers. Identity becomes the only thing that can sit across all of it.

But even then, it is still responding to something else. The deeper question is not how to govern agents. It is what work those agents are being asked to perform, and whether that work is actually understood, structured, and worth automating in the first place.

Because if the underlying workflows are still fragmented, manual, or poorly defined, then introducing agents does not create value. It simply accelerates inconsistency. And wrapping that in a strong identity model does not fix it. It just makes it governable. Yo end up with controlled chaos.

This is the pattern that is starting to emerge. Identity vendors are correctly identifying that the world is becoming more complex, more distributed, and more autonomous. They are positioning identity as the layer that brings order to that complexity. But the complexity itself is not coming from identity. It is coming from work that has outgrown the structures designed to support it. Which leads to a more grounded way of thinking about it.

The next phase of the market will not be defined by identity alone, but by how clearly it is connected to the work it is there to govern. The identity vendors that recognise this best, and are most articulate about anchoring their story in workflow, action, and outcomes, will find themselves riding a much larger wave. Because identity does not create the demand. Work does.

Identity scales as work scales. It becomes more critical as work becomes more distributed, more automated, and more autonomous. But it is always responding to something else. So the opportunity for identity providers is not to compete for primacy, but to align more directly with where value is actually created. To move closer to the systems and platforms where work is defined, executed, and increasingly delegated to machines. Done well, this will not diminish identity but amplify it.

Because when identity is tied to action (who or what is allowed to do something, not just access something) it becomes part of the operating model, not just the control layer around it. And that is where the market expands. Agents make this unavoidable. They are not a new identity problem, but a new form of work execution. And as that work scales, identity is pulled into it. Which is why identity and workflow cannot stand apart for long.

An identity layer without coherent workflows has nothing meaningful to control. A workflow layer without identity has no safe way to scale. They are not competing abstractions. They are interdependent as I called out in the Whatever-as-a-Service post.

The organisations that recognise this will stop treating identity and workflow as separate domains, and start treating them as two sides of the same operating model. One defines what can happen. The other defines who or what is allowed to make it happen. This is where the market is heading.

Platforms like ServiceNow and Salesforce are expanding identity capabilities because they need control over the work they orchestrate. Identity providers like Okta are moving closer to workflow because they need context to remain relevant. The centre of gravity is shifting toward the intersection. And in an agentic world, that intersection becomes the system.

Agents don’t just need identities. They need roles, permissions, and boundaries tied directly to the work they perform. That requires more than authentication. It requires a shared understanding of entities, states, and actions. That’s an operational ontology that both identity and workflow systems can interpret in the same way.

Without that, identity and workflow drift apart. With it, they reinforce each other. Which is why the likely winners will not be those who dominate one layer in isolation, but those who align both. Not simply around access or automation but around coordinated, governed action. That is where the real value sits.

Behind all of this sits a relatively well-defined group of control-plane identity providers. But the strongest will no longer be those with the best integrations. They’ll be the ones closest to the flow of work. For paid subscribers, I’ve put together a short view of where I think the major vendors sit today against this shift.

Read more

Everyone says you can’t do artificial intelligence with bad data. And at face value, the argument seems reasonable. But what is the answer then? We can’t simply keep repeating that transformation will take longer than expected without a clearer explanation of how fragmented enterprise data, with all its inconsistency and incompleteness, is supposed to be fixed before AI can safely operate.

And what about the organisations with messy data that are already beginning to see real operational value from AI platforms? Not through chatbots or document summarisation, but through automation, orchestration and decision support embedded directly into enterprise workflows. How does that make any sense?

Well, as it turns out, it is precisely this contradiction that reveals the deeper truth. The biggest barrier to AI inside most organisations has never been bad data. It is that they have never clearly described how the relationships actually operate between people, systems, approvals and the work that flows between them.

Enterprise technology has long been dominated by the simple assumption that systems require clean data. This belief emerged from the era of enterprise resource planning where systems were designed to execute deterministic transactions. If the underlying data was inconsistent, the results could not be trusted. That was fine for a generation, but the same assumption has carried forward into the AI era almost without question.

But artificial intelligence does not simply operate on tables and records. It operates on meaning. And that requires us to stop thinking about this technology in the way we have managed enterprise systems for the past thirty years.

For AI to perform real work inside an organisation, it must understand several things at the same time. It must know what objects exist in the enterprise, how those objects relate to one another, who has the authority to act on them, and how work moves between them. That’s what I mean by understanding the relationship structures of the organisation itself.

We’ve all worked for organisations that have never formally defined these relationships. They exist implicitly inside systems, processes and job descriptions, but rarely as a coherent model of how the enterprise actually functions or behaves. That model has a name. An ontology. And without that model, artificial intelligence is forced to improvise.

Ontology is a word that sounds abstract and so it is rarely used even by the companies that have great ontological solutions, and almost never in executive company. But the concept is straightforward. It is simply the structured representation of the things that exist in an organisation and the relationships between them.

A council, for example, operates around concepts such as citizens, properties, permits, assets and service requests. But the important thing is not simply that these records exist in systems (as a data model). It is how they relate to the work of the organisation.

A citizen may own a property. That property may require a permit before certain activities can occur. A permit must be assessed and approved by an officer. An inspection may later confirm that the conditions of that permit have been met.

Taken together, these relationships describe how the organisation actually operates, how decisions are made, who is responsible and how work flows across the council. Without that structure, artificial intelligence is left guessing or hallucinating. It can see the records, but it cannot understand the work.

Language models don’t fix this. Even connected to the right documents it can only summarise policies or generate reports. But what it cannot do alone is safely execute work across systems, departments and authorities. It does not know which team owns a service, which role must approve an action or how a process should unfold. Those rules do not live in the data alone. They live in the meaning of the enterprise. And meaning is the currency of AI. Said another way, AI runs on infrastructure but it operates on meaning. It’s just that most organisations have never actually modelled what their organisations mean.

So how did we get here? We can all agree that the cloud revolution dramatically expanded the number of systems inside organisations. It has been an appslosion! Sales teams adopted customer platforms, HR teams adopted workforce systems, finance departments moved to cloud ERP solutions and collaboration tools multiplied across the enterprise.

It’s a phenomenon I call “Whatever-as-a-Service”. A decades long application frat party. Connectivity improved dramatically but organisational meaning did not. It actually got worse. Each system introduced its own definition of the world. A “customer” in one application became an “account” in another and a “ratepayer” somewhere else. Integration platforms allowed data to move between these systems, but they rarely reconciled their underlying semantics.

We humans have quietly resolved these inconsistencies through experience and context, not architecture. But Artificial intelligence cannot. For AI to operate safely, the enterprise must first be represented somewhere as a coherent model of objects, relationships, authority and process. But where? This is where platforms like ServiceNow begin to change the conversation.

They have gradually assembled a structure that resembles an operating environment for enterprise work. Through frameworks such as the Common Service Data Model (CSDM) and the Configuration Management Database (CMDB), it is the role of the platform to model relationships between services, applications, infrastructure and teams. Incidents impact services. Services support business capabilities. Teams own responsibilities. Workflows define how requests are approved, escalated and resolved. What emerges is not simply a data platform, but a representation of how the organisation behaves.

You can see this clearly in some of the publicly available architecture diagrams. The ontological elements I am talking about in this article do not sit purely within a data model or the organisation’s systems of record.

Instead they appear in what ServiceNow describes as the semantic and intelligence layers of the platform. This is the connective tissue that ties enterprise data, workflows and AI together. It’s the secret sauce your systems architecture is probably missing if you want to do AI well.

That ontological representation of the business provides something more valuable than perfectly structured data. It provides operational coherence. And when relationships between services, teams and responsibilities are clearly defined, work can move predictably through the enterprise even if the underlying data describing those objects remains imperfect.

Incidents can still route to the responsible teams. Approvals can still reach authorised managers. Changes can still propagate through dependency structures. The ontology stabilises the environment. Which brings us back to the point. Perfect data may be desirable but ontology is essential.

Another critical component of enterprise ontology lies in identity systems. Platforms such as Microsoft Entra or Okta maintain a living map of organisational authority. They define who belongs to which teams, which systems individuals can access and which roles they perform. Those relationships quietly encode part of the enterprise’s operating structure.

For artificial intelligence, this authority layer is essential. An AI system cannot safely approve a payment, provision an employee account or modify a record unless it understands who is authorised to perform those actions. Governance therefore becomes structural rather than procedural. Security, identity and workflow together form the guardrails within which intelligent systems can operate.

Newer AI-native platforms are beginning to recognise this pattern as well. Systems such as Glean (in Australia, via Journ3y), construct knowledge graphs that map relationships between people, documents and projects across collaboration tools. Rather than attempting to impose a new security model, they inherit the permissions already defined in identity and collaboration platforms. If a document is accessible in its original system, it remains accessible in the AI environment. The insight is simple but powerful and this kind of leaning into the identity ontology approach underpins their growing success.

What this also reveals is that the meaning of the organisation can already exist in some places. It is simply scattered across systems, permissions and workflows. The challenge is therefore to surface those relationships. Once they are visible, the AI models themselves that feed the ontological structure become interchangeable. That’s why every big vendor is partnering with every AI model. It’s because ultimately the ontology becomes more important than the model.

The enterprise technology industry spent decades believing that clean data was the prerequisite for effective systems. It’s ok to say, structure the work first, and the data will eventually follow.

This shift carries another implication that the enterprise software industry has begun to recognise. Best-of-breed approaches to software work because humans reconcile the differences. AI cannot without a platform. Artificial intelligence operates far more effectively within environments where objects, relationships and authority are clearly defined. That environment increasingly emerges around platforms capable of modelling enterprise meaning. It’s part of the (very nuanced) argument discussing the “death of SaaS”.

Once such a platform exists, other systems begin to orbit around it. Workflows attach to it. Identity integrates with it. AI agents execute within it. Because ontology has gravity. Not AI. But AI is what captures attention. Ontology is what actually holds the system together.

This is why ServiceNow, Salesforce and Palantir are becoming strategically very very important. They are not simply applications. They are evolving to systems of meaning. And once an organisation begins to depend on a system of meaning, endlessly assembling best-of-breed tools (whatever-as-a-service) starts to lose its economic, financial, and technical appeal.

The bottom line is that we need to think differently about this. For decades we have pursued systems of record where the challenge was believed to be storing information correctly. Artificial intelligence forces a different question. It is no longer about where the data lives but whether the organisation has ever explained what the data means.

Therefore before machines can run the enterprise, someone must describe how the enterprise behaves. That description is not just a bunch of data schemas and lakes. It is an ontology. And the organisations that recognise this will discover that the biggest obstacle to AI was never bad data but understanding themselves.

That said, the answer to all this is not “buy a platform”, though I am glad that platform is now a broadly accepted conversation. It is more like “choose your entry point to platform.” That means identifying coordination failures within the business (problem statement). These coordination failures are usually the result of missing ontology.

I’ve included a simple example below. It reflects the kind of issue that commonly emerges during staff workshops and consultation when organisations are considering new systems. In one organisation we identified around thirty of these coordination problems in just a couple of days.

Let’s consider a common coordination failure like employee onboarding. In many organisations, provisioning a new employee across HR, payroll, finance, identity and IT service systems can take several days.

1. Coordination problem: Employee provisioning takes five days.

2. Desired outcome: Reduce onboarding time to two hours.

3. Why AI alone fails: AI cannot resolve cross-system discrepancies or coordinate approvals across multiple systems without understanding how those systems relate to each other.

The starting point is not the (new system or) platform. It is defining the ontology of the employee domain. That means identifying the core objects and relationships involved like employee, department, role, system access and approvals, and how they relate to one another. An employee belongs to a department. A department grants certain roles. A role determines which systems the employee should access and which manager must approve that access.

Once that structure is defined, the systems can be mapped against it. HR, payroll, finance, identity and IT service management platforms each manage part of that model, but none of them represent it completely on their own. The ontology provides the common structure that allows those systems to coordinate.

This is where platforms like ServiceNow become important.

Inside ServiceNow, those objects can be represented explicitly. An employee record may originate in the HR system, but ServiceNow can model the relationships between the employee, their department, their manager and the services they require. The platform’s data structures, including the configuration management database and related service models, allow those relationships to be expressed consistently across workflows.

Once the objects and relationships are visible, the missing capability becomes clear. Orchestrate the workflow across systems. That is the “simple” answer most execs want.

Using workflow automation and integration capabilities, ServiceNow can trigger provisioning steps across the relevant systems. HR creates the employee record. Identity systems provision accounts and access. IT service workflows allocate devices and system permissions. Finance systems configure payroll records. Approvals are routed automatically to the correct managers based on the defined relationships. So instead of integrating systems in isolation, the platform orchestrates the workflow across them.

At that point AI becomes useful. An AI agent can monitor the onboarding process, detect failures when provisioning steps break, investigate discrepancies between systems and recommend or trigger corrective actions. What previously required manual coordination across several teams can collapse into hours.

The larger point is that employee onboarding is only one example. Once organisations begin mapping coordination failures in the employee domain, a much broader pattern usually emerges.

In workshops and operational reviews across several organisations I’ve worked with, we routinely identify dozens of workflows that suffer from the same underlying problem. Work spans multiple systems, roles and approvals, but no single structure exists to coordinate them.

Examples include the creation and approval of position descriptions, recruitment workflows covering advertising, interviews, references and medical checks, employee induction processes including compliance training, leave request approvals, employee issue or case management, professional development requests and reimbursements, performance appraisal cycles, talent and skills searches, promotions and transfers, employee offboarding, and routine activities such as timesheet submission and approval.

Each of these processes touches multiple systems and involves several roles across the organisation, especially after more than a decade of whatever-as-a-service. Viewed individually they appear to be isolated workflow problems. Viewed together they reveal something more fundamental. The organisation lacks a shared model of how employee-related work flows across its systems.

This is where ontology begins to take shape. Each coordination problem exposes another part of the enterprise model that needs to be defined from the objects involved, the relationships between them, the authority required to act and the workflows that move work forward.

Over time those fragments accumulate into a coherent ontology of the employee domain. But that only works if the organisation has a platform capable of orchestrating across systems once those relationships are defined. Without that capability, the ontology remains theoretical. With it, the coordination problems begin to collapse.

That’s the power of a platform like ServiceNow. With or without clean data.

Australia’s major banks did not voluntarily embark on large-scale customer identity remediation. They were pushed. Regulatory tightening around KYC and AML reframed customer data quality from an operational concern into a compliance risk. In doing so, it exposed how much institutional confidence had been placed in identity records that were never truly verified. The banks aren’t now just fixing UX. They are protecting their licence to operate. Think about that for a second.

While the public narrative centres on financial crime, terrorism financing, and systemic integrity, something more structural is occurring beneath the surface. Compliance is quietly converting identity data into hardened economic infrastructure. Data that survives sustained regulatory scrutiny becomes economically different. It can be relied upon and automated against and shared internally without qualification. And it reduces the cost and risk of every downstream decision that depends on it.

And today that matters beyond compliance. Verified identity is not just a regulatory obligation. It is a prerequisite for automation at scale. Without trustworthy records, delegated work collapses back into manual oversight. But with them, institutions can safely transition toward machine-assisted and agentic operating models.

In a recent discussion with one of the Big Four banks, I was told they are actively validating more than 1.3 million unique customer records. Not enriching them. Not optimising them. Simply validating. Addresses. Employment status. Proof of identity. Duplicate CRNs. Parallel identifiers created across legacy systems. Records that were considered “good enough” for years, but are no longer defensible.

These are institutions with deep technology budgets, mature analytics capability, and decades of digital transformation behind them. They have invested heavily. They have modernised repeatedly. Yet even here, identity foundations required remediation at scale.

So, if that is the position of Australia’s most heavily regulated, best-funded data environments, what does that imply for everyone else? Well, a great deal.

Let me make this far less abstract using my own personal experience.

Over several months my bank sent repeated requests for updated KYC information (primed by their own regulatory deadlines). I delayed. I was busy, and yes, slightly stubborn. But I was also hesitant because I knew the friction that was coming. I couldn’t remember my CRN. Password? Yes. PIN? Yes. Account numbers? Naturally. I’ve been a customer for decades. But the CRN, that single identifier, isn’t something someone needs on a day to day basis.

I tried and failed to recover it online. The website process instructed me to '“Please call this number.” Urgh. I opted to book an online appointment at the local branch, as much to transfer the inconvenience back to the organisation that had created it.

A bank employee then sat with me for roughly twenty minutes to satisfy compliance obligations. The interaction began with a simple question: “Why are you here?” Anyone who has spent time around agentic AI will recognise immediately this. It was textbook intent capture. The autonomous systems we are talking about today will be able to ask that question, instantly classify the request, and route the workflow without ever needing a chair. Instead, the process unfolded manually.

I explained that I was unsure of my CRN. I then provided basic identifying information. Then produced my passport. It was taken away and photocopied. I have submitted digital passport scans for foreign visa applications for years. Entire governments verify identity at national scale using digital processes. Here, a human inspected the document and made a copy.

I then signed a paper form. I updated my details, speaking while he typed. He retrieved my CRN and handed it to me. He then triggered a one-time password so I could re-enter and verify the same information inside my banking app. I typed it all again. Job done.

We can all agree that nothing in that interaction required complex human judgement. It was structured, sequential and deterministic. It was, in effect, an agentic workflow executed by people because the underlying identity data and orchestration layer were not sufficiently trusted to run autonomously1.

Now multiply that experience nationwide. If one million customers require similar service, and each interaction consumes twenty minutes, that equates to twenty million minutes. For a single institution. More than 330,000 hours. Roughly 160 full-time staff years. That’s the hidden cost of identity fragility.

Regulation can force the clean-up. But it is data inconsistency and orchestration immaturity that determine how painful that clean-up becomes. The regulatory stick is not creating the problem. It is exposing decades of accumulated identity drift. The institutions that complete this remediation properly will not simply satisfy compliance. They will harden their operating core and in doing so, unlock nonlinear gains. Because once verified identity is embedded at platform level, every workflow that depends on it becomes safer to automate, every delegated decision requires less oversight and every downstream interaction inherits trust.

The remediation cost, though significant, is incurred once. But the leverage compounds everywhere. Verified identity is not incremental improvement. It is an enabling condition for automation, delegation, and machine-scale trust.

If that is what identity remediation unlocks in banking, it is worth asking what the equivalent looks like in local government. Across Australia, the council Name and Address Register (NAR) underpins almost everything. Rates and property systems. Planning applications. Waste services. Animal registrations. Libraries. Customer request management. Infringements. Community services. It is the quiet spine of council operations. Yet in many councils, the NAR, or more accurately, the multiple NARs, sit in quiet disrepair.

Duplicate ratepayers. Historic land titles still attached to prior owners. Household members fragmented across systems. CRM records that do not reconcile with property data. Decades of manual overrides. Inconsistent address formats across applications. None of these are edge cases. They are structural artefacts of systems built for billing and statutory record-keeping, not for orchestration.

And yet there is increasing pressure for councils to now deliver seamless portals and real-time service coordination, better automate their workflows, and, if you don’t mind, now adopt AI-enabled assistance. Many voices in the sector speak confidently about digital experience yet far less about whether the identity spine beneath that experience is coherent, trusted, and platform-ready.

Whereas banks are being forced to confront identity integrity through regulatory mandate. Councils are not, which I think raises a harder question. In the absence of sector-wide enforcement, does identity remediation simply fall down the priority list? In my own experience, compliance budgets are approved quickly. Foundational data hygiene projects rarely are.

This matters more than ever now because Agentic AI and platform orchestration are not limited by intelligence. They are limited by data confidence. So without a validated citizen and property spine, automation just scales inconsistency. An AI assistant trained on duplicated identities does not fix the duplication. It accelerates the confusion and drives the customer into the front counter. A portal layered over fragmented records does not create seamless experience. It just masks fragmentation behind a digital façade.

And it’s not that it is not possible to achieve better right-sized outcomes. And the ambition for better citizen experience is definitely real. And the technology exists. And the sector talks confidently about transformation. But the NAR remains an unresolved architectural dependency. And this is where the uncomfortable truth sits.

Council CIOs and IT Managers cannot solve this alone. They can propose remediation programs. They can modernise systems. They can integrate platforms. But identity remediation at sector scale is not an IT project. It is a governance mandate.

Banks are not just cleaning millions of records because their CIOs and CTOs were ambitious, though of course many are. They are cleaning them because regulators made identity integrity a board-level risk. So until the civic identity spine is treated as a governance and risk issue, and not merely a system hygiene task, progress will remain incremental. So how do we move this forward?

If we want faster digital progress in local government, we need to reframe the Name and Address Register as critical infrastructure. Not IT. Not a back-office dataset. Not a legacy inconvenience. Critical civic infrastructure.

Councils understand assets better than almost any tier of government. They manage roads, bridges, stormwater systems, community buildings, parks and fleets through disciplined asset management frameworks. They track condition, depreciation, lifecycle risk and renewal schedules. They allocate capital to prevent failure. They plan decades ahead. Local government is, at its core, an asset portfolio manager. Now imagine if that same legislative discipline were applied to civic identity data.

It’s not such a bold step. Councils exist through state legislation. In most jurisdictions, asset management planning is mandated. They are required to demonstrate lifecycle planning, risk mitigation, renewal forecasting and financial sustainability across their physical asset base. The governance machinery already exists.

Imagine a state-level directive requiring councils to validate, reconcile and standardise their Name and Address Register over a defined period. Standardised address formats. Duplicate detection and remediation. Cross-system identity reconciliation. Clear ownership. Auditability. Executive reporting on data integrity metrics. Not as an IT uplift. As mandated asset stewardship.

It would not be glamorous. It would not generate headlines the way KYC has in banking (though it probably should). But it would create the conditions under which digital ambition could safely operate.

State governments already exercise oversight of councils in matters of financial sustainability and infrastructure risk. Extending that discipline to digital identity would not be radical. It would simply recognise that the civic identity spine now underpins service delivery as materially as roads and stormwater. The sector does not need another transformation slogan. It just needs the Name and Address Register treated with the same seriousness as a bridge.

Achieve that, and its even possible to see a little further down the orad. Across Australia, there is frequent discussion about councils sharing the cost of technology platforms. Shared ERP environments. Shared CRM. Regional system consolidation. The logic is understandable. Pooling investment appears efficient. Buying the same system sounds rational. And in principle, it is not a bad idea. But it is incomplete because systems do not create capability. Data does.

Two councils running the same platform with inconsistent, duplicated and poorly reconciled Name and Address Registers will not achieve interoperability. They will share infrastructure, but not integrity. The argument to “buy the same system” is easier to grasp. It is concrete. It can be tendered. It can be budgeted. It produces visible alignment.

But shared data discipline is harder. It requires governance alignment, common standards, reconciliation effort and executive mandate. It does not generate ribbon-cutting moments. But in practice, the capability of any shared system is determined by the quality of the data flowing through it.

A shared platform built on fragmented identity registers simply aggregates fragmentation at scale. If we are serious about shared technology services, then the logical precursor is shared identity integrity. Otherwise we are optimising the container while ignoring its contents.

What will not go away is the fact that, as citizens, we will constantly demand better digital engagement with our local authorities. Every new generation will expect faster responses. Better portals (and agents!). Coordinated services. Those experiences are built on identity integrity.

“Our” banks know that regulatory pressure accelerates the strengthening of that foundation. Our local governments probably do too and should not wait for a similar stick.

If councils are serious about AI, orchestration and modern digital experience, the transition must be led from the top, framed not as digital uplift, but as governance and risk management. Banking was compelled by KYC. Not because it was technologically elegant, but because it was institutionally undeniable. Boards understood it. Audit committees tracked it. Executives funded it.

Local government needs its own forcing function. One that reframes the Name and Address Register as critical civic infrastructure. And one that translates identity integrity into the language of risk and stewardship that non-technical leaders already understand, much as KYC did in banking.

Without that shift, digital ambition will roam the streets of an LGA near you. Visible, energetic, and politically attractive. All while the identity infrastructure it relies on remains untreated.

Everyone is racing toward an AI-enabled future state, but most organisations are working on the wrong problem first. The real challenge of 2026 is not model capability, agent maturity, or responsible AI frameworks. It is the far harder work of changing the ERP-centred operating model that still sits underneath almost every enterprise. AI will arrive regardless. The question is whether organisations will be structurally ready for it. And who is accountable for making them so.

For decades, ERP has been the gravitational centre of enterprise technology. Not just as a system of record, but as the implicit organiser of work, authority, and accountability. Processes were designed around its constraints. Humans filled the gaps. Control lived in people as much as in systems. That model worked until intelligence began to move into the machine.

AI does not fit neatly into an ERP-centred world. It does not tolerate implicit intent, fragmented state, or human-held orchestration. When dropped into these environments, AI does not transform them, it compensates for them. So humans remain in the loop not because judgement is required, but because the operating model cannot yet stand on its own.

That is why the real AI task in front of us is architectural, not algorithmic. To reach a future where AI can act, not just advise, organisations must first decentre ERP as the organising principle of work and reframe it as a still critical but bounded system of record within a broader platform architecture. This is not about replacing ERP. It is about relieving it of a role it was never designed to play.

The inevitable AI future state cannot be achieved by layering more intelligence on top of yesterday’s operating model. It can be achieved by doing the harder, less glamorous work of redesigning how intent, flow, and authority are expressed across the enterprise. That is the real AI challenge of 2026. So let’s get busy changing the world.

One of the quiet failures of 21st-century enterprise technology so far is that we keep using 20th-century language to describe it. “Human-in-the-loop” is the latest perfect example. It is usually presented as wisdom. A familiar sign that an organisation understands the limits of automation and prudently respects the role of its people. In reality, I think it really signals something far less noble.

When AI strategy or product selection depends on humans remaining in the loop to make the system work, the problem isn’t ethics or caution, it’s architecture. What you’ve really done is extend an ERP operating model, wrapped it in AI, and moved it onto modern infrastructure.

AI has exposed the limits of application sprawl, outsourced responsibility, and ERP-centred thinking, all relics of a 20th-century operating model that no longer holds. The irony is that the one construct we should have preserved to manage this complexity, the CIO as a true technology leader, has been steadily dismantled at the very moment it is most needed.

For most of the modern enterprise era, systems were built around transactions, not flow. Work happened because a human initiated it, pushed it forward, interpreted exceptions, and absorbed ambiguity. Technology recorded outcomes. But people carried the intent of the transaction. ERP systems formalised this worldview.

Byut they were never designed to run organisations autonomously. They were designed to support human-led execution. Roles, approvals, screens, handoffs, and controls all assumed that a person sat at the centre of the loop.

When AI is layered onto this environment, it does exactly what you would expect. It becomes expontentially smarter at the edges. It summarises, explains, recommends, and reassures better than we can. It improves interaction without changing the underlying structure. So humans stay in the loop. They approve what the system cannot approve. They escalate what the system cannot interpret. They stitch together what the architecture cannot orchestrate.

This becomes a serious problem at scale. Boards, whether public or private, exist to govern systems that must operate reliably, repeatedly, and under pressure. Not once. Not in a pilot. Not in a demo. At national or enterprise scale, with failure modes that are political, legal, financial, and human. We’ve seen this before as part of every significant 21st century change.

Rolling out a national vaccination program is not a communications exercise. It is a system-of-systems problem involving supply chains, identity, eligibility rules, appointment scheduling, exception handling, adverse event reporting, and public trust, all operating under intense scrutiny and time pressure. Boards were not asking whether the intent was ethical. They were asking whether the system could withstand volume, variation, and failure without collapsing.

The same is true of the shift to digital driver licences. Once a digital licence becomes a primary credential, it must work everywhere, all the time. Offline, across jurisdictions, under enforcement, and in edge cases the designers never anticipated. A board does not care that the user experience is elegant if the system fails during a roadside stop, a disaster response, or a court proceeding. Reliability and accountability are non-negotiable.

Or take the current nationwide KYC and identity reforms in Australia. These are not digital initiatives. They are foundational trust infrastructures. When onboarding fails, payments stall, benefits are delayed, or fraud scales faster than control, the consequences are immediate. Bank boards are not reassured by good intentions. They want to know where authority sits, how decisions are enforced, and who is accountable when the system makes, or enables, a mistake.

In all of these cases, humans are involved, but critically, not because the system would otherwise fall apart. They are involved because judgement, discretion, and oversight are genuinely required at the edges. The core system is designed to stand on its own. Human involvement enhances it; it does not prop it up. That is the standard boards apply. Which is why this matters so much in AI discussions.

When AI-enabled systems are presented to boards with the reassurance that humans are in the loop, but without clarity on whether those humans are adding judgement or simply preventing failure, boards are being asked to underwrite risk without being shown the architecture. That is not how large-scale systems are governed. Boards understand the difference between human oversight and human dependency. One is a strength. The other is a liability. But the distinction is not always made explicit in how AI is presented to them. And at scale, that distinction is everything.

At scale, boards care less about intent than about exposure. When something goes wrong, they actively look for where control actually sat and who carried the consequences. If a system cannot function without humans, accountability does not sit with the technology, it sits with the people. And boards rarely tolerate hidden accountability.

Hidden accountability is risk. Diffuse accountability is risk. Implicit accountability is risk. This is why failing technology initiatives so often become personal at board level. Failure exposes whether control ever truly existed. Boards do not fund virtue. They fund capability, control, and outcomes.

On the factory or the trading floor, responsibility has very little to do with whether a system needs human intervention to function. Architecture does. And so this brings us to where platforms fundamentally break with ERP thinking.

A real platform is not defined by UI, licensing model, or cloud credentials. It is defined by where control lives. In a platform environment like ServiceNow, control is designed to live in the architecture, not in people’s heads or inboxes. Workflow is explicit, not implicit. State is durable. Authority is delegated, not implied. Policy is externalised from process. Integration is transactional and observable. The truth only lies at a modular level.

Every serious platform converges on the same capabilities, and notably, these are platform-as-a-service constructs, not ERP ones. Explicit workflow orchestration (e.g. Servicenow’s Flow Designer). Transactional integration (e.g. IntegrationHub). A trusted model of operational reality (e.g. CMDB). Enforceable policy and security controls. Not because vendors agree, but because autonomy demands that policy and decision logic exist so rules stop being folklore and start being code. Without these foundations, AI can reason, but it cannot be trusted to act.

These are not additional products or services to be included in an ERP roadmap. They are the structural foundations on which autonomy depends. And when they are absent or immature, humans must step in to compensate. Humans become the workflow engine. Humans become the integration layer. Humans become the permission model. Humans become the exception handler.

The real outcome is that humans in the loop has never been about man-machine collaboration. It’s a cover for unpaid architectural debt. And this is why so many early conversations about agentic AI have felt underwhelming.

The agent can look and sound intelligent. It can analyse, categorise, plan, and make suggestions. But when it comes time to act, it often can’t. The ERP-centric environment it lives in doesn’t give it real authority, clear boundaries, or end-to-end accountability. So the work stops at the screen. A human has to step in and finish the job. The demo looks impressive, but the client operating model underneath hasn’t actually changed.

For much of last year this was explained away as ethical restraint, and while it is true that reality is never black and white, in many cases, that language is masking a more uncomfortable truth. The architecture (of some solutions) and many organisations simply isn’t ready yet.

When presented to customers by a technology provider early in their AI maturity curve, human-in-the-loop is not a sign of wisdom. It’s a sign of platform limitation. Only later, when the system can operate reliably on its own, as it adopts more PaaS-centric models, does keeping humans in the loop become a genuine design choice, and a source of strength.

In immature environments, humans are in the loop mostly because the system cannot be trusted. In mature environments, humans are in the loop because their judgement is genuinely valuable. Those two states look identical on a governance slide whereas they could not be more different in reality. Most of the high-profile failures of 2025 sit squarely in that gap when organisations convinced themselves they were in the second state while still operating firmly in the first.

One means humans are propping up brittle systems or solutions. The other means humans are governing autonomous ones. Which brings me back to the beginning. The entire purpose of a platform is to enable the once in a generation transition wea re living through in real time.

This is not about removing humans. It never was. It is about relocating humans to where 21st-century organisations actually need them. Not as workflow glue. Not as integration buffers. Not as permission proxies. But as stewards of intent, ethics, accountability, and outcomes.

When platforms mature, humans move out of execution and into governance. They become orchestrators. They stop making the system work and start deciding how it should behave. That is also when AI stops being dangerous. Not because it is constrained, but because it can be contained by architectural design.

The opportunity is to move beyond an ERP-centric operating model, not to abandon ERP altogether. ERP isn’t going away. But it is being moved out of the centre, because organisations are now dealing with a genuine three-body problem between ERP, PaaS, and AI. Each exerts force on the others, and none can dominate without creating instability. ERP’s role is to remain a system of record, not the system of control. The centre of gravity is shifting toward platforms that can express intent, orchestrate work, and delegate authority across the estate, with AI operating inside those boundaries.

Regardless of which industry you operate in, crossing that threshold does not start with more AI. It starts with an honest reassessment of the operating model itself and a willingness to accept that the future of ERP is as a critical component of the value chain, but not its organising principle. That is not a loss of control. It is how control is regained for the next era and it should rewrite most procurements from this year forward.

Enterprise technology buyers are being told a comforting story. Artificial intelligence, we are assured, can be bought, licensed, and governed much like the systems that came before it. Enterprise licence agreements, flexible consumption pools, and familiar commercial constructs promise to make AI feel legible and safe. Salesforce’s Agentforce Enterprise Licence Agreement (AELA) is a good example of this intent. It is not a gimmick. It is a solid and sincere attempt to meet customers where they are.

The problem is not that these models are wrong. They are right for now. But that is also precisely the issue. They are transitional. They wrap a fundamentally different economic creature in the language of a world that no longer exists. Traditional total cost of ownership (TCO) was built for software that behaves like an asset. Agentic systems behave like labour. And that distinction matters more than any pricing model.

For decades, TCO has been an exercise in containment. Organisations estimated licence costs, infrastructure, integration, and support, then spread that cost across users or transactions. Performance improvements were welcomed because they reduced run costs. Efficiency meant savings. Usage broadly tracked value, and behaviour was bounded by human attention, working hours, and organisational friction. Agentic systems break every one of those assumptions. How and why?

An agent does not wait to be used. It acts. It retries. It escalates. It triggers other systems. It improves over time and continuously operates. Cost is no longer driven by access but by behaviour. In traditional systems, better performance was efficiency driven to reduce cost. Whereas in agentic systems, the more capable an agent becomes, the more it does. So better performance often increases use. This is where familiar TCO models quietly fail.

An organisation may deploy an agent to reduce case handling time, improve resolution rates, or increase customer satisfaction. All of those outcomes can be achieved. Yet the same improvements can also drive higher system interaction, greater orchestration complexity, more monitoring, and increased downstream activity. The agent becomes productive, but not necessarily cheap.

That creates the new TCO question. Are we paying for fewer actions or for better outcomes? The difficulty is that even this framing assumes a level of comparability that rarely exists. I’m sure the model enthusiasts reading along have already quietly objected to the efficiency argument.

But I agree. Two organisations can deploy the same agentic process, on the same platform, under the same commercial model, and experience materially different economics. One may operate with clean data, minimal workarounds, and low regulatory friction. Another may require multiple exception paths, manual validations, and heavy oversight. The agent performs the same “work,” but with very different efficiency, risk, and cost profiles. That doesn’t change the argument that traditional TCO has no way to account for this because it was designed to price systems, not organisational complexity.

This is why agentic cost benchmarking remains elusive. What looks like an AI efficiency problem is as much an operating-model problem in disguise. That is a management consulting problem and the result is the ensuing economic fog.

Customers want AI. Boards expect it. Executives feel pressure to adopt it. Yet few organisations truly understand how to model its long-term cost, let alone govern it. Everyone is struggling to determine whether to buy capacity, consumption, outcomes, or something in between. The language of tokens, actions, and autonomy feels abstract and risky.

To this point vendors have only been able to respond rationally. They have to offer what sounds safe and familiar. Enterprise licence agreements. Flex pools. Commitments that resemble what procurement teams already know how to approve. These constructs are not cynical. They are necessary bridges. They allow organisations to step into agentic territory without immediately confronting the fact that the ground rules have changed. But the ground rules have changed.

In many ways, this challenge should feel familiar. It is the same problem organisations have wrestled with for decades in business process outsourcing and managed services. Cost outcomes were never determined solely by the contract rate card. They were shaped by process maturity, regulatory burden, exception volume, and the level of oversight the organisation itself required. Two customers could outsource the same process and experience radically different economics. Agentic TCO brings that same reality into software.

At this point, it is important to be precise. Not every layer of an AI-enabled platform behaves the same economically. Foundational PaaS capabilities like workflow engines, data models, and integration layers can still be governed and amortised like traditional software assets. Their cost curves are familiar, and their value can be planned. The discontinuity appears at the point where agency is introduced. Once software is empowered to act, decide, and initiate work, cost becomes behaviour-driven rather than asset-based. This is why vendors are carving out separate commercial constructs for agentic capability. It is not an admission that platform pricing is broken, but an acknowledgement that agency cannot be priced in the same way as software.

Agentic TCO is not about ownership. It is about economic governance. It shifts the focus from controlling access to controlling autonomy, from budgeting per user to budgeting per action, and from minimising cost to constraining behaviour. That shifts the dominant cost drivers from licences and infrastructure to decision loops, orchestration logic, exception handling, guardrails, and oversight. These become operating costs, not implementation artefacts, and they tend to grow with success rather than diminish over time.

Let me beat my old drum again. This is why platform architecture matters. Agentic systems do not sit neatly inside application silos. They require a platform layer that can observe, govern, throttle, and evolve behaviour across systems. This is not an ERP problem. It is a platform-as-a-service problem. PaaS becomes the economic trunk through which agentic activity flows, whether organisations acknowledge it or not.

So what we are witnessing is a market in transition. Customers are being sold AI using commercial models designed to reduce anxiety, while vendors quietly pivot toward a future where agency, not software, is the unit of value. Enterprise agreements like Salesforce’s AELA are part of that necessary bridge. They help organisations begin the journey by uncapping some of that agency. But even they will admit that they do not yet resolve the underlying economic ambiguity at free agency scale. No one has.

The bottom line is that agentic AI cannot be priced and governed like software. It must be governed the way work is. And until organisations accept that shift, total cost of ownership will remain an estimate rather than an insight. Is it still worth pursuing? Absolutely! The shift is simply this. Where traditional TCO asked what a system costs to own, agentic TCO asks what it costs to let software act on your behalf.

I think we all get that part of the discomfort to this point comes from a reluctance to talk about AI taking jobs. Framed that way, the conversation becomes politically charged and emotionally loaded. In practice, agentic AI is not taking jobs. It is taking work. The tasks and decisions that were previously performed by people. That distinction matters, because work can be delegated, reallocated, and governed in ways that jobs cannot.

Agentic AI is not difficult to price because vendors lack models, but because enterprises have not yet accepted that they are buying delegated work rather than tools. So try reframing the way you are approaching those business cases. Everything else is just a negotiation over how long we pretend those two questions are the same.

Share

The Top 10 Questions to Start Costing Agentic AI

Costing agentic AI is not difficult because the technology is new, or because vendors lack pricing models. It is difficult because organisations are trying to apply asset-based thinking to something that behaves like delegated work.

Traditional TCO models assume comparability, predictability, and efficiency gains that reduce cost over time. Agentic systems violate those assumptions. Their costs are shaped as much by organisational complexity, governance choices, and operating discipline as by software consumption itself.

The questions below are not designed to produce a perfect number. They are designed to surface where agentic AI will behave unlike traditional software, where costs will scale with success, and where economic exposure is likely to appear. Without answering them, any TCO model will be incomplete, regardless of how familiar the commercial wrapper looks.

They focus on the agentic (probablistic and variable) layer of the platform, not the underlying PaaS foundations, which can still be governed and amortised using traditional asset-based TCO models. They are based on the premises that you can’t cost what you can’t see, you can’t budget what you can’t limit, and you can’t govern delegated work without ownership.

At scale, organisations are likely to require a control layer that can observe, constrain, and govern agentic behaviour across systems. Such control mechanisms should not be viewed as a product trend, but as a structural response to the economic realities of delegated work operating at machine scale.

Read more

Globalisation is a relatively recent phenomenon. And in the early 2000s, something subtle but consequential began to unfold inside Western organisations. Standing in line for coffee in the Sydney CBD, shoulder to shoulder with the bankers of George Street and Martin Place, it was easy to assume that everything was working as designed. The offices were full. The deals were flowing. The machinery of capitalism looked solid.

But what began as a quiet experiment in cost reduction soon exposed a far deeper truth. When organisations attempted to move work beyond their walls, they discovered they didn’t actually understand how that work got done. Processes lived in people’s heads. Decisions relied on proximity. Exceptions were handled by habit rather than design. Basically, the first wave of globalisation forced organisations to confront the fact that they didn’t truly know themselves.

Business Process Outsourcing and Offshoring was supposed to be about labour arbitrage. Lower wages. Time zone leverage and scale. Large banks were among the earliest adopters, not out of experimentation but necessity. When margins are defended at the second decimal place and operational efficiency compounds at scale, even small reductions in unit cost become strategically meaningful.

What it became instead was a forced confrontation with organisational reality. Processes that lived in people’s heads had to be written down. Exceptions had to be named. Decisions had to be justified. Handoffs had to be explained to someone who wasn’t sitting three desks away. And for a while, progress was slow. Painfully slow.

Executives underestimated the sheer volume of documentation required. BPM diagrams multiplied. SOPs sprawled. Edge cases turned out to be the rule rather than the exception. And there was a deeper discomfort too. Not just with process discipline, but with trust. Trusting distant teams. Trusting unfamiliar cultures. Trusting companies most leaders had never even heard of.

Even as late as 2005-06, there was still a surprising lack of clarity about what was unfolding. At IBM’s Australia–New Zealand Sales Kick-Off on the Gold Coast, I was asked to stand in front of more than 300 sales and account executives and explain who the “Indian outsourcers” were and why they mattered. But then, almost without warning, the floodgates opened.

Once processes were explicit, portable, and measurable, they stopped being local. Work that had once been anchored to physical offices began to flow. Entire delivery models shifted. Cities like Bangalore, Pune, and Hyderabad didn’t rise because of cheap labour alone. They rose because execution itself had become transportable.

The result was profound. A generation of global technology firms emerged. Economies rebalanced. New talent ecosystems formed. The centre of gravity shifted and it never fully shifted back.

I saw that transition up close. In 2004, I travelled to Manila to close the local META Group office near Makati City. At the time, Bonifacio Global City literally did not exist. Other than in developer brochures. The land between Makati and the old military reservation was sparse, quiet, and largely undeveloped. It was a place passed by, not a place you went to.

Less than a decade later, that same ground was unrecognisable. Where there had been open land, there were now dense clusters of glass and steel high-rise offices, residential towers, and global delivery centres operating around the clock. Bonifacio had become a city in its own right and one of Asia’s most important hubs for global outsourced execution. That is the scale of change BPO set in motion.

I’ve been thinking a lot about that period lately and am increasingly convinced that while the delivery platform has changed, we are otherwise watching the same tectonic shift occur all over again.

Last time, the logic of optimisation drove execution to the only places where cheap labour at scale still existed, and entire cities rose to serve that demand. This time, the same logic applies, but the city won’t be physical.

Agentic AI is currently in its “this looks promising but feels messy” phase. A lot of early pilots have stalled. Proofs of concept have struggled to scale. Leaders have complained that the tools are impressive but unreliable. Teams have quietly discovered that their processes aren’t nearly as clean as they thought they were. Decisions that felt obvious have turned out to be contextual. Exceptions have exploded.

I think the disconnect is less about technology and more about readiness. Many vendors are aggressively marketing Level 5–6 agentic capabilities to organisations that are still struggling to define their Level 1–2 foundations. The result is that sales and delivery organisations end up aligned to the pace of marketing rather than the maturity of the customer. And while the two can coexist, operations cannot move at the speed of marketing. That was never the intent.

But this hasn’t been a failure of AI. It’s exactly the same organisational reckoning we saw during the first BPO and offshoring wave. In the same way that you can’t outsource chaos, you can’t delegate incoherence to an agent.

Before anything meaningful can happen, work has to be made legible. Inputs defined. Outcomes bounded. Authority clarified. Escalation paths designed. Controls articulated. Metrics agreed. The real work, once again, isn’t automation. It’s self-knowledge. That’s something we’re all impatient for.

That’s why progress feels slower than the headlines suggest. The technology has been ahead of the organisations adopting it. Exactly as it was twenty years ago. But history suggests this phase doesn’t last forever.

That was the hidden force behind offshoring. Documentation didn’t just enable delivery. It shifted the centre of execution. Once work could move, it did. Talent followed. Capital followed. Capability clustered.

Agentic AI creates the same condition, but with a far more radical implication. Execution itself is becoming abstract. That is not hyperbolic. Let’s ponder that for a minute. Agents literally don’t sit in buildings. They don’t sleep. They don’t resign. They don’t require visas or commute times. They consume tokens, operate within guardrails, and escalate when designed to do so. They can also be insourced, outsourced, federated, shared, or rented. Geography becomes optional. Time becomes elastic.

But this is also where the analogy with BPO stops being clever and starts being uncomfortable. In the 2000s, organisations had to decide whether to build captive centres offshore or outsource to third parties. Some did both.

Today, the choice reappears in a new form. Do you run agents internally, tightly coupled to your data, architecture, and governance? Or do you consume agentic capacity as a service, trusting external platforms to execute parts of your organisation on your behalf? If the decision feels tactical, that is a mistake. It isn’t. Because just as before, the early choices will harden into operating models that last decades.

Contemporary BPO cities and offshore delivery hubs came into existence because of density. Skills, services, capital, and coordination concentrated until something self-reinforcing emerged. Once enough capability clustered, those cities stopped being back offices and began to function as innovation engines.

Over time, some went further still. As talent deepened and decision-making followed execution, these centres began to assume strategic importance, shaping roadmaps, influencing investment, and increasingly determining where growth would come from. What started as delivery hubs evolved into centres of gravity in their own right. We’re seeing this occur today in the way large global technology vendors are balancing India as a strategic execution and innovation centre, with Singapore increasingly acting as a regional coordination and administrative hub.

Agentic ecosystems are already showing the same tendencies. Common agent frameworks. Shared orchestration layers. Specialised agent roles. Reusable process patterns. Governance primitives. Observability tooling. Token optimisation. Cost-to-serve models. These are the streets, utilities, and institutions of a new kind of city.

It won’t have a skyline. It won’t appear on a map. But it will concentrate execution, capability, and influence in ways that are no less real for being invisible. We’re already seeing early versions of this in the wild. Platforms like ServiceNow describe it as a control tower. The place where work, agents, workflows, and decisions are orchestrated rather than directly executed. Accenture talks about agent-led delivery factories embedded inside client operating models. IBM, drawing on decades of systems integration and automation, frames it as cognitive operations.

The language differs, but the struggle is the same. That is, to become the de facto regulatory authority for digital workforces setting the rules, enforcing the controls, and deciding how autonomous execution is allowed to become.

Digital agentic cities won’t live entirely in the cloud or inside legacy systems. They will span them coordinating execution across environments that were never designed to be seen as a single place. For that to work, they must be interoperable by design and capable of managing multiple digital labour forces within a single, regulated operating environment. Not one workforce, not one platform, but many (human, automated, and agentic) governed together inside the complexity of a contemporary enterprise.

Organisations that align themselves early will find execution cheaper, faster, and more adaptable. Those that don’t will struggle to compete with firms whose workforce can scale at machine speed. The uncomfortable truth is that these cities are being built regardless, and without a central authority, what emerges isn’t innovation, but sprawl.

Share

Much of the public debate about AI has to this point fixated on human displacement. That’s understandable, but I also think it misses the deeper pattern.

BPO didn’t eliminate work. It reorganised it. Yes, it did hollow out organisations that couldn’t define themselves clearly but it also elevated those that could orchestrate complexity across distance. Agentic AI will do the same.

It will punish organisations that rely on tacit knowledge, heroics, and informal coordination. It will expose unclear decision rights. It will surface governance gaps that have been tolerated for years. It will make ambiguity very expensive. But it will also reward those that understand their own architecture, both technical and organisational.

This is why AI strategies that start with tools and finish with dashboards feel fundamentally incomplete. The challenge isn’t intelligence or automation. It’s whether an organisation can describe itself clearly enough to be executed by something other than habit. That’s why this is a leadership moment. CEOs don’t need to understand AI, but they absolutely need to understand the organisational consequences of deploying it.

What is undeniable is that the offshoring boom reshaped global technology dominance because it changed where execution lived. Agentic AI will reshape it again by changing what execution is.

The slow burn we’re seeing now, the frustration, the false starts, the documentation fatigue, is not a sign that this moment is overhyped. It’s a sign that we’re still early. Confidence should come though from the knowledge we have lived through it before. And we came out stronger. For those early in their careers, that means experiencing a period of uncertainty where the rules are shifting faster than the narratives explaining them. Because the very shape of work is changing underneath us all.

But once the legibility problem is solved at scale, and once agents become trusted participants in organisational workflows rather than novelties, the shift will feel sudden. It always does. And by the time it’s obvious to everyone, the agentic city will already exist.

And perhaps that is the quiet unease sitting underneath all of this. Not that we are entering a simulation, but that we are finally seeing how simulated our organisations already were. Roles, approvals, escalation paths, and incentives are all abstractions we agreed to treat as real because humans were inside them.

Agentic AI doesn’t invent a new world. It just removes the camouflage that humna-in-the-loop has always provided. And when execution no longer requires presence, belief, or habit, what remains is structure. Some organisations will recognise themselves in that reflection. Others will discover that what they thought was a living system was mostly theatre.

The city of digital agents will keep growing either way. The only real questions left will be who will govern it, whether you helped build it, and whether your work quietly moved there without you.

Above all else, there is a quiet irony here. The captive centres and offshore providers that industrialised execution during the BPO era are likely to be among the first organisations forced to confront an agentic future. I don’t think it is a case that what made them indispensable last time makes them replaceable first this time.

Rather, after spending two decades breaking human work into repeatable systems and delivering it at scale, it is that they now find themselves confronting the same optimisation logic they once helped their clients apply, only this time where that same work can be executed by something else entirely.

For them, the change may be as great, where the implications of agentic execution are not theoretical. They are immediate, unavoidable, and impossible to ignore. Paid subscribers can read on for a closer look at the ten Australian organisations and five technology vendors I’ll be watching in 2026 as they shape the early contours of the agentic decade.

Read more

When a council hears that a new AI capability carries a licence fee of around $100,000 per year, the instinctive reaction is predictable. Is it affordable? Is it necessary? Is it defensible to ratepayers? Those questions are understandable. But they are also the wrong place to start.

In the Australian local government context, scale matters but it must be properly defined. That is because population size, service complexity, and rate base do not move in lockstep. A council with a population of 20,000 might reasonably be described as a city whereas a council with 20,000 rateable properties might not. But it may still be a significant regional centre, a fast-growing fringe council, or a large rural authority managing a dispersed population across a wide geography.

This distinction matters because councils are funded per property, while services are experienced by people. AI value sits somewhere between the two. When those measures are blurred, cost conversations drift and hesitation becomes sticky. It is also why vendors price by organisational scale. It is not out of generosity, but because the underlying economics demand it.

So before debating AI investment as “a lot of money,” the math needs to be normalised (all cost debates drift unless they’re normalised properly). Using $100,000 as a reference point shows how quickly per-property cost collapses as scale increases, regardless of whether pricing is flat or tiered.

Share

At this point, it is also important to place these numbers in the further context of existing tech investments.

Councils already accept a per-rateable-property cost for their core ERP platforms, typically somewhere in the range of $15 to $45 per property per year, depending on scale, module mix, and contractual structure. That cost is rarely debated in isolation because, after decades, the ERP is understood to be foundational. Against that baseline, an additional AI capability priced at around $100,000 per year looks very different.

At approximately 10,000 rateable properties, it adds around $10 per property per year on top of the existing ERP cost. By 15,000 properties, that incremental figure drops to around $6.70. At 20,000, it settles at $5. Beyond that, the marginal impact becomes progressively smaller. Approximately $3.30 per property at 30,000, $2.50 at 40,000, and around $2 per year for councils with 50,000 rateable properties.

Viewed this way, the question is no longer whether $10 per property is “a lot of money” in absolute terms. For some councils, it may represent a modest uplift on an already high ERP cost base. While for others, it could be a material increase of 25 per cent, 50 per cent, or even more. That variability matters and should not be ignored. The real question, however, is whether an incremental uplift of that order, relative to an already-accepted ERP baseline, can deliver measurable improvements in how work flows through the organisation and how residents experience council services. Framed properly, this becomes a value and design question, not a headline pricing debate.

This is precisely why vendors price by scale. Once costs are normalised in this way, the headline pricing debate largely dissolves. Even allowing for tiered models, the per-property burden quickly falls into single-digit dollars and, for larger councils, into background noise. At that point, the question is no longer affordability, but whether councils can extract even modest, repeatable value from the way work actually flows through the organisation.

And this is where the conversation often goes off course. While the per-property cost diminishes with scale, the underlying workload does not. Customer requests, regulatory enquiries, correspondence, and service follow-ups do not shrink in proportion to the rate base. In many cases, they grow faster. So while the cost becomes less visible, the operational pressure increases, and it is this mismatch that AI is meant to address.

AI is too often justified through internal productivity narratives. Faster drafting. Better summaries. Reduced administration. For example, HR efficiency is frequently positioned as a lead use case because it is familiar, controllable, and politically safe. There is nothing inherently wrong with this. In fact, under a PaaS-driven architecture, a reimagined corporate services model can deliver significant organisational value through better decision support, reduced friction, clearer accountability, and materially improved cost-to-serve across the enterprise. The problem arises when internal efficiency is presented as the primary value story for a rates-funded organisation.

While HR, finance, and corporate services matter enormously to how a council functions, they are not how residents experience council. Residents experience response times, clarity, follow-through, and consistency. When AI is justified almost exclusively through back-office gains, the connection between investment and community value becomes abstract, and the political-buyer argument weakens.

This is not a critique of corporate services transformation. It is simply a sequencing issue. Internal AI gains are real and important, but in a public-sector context they cannot carry the whole case on their own. The strongest AI strategies are those that improve internal capability and deliberately translate that capability into frontline service outcomes residents can see and feel. That is, where it is tied to the services P&L. If AI is going to earn its keep in a rates-funded environment, it must be applied where residents actually feel friction.

The highest-return workflows are also not sophisticated. They are the relentless “are we there yet?” pleas from the back seat. AI earns its keep not by inventing new destinations, but by giving everyone (staff and customers) a clear view of the journey. You know the questions:

“Where is my request up to?”
“Who is responsible for this?”
“What happens next?”
“Why did I receive this notice?”
“How long will this take?”

These questions generate enormous effort not because they are complex, but because they recur thousands of times a year across customer service, rates, planning, compliance, waste, roads, and facilities.

At that scale, small efficiency gains compound quickly. So saving thirty seconds per interaction across live, resident-facing workflows produces a return that dwarfs the original licence cost even at the smallest end of the scale. A three-to-five-times return is not ambitious. It is conservative. Yet many councils hesitate precisely here.

Instead of embedding AI into frontline workflows, there is comfort in quarantining it in the back office. Piloted in HR. Restricted to internal drafting. Treated as a novelty rather than an operational capability, twelve months later the conclusion quietly emerges that the value was unclear. The value was not unclear. The application was timid.

AI does not create value by existing. Like a financial derivative, it only generates value when it is anchored to an underlying asset. In this case, live workflows where volume and repetition provide the leverage.

Customer service. Request management. Rates and property enquiries. Regulatory correspondence. Field service updates translated into resident-ready language. These are the domains where AI will invisibly earn its licence investment many times over.

I think there is also a “sweet spot” where AI becomes almost impossible to argue against in local government. Somewhere between 15,000 and 40,000 rateable properties, the per-property cost drops low enough that the burden disappears, while service complexity remains high enough for compounding returns to take hold. That is a meaningful slice of the overall sector. At that point, the risk is no longer financial. It is organisational.

The uncomfortable truth is that at $5, or even $10, per property per year, AI does not need to be transformational to be worthwhile. It just needs to be used. Which is why the real AI question for councils is not “can we afford it?” but “are we prepared to change how work flows through the organisation?” In my experience, that is often a hard no (for reasons I’ve explore before). When the answer is no, no licence price will ever make sense. If the answer is yes, the return will arrive long before the debate finishes.

In the end, AI is not testing council budgets. It is testing council confidence. Confidence to stop hiding behind internal efficiency stories. Confidence to apply capability where residents actually notice. Confidence to accept that the real risk is not spending a few dollars per property, but failing to extract even modest value from it. That is the cost problem local government actually needs to confront.

What’s also worth being explicit about is this. Everything above is the business case and the strategic positioning for AI in the sector. AI belongs squarely in every council’s five-year technology and service roadmap.

This precedes demo theatre and product selection and any vendor comparison exercise. The strategy is actually straightforward. AI must be deliberately applied to high-volume, resident-facing workflows where small reductions in effort compound quickly over time, and where the value is felt directly by the community rather than disappearing invisibly inside the organisation.

Framed this way, AI is not a discretionary experiment or a short-term initiative. It is a structural capability that can be planned, sequenced, and embedded alongside other long-term service and platform decisions. And, unlike ERP projects, in relatively fast time.

Once the cost drops to a few dollars per rateable property per year, the strategic question is no longer financial. It becomes organisational and architectural. The issue is no longer whether council can afford AI, but whether it is prepared to redefine what “the system” actually is (for the next 5- or 10-year investment cycle). What is clear is that the system is no longer the ERP alone. It is the broader architectural framework through which work flows incorporating core transactional platforms, PaaS capabilities, integration layers, data, and now AI as a native component rather than an add-on.

So the real question, then, is whether council is willing to deliberately change how work moves through that system, rather than simply bolting new capability onto old pathways. That is the strategy and it has never been clearer in over a decade. Everything else is execution, including the discussion about whether any given AI product can actually do these things well. Some can, very well. Others simply claim and obfuscate.

That’s where we left things in 2025.

There was a growing tendency in the market to blur these two conversations. Councils were told that because the business case made sense, the product must therefore be fit for purpose. That leap is dangerous and fed the hesitation and anxiety we also saw. Establishing that AI should be applied to certain workflows is a strategy decision. Determining whether a specific solution can support those workflows, with acceptable accuracy, governance, integration, security, and operational maturity, is a product and architecture assessment.

Confusing the two simply leads to justified purchases, weak adoption, and quiet disappointment. So be clear-eyed about the sequence. First define where AI must create value. Then test whether the technology can actually deliver it in those places. Strategy before tooling, not the other way around.

For paid subscribers, I’ve outlined 20 representative workflows where AI can quickly earn its keep in local government. If you’re trying to assess which technical solutions can genuinely support this level of capability in practice, rather than simply claiming to, I’m always open to a conversation.

And if you’re doing that assessment yourself, the test is straightforward. If an AI solution whether a point capability or a platform in its own right cannot be embedded into a material subset of these workflows, the issue was never price. It is relevance. If it can, then the original question of whether $100,000 is “a lot of money” becomes almost impossible to sustain.

A brief clarification: I’m well aware there are AI offerings in the local government market priced well below and well above this level, and I expect the inevitable “ours is much cheaper” responses. That is a different conversation. At that point, the question shifts from cost to architecture and specifically whether a tool is a point solution or a platform capable of supporting AI at scale across the organisation over time. That distinction matters far more than the headline price, which I’ve used here simply as an indicative benchmark to unpack the broader argument.

Read more

2026 is not the year of AI adoption. It is the year organisations start treating platforms as minimum viable operating systems for work. That reframing explains why 2026 represents a more consequential year for ServiceNow than 2025. Not because anything is accelerating, but because the platform’s role is now clear.

In 2025, AI was widely used to rationalise ServiceNow’s acquisitions, software contract evolution, and platform expansion. In reality, AI was not the objective. It was the forcing function. What mattered most was that, under that pressure, ServiceNow continued to complete the foundational capabilities required for autonomous execution. That is, the foundations required to act.

In practical terms, AI did not clarify ServiceNow’s role. Platform coherence did. The ability to translate AI potential into operational reality requires a level of platform maturity that few enterprise vendors have reached.

ServiceNow’s 2025 acquisitions and platform investments followed a consistent and deliberate logic. Capabilities such as data.world strengthened data context so decisions could be grounded in trusted information. Veza extended identity authority so actions could be taken safely and with clear permissioning. Moveworks established a natural enterprise entry point, allowing work to flow into the platform without friction. Armis expanded visibility into exposure and risk so automation could be corrected in motion rather than after the fact. Together with workflow intelligence embedded across the platform, these moves allowed ServiceNow to understand what actually happens in the enterprise, not just what process diagrams suggest should happen.

None of this was about adding features. It was about closing the gaps that required humans to stay in the loop. Human-in-the-loop is frequently presented as a safety measure, but in most environments it reflects the limits of platform maturity. Where systems lack reliable data, consistent workflow logic, clear authority, and enforceable policy, human oversight is not a choice. It is a workaround.

By the end of 2025, those gaps have been underpinned. And what has now emerged is not simply a broader platform, but something more specific. A benchmark for a minimum viable operating system for execution and governance. Whether you are talking about the NOW platform itself, or elements like Control Tower, or even lesser functional solutions, the execution and governance narrative is consistent and strong.

With that in place, this is where platform licence tiering needs to be understood differently by contemporary enterprise buyers.

For many years, tiers have been interpreted primarily as commercial packaging. Higher costs exchanged for more modules, more functionality, and a broader set of use cases. That framing made sense when the platform behaved largely as a collection of applications.

But moving forward, licence tiers will describe something far more fundamental. They will define the minimum operating baseline required for the platform to function as a coherent system.

Identity, core workflow, trusted data context, policy enforcement, and observability will no longer be optional capabilities. They will be the pre-conditions that must be in place before automation can be relied upon to safely act with consistency. Seen through this lens, higher tiers do not simply add capability. They actually expand delegated authority. Those that work in highly regulated industries know just how consequential the concept of “expanded delegated authority” is. It is everything.

In the context of the PaaS market, forget technology for a second. Expanded delegated authority widens the scope within which the platform is permitted to execute work autonomously. It allows activity to move across more organisational domains without constant human supervision. It enables the platform to act, not merely recommend.

So what organisations are really choosing at each tier is not how much software they want to license, but how much execution they are prepared to delegate. That is a very different commercial conversation, and a far more productive one, because it shifts the discussion from software cost to outsourced business value, where financial return can be more honestly assessed by the non-technical buyers that prolifierate in today’s large enterprises.

That is why ServiceNow’s playbook essentially becomes a platform benchmark. As clarity emerges, conversations change.

Sales discussions can move beyond individual use cases and start addressing operating posture. Procurement conversations can shift from SKU optimisation to entitlement boundaries. Executives can stop asking whether ServiceNow can automate and begin asking where it should be allowed to do so without oversight. It is great for service partners too. Because those are not incremental changes in messaging. They are structural changes in how the platform is understood and discussed right across the SI and BPO supply chain.

Seen through this lens, ServiceNow’s evolution reflects a decisive shift toward coherence rather than scope. In platform-as-a-service markets, there is a maturity threshold that must be crossed before a platform can function as a true enterprise control loop for work execution. Having crossed that threshold last year, ServiceNow can approach its 2026 SKO without the need for its sales organisation to improvise within abstract AI or CRM narratives. Instead, it can present a coherent operating story in which the pieces already fit together.

The fact that this interpretation was not broadly accessible a year ago reflects less a failure of perception than a matter of timing. The platform had not yet reached the level of consolidation required for its operating role to be clearly visible or practically defensible. And AI was a massive, albeit important, distraction.

What that means for 2026 is less hype because there is less ambiguity. Less fascination with what AI might do and more clarity about what the platform is ready to take responsibility for. Less experimentation for its own sake and more deliberate standardisation. That is not stagnation. It is maturity.

It is about helping the customer organisations to recognise that they are no longer licensing workflows. They are licensing some level of a minimum viable operating system for execution, and then deciding, deliberately, how much authority that system should hold.

It is worth repeating that I don’t think that AI made ServiceNow clearer. Building out the platform did. And only once the platform reached sufficient coherence did AI become usable rather than speculative.

The irony, of course, is that this clarity was achieved not by shrinking the application landscape, but by expanding the platform until consolidation could finally occur within it. That is why consolidation now re-enters the conversation in 2026, not as an aspiration, but as a practical next step for both PaaS and AI.

Local government never wrote a strategy that said the ERP should define the entire technology environment. It happened quietly. Councils bought whole-of-council systems because they wanted a single suite to run finance, property, rating, regulatory and revenue. That decision made operational sense at the time. The problem is what came next. The idea drifted. A business consolidation decision turned into a whole-of-IT mindset. Over time the ERP stopped being one system among many. It became the architectural centre of gravity.

This shift was never really debated in public. We just talked about it amongst ourselves. Then it started to show up through procurement templates, and longer vendor relationships and a slow narrowing of the IT function’s ambition. Corporate Services took over decisions. The ERP suite became the defcto strategy. The vendor became the advisor. The integration partner became a rarely executed option. The IT department became a support unit for a product rather than a steward of enterprise technology.

The net result is that councils did not outsource IT. They just behaved as if they had. Without the contracts or governance that proper outsourcing requires.

That’s how today’s ERP vendors gained such strategic power in the sector. It was a power they were never designed to hold. Their products have since shaped decisions about infrastructure, integration, cybersecurity, data governance and customer service.

Many IT service providers faded into the background. Councils forgot why they needed them. Integration engineering, platform orchestration and data architecture are not functions ERP vendors ever performed well. They were not required to. And the councils simply stopped demanding those skills.

This legacy sits at the heart of the current digital transformation struggle.

Councils are trying to build modern platforms on top of an old worldview and years of underinvestment in some of the skills and services of core IT. Yes, they are adopting Microsoft cloud, Salesforce service layers, ServiceNow orchestration and API-driven ecosystems. But they are still thinking of IT as an ERP extension. The gap between the world where most organisations are headed, and the model councils have inherited is now too large to ignore.

In the changes we are seeing, it is not that a new group of vendors has appeared. They have been here the whole time. What has shifted is the way councils are (re)looking at them.

Once the old ERP worldview starts to fall away, the market becomes easier to understand. The same brands fall into different places when viewed through an architectural lens rather than a product lens.

In Forrester Wave or Gartner Magic Quadrant terms, the market itself is not new. The classification scheme is. This reclassification signals a deeper shift in thinking. Councils are beginning to see technology as an ecosystem that needs orchestration rather than a single system that needs administration.

The picture becomes clearer once the lens shifts. You can see which vendors operate across the full stack (Transformation Partners), which remain tied to the traditional ERP model (ERP), and which offer a modern cloud alternative (Challengers). And with this different perspective comes a different understanding of where each one fits in the future of local government technology.

1. The first group, Trasformation Partners, really sit in a different part of the market. They are not defined by an ERP suite, even where they may offer one. They are system integrators that bring software capability into the transformation process and can operate as long-term technology partners rather than suite providers. Datacom, Oracle and Fujitsu sit in this category, alongside others such as Deloitte and KPMG who work in similar roles. In some cases, including Datacom, this group may also carry a local government ERP product, but the software does not anchor their market position. Architecture does. And while longevity exists across all three categories in local government, it signals something different here. ERP vendors endure because they are embedded and often own the transactions. Challengers endure by remaining relevant within a defined scope. Transformation Partners endure by supporting thier clients to survive change. They do this by working across applications, platforms, cloud infrastructure, integration and managed services. Their performance is also revealed over time, rather than at the point of sale. They are exposed to shifting architectures, changing vendors and evolving operating models. Their continued presence depends on their ability to adapt rather than their ability to lock in. That distinction matters in a market that is now organising itself around ecosystems rather than suites.

2. The second group still represents the ERP worldview that shaped local government for the last generation. TechnologyOne. Civica. Infor. Their approach was built for a period when the safest answer was to consolidate everything into one suite and manage one primary relationship. That made sense when councils wanted stability rather than knowing they need more architectural flexibility. It solved the problems of its time. But it also set the boundaries of how councils understood technology and what they were prepared to tolerate. These products were never designed for an environment defined by integration, orchestration or data flow across many platforms and they have usually been sold to executive roles, not IT buyers. They remain strong incumbents because they are the foundational systems of record for so many councils. They simply hold a position that reflects an earlier period in the sector’s digital development. When councils continue to centre their strategy around these suites they often recreate the old world inside the new one. The technology changes but the operating model does not. The result is a modern interface wrapped around a legacy mindset. They are still very important, in context.

3. The third group contains the modern challengers like MAGIQ and CouncilFirst. They sit outside the old ERP tradition but they are not system integrators either. Their value comes from offering councils a more contemporary business system footprint without requiring a shift into the scale and complexity of global platform ecosystems. MAGIQ’s current suite reflects a long period of rebuilding and reinvestment after the acquisition of several legacy products. The portfolio today is more cloud aligned and more extensible than it once was, but that position has been achieved through patient redevelopment rather than a single clean build. CouncilFirst, by contrast, enters the market with a clearer cloud starting point and a tighter architectural story. Both give councils a way to modernise and reduce dependency on traditional ERP suites, though they arrive at that outcome through different paths. They fill the space between the legacy worldview and the broader transformation models now taking shape. These vendors don’t claim to be PaaS providers like Salesforce and Servicenow, and that clarity helps them at this point. They focus specifically on the functional needs of local government and build contemporary on-demand products, with on-demand user licensing for those needs. They offer councils a way to break long dependencies on legacy suites without forcing a shift to enterprise platforms before they are ready. They fill the space between the old ERP worldview and the broader transformation models now taking shape.

| Vendor Group | Examples | Role in Architecture

| Transformation | Datacom, Oracle, Fujitsu | Full-stack, integration, platform

| ERP Vendors | T1, Civica, Infor | Traditional system of record

| Cloud Challengers | MAGIQ, CouncilFirst | Modular capable SaaS

This is where I think one vendor currently sits awkwardly between the groups. ReadyTech has acquired its way into a position that defies simple classification. Today, it is not a traditional ERP provider in the mold of TechnologyOne or Civica. Today, it does not hold the systems integration capability or architectural breadth of Datacom, Fujitsu or Oracle. Today, it is not a clean cloud SaaS challenger like CouncilFirst or Magiq. Today, it carries legacy from earlier products and the portfolio is too new to yet form a clear architectural story.

The result is a stack that appeals to some smaller councils yet lacks the cohesion needed for a modern platform strategy. This is a question of identity. Councils are beginning to choose ecosystems rather than collections of applications, and vendors without a defined position in that ecosystem find themselves harder to place.

ReadyTech sits in that unresolved space at a time when the market is actually becoming more structured and more segmented. Councils are moving into models that expect clear roles inside a broader architecture. ERP vendors cannot stretch into platform orchestration. Platform operators cannot shrink into ERP logic. Challengers cannot carry inherited complexity. So ReadyTech’s challenge is not capability, nor investment potential. It is alignment with the shape the sector is now taking.

This new framing also exposes the myth at the centre of the whole-of-council idea. The 20th century ERP-centric worldview created the illusion that the software provider was the natural owner of the technology agenda. It was never true.

The rise of PaaS and low-code platforms has made that illusion impossible to sustain. Integration matters now. Data pipelines matter. Identity matters. Interoperability matters. Service design matters. None of these sit inside a single ERP. They sit across many systems and require coordination by skilled partners.

This is why the Transformation Partner companies sit more naturally in the architectural direction councils are beginning to pursue. Their work spans several layers of the technology stack, so they occupy positions that fit the broader patterns now taking shape.

Councils have to move toward operating models that depend on several partners working within one strategy rather than a single product holding everything together. Don’t agree? Then how does the expanding application footprint make this unavoidable?

SaaS has made it easier to adopt new tools and the result is a larger and more complex environment than the old whole-of-council model ever anticipated. The irony is that this was always the logical destination. The sector grew its way into an ecosystem. It is only now beginning to see that it needs an ecosystem approach to manage it.

And this is the key point that starts to shape the path forward.

Local government simply avoided formal outsourcing while also growing dependent on ERP vendors in a way that resembled it. The difference today is that councils are starting to see the actual structure of their environment. They can now see the roles different companies play across the ecosystem rather than through the narrow lens of a single suite.

I am obviously only calling out a subset of vendors here. The focus is on those that sit at the centre of the whole-of-council market because they have shaped the way councils think about technology for more than a generation.

The broader ecosystem is much larger of course. Finance tools, planning systems, asset management platforms, CMS and CRM products, spatial solutions, rating management, governance applications and specialised tools like parking enforcement all play important roles in the digital environment of local government. They matter. They influence architecture. They carry operational weight. They simply sit outside the specific question this article is trying to resolve which is how the core vendors have been understood and how that understanding will continue to shift in the years ahead.

It also underscores just how razor thin the whole-of-council narrative has been, yet how effectively it has shaped the core of thinking across the sector. The simplicity of that message carried extraordinary influence. It pushed councils toward a worldview where one system was expected to hold the centre of everything. It is baffling in hindsight yet also a reminder of the strength of the marketing that sustained it. TechnologyOne’s communication of that idea has been truly world class and the sector has willingly carried it forward for decades.

So where to? Well i think the real question is not which vendors win the next round of procurement but whether councils will update the mental models that guide their choices. Strategic architecture is no longer optional. The technology landscape has already moved beyond the old worldview. Councils can move with it or carry the same untested assumptions into a new era.

Of course it will be a mix of both. But no sector, including local government, can stand still while enterprise application technology is shifting under its feet. The only choice is whether the shift is conscious or accidental.

Either way, 2026 is going to be a big year! And I look forward to working with many of you again. For my paid subscribers focused on local government tech procurement, read on to unpack why whole-of-council ERP RFTs no longer fit the market, and get in touch if you need some help.

Read more

The local-government ERP market across Australia and New Zealand is much larger and more diverse than it appears at first glance. Across the two countries, more than six hundred councils operate with wildly different scales and technology needs. The top hundred are substantial organisations in their own right. These are large, complex technology consumers with multi-million-dollar systems and dedicated internal capability.

But beyond that top tier lies the overwhelming majority of the market. These are the SMEs of local government. These are the regional, rural and remote councils with small teams, tight budgets and limited capacity for disruption. And it is this long tail, rather than the metropolitan giants, that has shaped the character and behaviour of the ERP market for decades.

At this level, the ERP landscape has existed in a kind of quiet equilibrium, shaped less by strategy than by inertia. Nothing moved quickly, nothing broke loudly, and most councils simply stayed with the systems they had because staying put for under a hundred thousand dollars a year felt easier than confronting the cost, risk and complexity of change.

Vendors servicing this end of the market didn’t push too hard because they didn’t have the resources. And the idea of a regional tender cycle was as unlikely as a sudden population boom in the Nullarbor. Everyone simply lived with what they had, and while what they had was rarely good enough, it was predictable.

ReadyTech shattered that equilibrium.

What began as a confident consolidation play has become one of the most consequential market disruptions the sector has seen in years. Not because they set out to create disruption (though of course it did that), but because the act of trying to lock the market down has ended up stirring it awake.

Consolidation is usually intended to bring order, clarity and growth. It’s the kind of move that’s meant to settle a market, not stir it. But in this case, the immediate effect has been the opposite. Instead of settling, the market has begun to move. Once that happens, it rarely does it quietly. It’s a tight knit sector, and a re-evaluation that begins in one region quickly becomes a conversation across many, and the ripple effects take on a life of their own.

Share

The long tail of Australian local government which includes the shires, the regions, and the remote authorities working with minimal staff and maximal expectations, spent years inside systems like SynergySoft, Open Office, CouncilWise (PropertyWise) and the rest of the small-vendor constellation.

These products were built in a different era, shaped as much by the preferences and philosophies of individual developers as by formal product strategy. Over time they accumulated their own folklore. Passing from hand to hand and rewritten across technological epochs. From early proprietary frameworks, through the VB6 years, and eventually into the kernels of the modern platforms we see today.

Patches layered on patches, customisations handed down across IT officers like a set of inherited tools. The products became familiar in the way old houses are familiar. But that familiarity always sat alongside the fatigue of technical debt and the quiet knowledge that the foundations were ageing faster than the councils could ever adapt.

Many of these companies had essentially sidestepped the full SaaS re-architecting journey that today’s contemporary software vendors undertook over the past 15-years. Their platforms carried years of incremental adaptation rather than a ground-up rebuild for the cloud era. So when ReadyTech bought IT Vision in 2022, Open Office and Open Windows in 2021, and CouncilWise in 2025, it didn’t just acquire customer bases. It inherited a complex landscape of legacy technologies, long-held customer expectations, service anxieties and decade’s worth of unresolved architectural decisions. What looked like a consolidation play on the surface was, in reality, a massive integration and modernisation challenge beneath it.

From an analyst’s perspective, the goal of these acquisitions was to create a unified cloud pathway under the Ready Community banner. Great. But bringing several long-standing systems, architectures and deeply embedded customer histories into a single platform is a complex, multi-(multi)-year exercise. I think the gap between the long-term vision and the immediate product reality was visible to councils, and to analysts, from the outset.

The moment the consolidation became real, councils in South Australia and Western Australia found themselves exposed to a new kind of question. WA in particular, with its deep SynergySoft footprint, probably felt the tremor first. SA was close behind, shaped by its own mix of Open Office and CouncilWise installations.

Entire regions began to look at their systems not as fixed assets but as things that now demanded re-evaluation. In 2025, conversations that had been dormant, sometimes for decades, suddenly became urgent, and competitors immediately recognised the moment.

Vendors who had struggled for visibility in certain states found doors opening that had been shut for a generation. They moved quickly, not because councils were suddenly dissatisfied, but because the conditions for change had finally appeared. The shift created a window of opportunity, and the market did what markets always do when stability dissolves. It flowed into the space that uncertainty created.

This would not have happened without ReadyTech.

Councils in the smaller tiers rarely pursue ERP renewal unprompted. Their operating reality is defined by immediacy. They have limited staff, tight budgets, visible risks, and a constant pressure to keep services running with as little disruption as possible.

Technology is often framed as an essential cost rather than an enabler of transformation, which means the perceived return on a major systems overhaul rarely outweighs the effort required to deliver it. In environments like this, large-scale change doesn’t emerge organically. It takes an external jolt to surface the question, and that is precisely what happened here.

They were pushed into clarity by the uncertainty that supplier consolidation always brings. When a familiar vendor disappears into a larger structure, even if the intention is good, the relationship changes. It doesn’t matter if it is IBM or Salesforce or in this case ReadyTech. Customers want to know what comes next, when it comes, and how far away next actually is.

ReadyTech offered a paper vision in which everything converges into a single cloud platform. The vision was attractive, but the details and the timeline were not. A vision without specificity becomes its own form of disruption, because it requires customers to imagine the gaps for themselves. And when councils are already relying on the day-to-day performance of their incumbent system, that ambiguity doesn’t inspire confidence. It actually amplifies the sense that the future is being asked of them before the present is fully resolved. The more opportunities councils had to look at the unified future, the more they realised that much of it was still being built. And the more they realised that, the more they looked outward.

This is how MAGIQ found itself with an open door in regions that had resisted change for decades. The company has followed its own long arc of acquisition-based evolution, not unlike ReadyTech’s, and not without its own challenges, but the crucial difference is timing. MAGIQ arrives at this moment with a cloud ERP and solution portfolio that is largely coherent and deployable. In many ways, it is benefitting from the conditions ReadyTech created.

The simplicity of a platform that is fully formed and available now becomes a powerful antidote to the uncertainty that consolidation has introduced. CouncilFirst has found a similar opportunity, not by promising simplicity but by grounding itself in something even more reassuring. Microsoft. A D365 ERP looks less like a leap of faith in 2025, and more like an extension of the tools that councils already trust, with regional skills they have, in an environment they know.

None of this was inevitable. ReadyTech created the conditions. The consolidation strategy brought three very different ecosystems into the same gravitational field, but unity in structure has not translated neatly into unity in customer expectation. A SynergySoft council in WA has different needs to a CouncilWise customer in SA or TAS, and each differ again from the councils shaped by Open Office’s regulatory workflows. From what I have observed, each group was told it would be part of a bigger future without clearly seeing how their present would actually merge into it.

As soon as one council in a region began to reassess its position, its neighbours followed. Market testing is contagious. Tenders are even more so. Councils talk, especially in SA and WA, where the distances are vast but the community of practice is tight. A single reassessment in the Wheatbelt becomes a conversation across half the state. A moment of doubt in the Adelaide Hills reverberates along the Limestone Coast.

This is why South Australia and Western Australia became the epicentre of local government ERP movement in 2025, and why 2026 looks set for even greater disruption. These states held the highest concentration of the legacy systems that ReadyTech absorbed. When those systems were lifted under a new umbrella, the stability that once held them in place dissolved.

Once councils stopped looking at this as a technology review (an area where confidence is often low), and instead began reviewing something they understand intimately (risk, autonomy and future dependency), the logic changed.

For the first time in a long time they felt responsible for questioning the structures that would shape their future. Were they really bound to the systems they had? And the moment the conversation moved out of software features and into organisational control, the door opened for every competitor in the market.

The irony is that ReadyTech has done nothing wrong in strategic terms. Consolidation was always coming. And consolidation will continue. The long tail was never sustainable. Obsolesence has been marching closer every year. The sector needs modernisation, clarity and investment. ReadyTech tried to bring all three at once. But timing matters, sequencing matters, and executable roadmaps matter more than ever in a sector that has lived with legacy debt for a generation.

And so the hornet’s nest was kicked. Not because ReadyTech intended to provoke the swarm, but because the pressure of consolidation was applied before the structure beneath it had settled. The result is a market that is suddenly louder, faster and more liquid than it has been in twenty years.

MAGIQ, itself a slow burner over the last decade, is winning councils it never would have reached before. OST is entering conversations that were closed to it just a few years ago. Datacom has a message. Even TechnologyOne is finding fresh attention in places that once dismissed it as too large or too costly.

ReadyTech may still emerge stronger but that will only become clearer in 2026. It is worth noting that their share price (ASX: RDY) has fallen by roughly 25 per cent over the calendar year. That movement reflects the performance and market sentiment around the entire company, not just the Local Government practice where the IT Vision, Open Office, CouncilWise and Open Windows acquisitions sit. But it is a reminder that the broader consolidation narrative is still being digested by investors.

Whatever the reasons for the decline, it reinforces the point that councils should assess their own risk and dependency positions independently of how the market values the company as a whole. Because being publicly traded also introduces a different set of strategic pressures. Listed companies are required to balance long-term product integration with short-term financial performance, and that inevitably shapes how aggressively they can invest in unifying complex portfolios. Civica’s ebb and flow over many years is reflective of this kind of pressure.

It also means their product mix is not static. Acquisitions can be followed by consolidation, re-prioritisation or shifts in focus as the company responds to market conditions and shareholder expectations. None of this is unusual. But it does mean that 2026 is going to be a critical year for ReadyTech as councils re-evaluate their current state. This includes a clear understanding of the structural realities of a listed vendor, and the strategic adjustments that may yet still occur in this vertical over time.

The advantage of consolidation has been offset by the acceleration of choice for which they have been found unprepared (this year), because the fight now unfolding has very little to do with features on a brochure. It has become a test of trust, of whether councils believe the roadmap is real or merely aspirational, and of whether they can deliver consistency at scale (better than the companies they acquired), rather than promise it in theory.

It is about stability in regions where stability has always mattered more than novelty, and about whether a supplier can speak credibly to long-term data strategy in organisations that barely have the internal capacity to manage today’s demands. Above all, it is about platform alignment and the quiet politics of technology in environments where every resource is stretched, every decision carries weight, and every misstep is felt for years.

In the end, the real story is that this part of the local government ERP market didn’t wake up because it was hungry for innovation. It woke up because its sleep was disturbed. But it is definitely awake now.

ReadyTech didn’t simply trigger an upgrade cycle. In fact, had it left the landscape untouched, I doubt MAGIQ or CouncilFirst would be expanding as quickly into South Australia and Western Australia with the momentum they have today.

The consolidation forced councils to re-examine assumptions they had held for years, and that re-examination opened the door for competitors. Where inertia, not technology, is the mechanism holding everything in place, once a council realises it has options, the entire market changes.

What happens next is where the real tension lies. The decisions councils make from here will shape not just their systems. The implications reach far beyond product choice, touching questions of trust, capability, data, politics and the quiet realities of operating under relentless constraint.

Paid subscribers can read on to further understand what I think it means for the hundreds of councils faced with this decision, and the 100-day plan.

Read more

Last month I wrote about the convergence of three distinct platform layers (The New Digital Campus). Basically, a digital twin for context, a network for sensing, and a service platform for action. I didn’t mean it as a slogan. I meant it as a pattern that is emerging naturally wherever physical and digital systems are forced to coexist.

Every major transformation wave eventually reduces to architecture. And the same is happening here. If the last twenty years have been about digitising processes. The next ten will be about digitising environments. Those places we live, work, and move through. And in doing that, we’re actually building three simultaneous control planes that each see the world differently.

The digital twin sees space. The network sees motion. The service platform sees purpose.

Each is essential, but none can govern alone. The twin without the network is static. The network without the service layer is blind. The service layer without the twin is contextless. The art, and the next decade’s leadership challenge, lies in learning how to align them. Because context without sensing is theory. Sensing without action is noise. And action without context is chaos. Let’s look at each in turn.

Share

Imagine match day at the new Macquarie Point Stadium in Hobart, or at Brisbane’s future Olympic venue rising at Victoria Park for 2032. Whether it’s thirty thousand fans or a hundred thousand, half a dozen entry gates or twenty. At these venues, every part of the environment comes alive. Food and merchandise stalls, floodlights, elevators, big screens, turnstiles. Each one behaves like its own system, yet all of them share, and must operate within, the same physical reality.

The digital twin is the layer that gives that reality structure. It’s not just a 3D model of stands and seats. It’s the contextual fabric that tells every other system where it lives. It defines the relationship between a sensor, a gate, and the concourse it occupies. It knows that Gate 7 leads to Section D, that Section D holds 4,200 people, and that 12 percent of them are likely queuing for food at halftime, or at end of next heats.

Ten years ago, that kind of intelligence was called visualisation. It was a dashboard with geometry. Today, it’s becoming governance. Bentley, Esri, and Hexagon see it. So do the digital-engineering teams inside stadium operators and city councils. Las Vegas runs on it. The twin has evolved from static architecture into a living spatial framework that anchors decisions in reality. It’s where the geometry of the physical world meets the semantics of data.

When a sensor trips, the twin gives it meaning. When a maintenance task is triggered, the twin places it in space. When a workflow is launched, the twin defines its scope. Context becomes the control plane. It is the quiet source of truth that keeps data from floating free of the world it’s meant to describe.

But context alone can’t keep up with movement. On match or event day, a stadium isn’t static. It breathes. And that’s where the next platform comes in.

By the moment the event starts, whether it’s a match or a medal race, the digital twin understands the environment, while the network understands the activity within it. It knows the moment.

Every tap of a turnstile, every phone connecting to Wi-Fi, every surge of foot traffic from the nearest public transport hub, the network senses it first. In a modern stadium, connectivity is no longer a utility. It’s actually a nervous system. Thousands of access points, edge switches, and antennas feeding a live pulse through the environment. Extreme Networks calls it “network as experience,” and that’s not marketing hyperbole. It’s a statement of architecture.

On game day, the network becomes the bridge between movement and meaning. It knows when a stand fills unevenly and can redirect fans through alternate gates. It detects congestion at food outlets and pushes alerts to digital signage. It powers dynamic advertising boards that change based on crowd composition, location, or even sentiment. It feeds anonymised analytics back to transport operators to synchronise departures at the end of proceedings.

Every packet of data tells a small story, whether it is a path, a delay, or a choice. And together those stories form a real-time map of human behaviour. That’s why sensing has become the new competitive advantage. It’s not about signal strength anymore, but situational awareness.

And yet, awareness doesn’t equate to action. Knowing that a crowd is forming at Gate 4 doesn’t disperse it. Detecting a security anomaly doesn’t resolve it. Sensing is only valuable when the system can respond. That’s where the third layer, the service platform, comes in.

When you can observe but not intervene, clarity becomes its own kind of pressure. It means the system is fundamentally incomplete.

In a connected stadium, thousands of micro-events unfold every second. A sensor detects rising CO₂ in a corporate box. A payment terminal goes offline in a bar. A Wi-Fi access point overheats above Section F. A floodlight trips on the northern stand. Each alert is meaningful, but without coordination it’s chaos.

The service platform is where those signals become decisions. It’s the layer that translates sensing into action and where telemetry turns into a ticket, a workflow, or a dispatch. Platforms like ServiceNow are increasingly acting as the orchestration brain in these environments. They link the physics of the twin and the pulse of the network to the operational routines of human teams.

When a cooling unit fails, the network senses the drop in performance, the twin knows its location, and the service layer automatically assigns a technician complete with route optimisation, part availability, and escalation protocols if the fault affects broadcast integrity. The system doesn’t just notify someone. It mobilises the right response.

That response extends beyond maintenance. The same service logic drives the fan experience by triaging support queries, coordinating lost-and-found incidents, and dynamically updating digital signage or transport information. When a thunderstorm rolls in, the platform can trigger automated messages across screens, social channels, and the transit API all in a single orchestrated act of service drawn from dozens of sensing points and one shared context. Action is the visible edge of architecture. It’s how design becomes experience.

Let’s scale this up. A stadium is a microcosm of a city. It has transport, energy, retail, safety, waste, water, and Wi-Fi all compressed into a few square blocks and a few decisive hours. It’s a system of systems with no margin for error. If you can govern a stadium digitally, you can govern almost anything.

But in practice, few environments are governed by a single authority. The modern campus, whether a stadium, hospital, port, or recreation precinct, often sits at the intersection of public and private control. Local government owns the land, maybe even the facility. State agencies regulate safety and transport or co-locate adjacent premises or share infrastructure hubs. Private operators manage the facilities. Vendors and contractors own the data pipes, the cameras, the kiosks, the fibre, even the lights. Each layer of ownership comes with its own systems, contracts, and accountabilities.

That’s what makes the campus such a compelling modelling framework. It exposes the messy middle ground where infrastructure meets jurisdiction and where the problem isn’t just technical integration but institutional alignment. Who decides when every system has a stake? Who governs the shared space between ownership and operation? These has been one of the key challenges of Macquarie Point for over a decade.

The answer will vary by place, but the 3-platform architecture won’t. Whether public or private, the path forward still depends on the alignment of context, sensing, and action. The same logic scales outward. A streetlight isn’t that different from a floodlight. A bus interchange isn’t that different from a gate. A council operations centre isn’t that different from a control room. What changes is the number of owners and the complexity of consent.

When these three platforms align, we stop managing assets and start governing environments. Cities and campuses alike become living, responsive systems, just like organisms that can sense, think, and act with intent, even across boundaries.

So here’s the rub. It only works if the data can move between jurisdictions, stakeholders and platforms securely, predictably, and with consent. In a stadium, that means Wi-Fi telemetry owned by a network partner may feed into an incident workflow managed by a facilities contractor, which depends on spatial context from a digital twin licensed to a different entity altogether. Each stream is vital, and each is owned by someone else.

That’s why the real foundation of this architecture isn’t just technology. It’s shared data governance. That’s just fancy language for a practical framework for how data crosses boundaries without losing its lineage or trust.

In most environments, those capabilities sit within the service platform layer. It’s the part of the stack that can enforce access rules, orchestrate data flows, log decisions, and record who acted on what signal. It’s the connective layer where operations meet accountability. In that sense, the service platform isn’t just the place where things get done but the place where governance lives.

The three-platform model doesn’t magically solve the governance problem, but it does give it shape. It also reveals the complexity of where ownership must be defined, where agreements must exist, and where the friction still sits. For some organisations, it will remain a reference model that guides decisions even if full alignment remains out of reach. For others, especially those managing complex shared spaces, it offers a blueprint for building genuine interoperability between people, systems, and intent.

Because in the end, context, sensing, and action aren’t separate domains. They’re three ways of describing the same pursuit. That is, turning a world full of signals into one that can think, decide, and act together.

Most campus-scale and city-scale digital transformations have stalled, and will keep stalling, for a simple reason: they are trying to connect a landscape that was never built to be connected. For years, even the largest asset-engineering firms have tried to bridge that divide through modelling and spatial mastery, but the systems they interface with were never designed to operate as one shared experience.

The converged environment stack I’ve written about here is the pattern that finally closes that gap. It anchors the architecture, maps the ecosystem, and makes the structural gaps impossible for both organisations and their supplier ecosystems to ignore.

One of the clearest is this. Digital engineering firms are world-class in physical and spatial data, but they remain weak in the platform layer that actually orchestrates the organisation. Whereas the opposite is also true. IT-led PaaS capability alone can’t win the campus either. Spatial brilliance without service orchestration, and service orchestration without spatial truth, leaves the transformation unfinished.

Until engineering capability and platform capability converge, the outcomes leaders are seeking will continue to stall at the edge of the models they create. But there is a way.

This week I thought I’d do something a little different.

I don’t usually write product reviews. But every so often, a product moves out of the realm of technology and becomes something closer to a lived experience.

We’ve all heard the stories about brilliant products plagued by persistent problems. Range Rovers are the perfect example. They’re stunning to look at and a genuine design icon. Yet behind all that elegance sits a well-earned reputation for unpredictable electrical faults and the occasional roadside moment where prestige quietly gives way to frustration. My cousin’s electronic key once opened his neighbour’s garage doors, which tells you everything you need to know.

And that, unfortunately, is where the Surface Laptop 6 for Business1 now sits for me.

It is, without question, a stunning device. The industrial design is exceptional. It’s thin, modern, understated, and precisely the kind of aesthetic that signals “premium” to match it’s AUD$4,000+ price tag. I should know. I am about to receive my third one since May. Not because I wanted a collection. Because the first two failed.

Across the last several months, I’ve experienced a pattern of issues that would be excusable if they were isolated. But they weren’t. And when the same behaviour appears across multiple units, it stops being an anomaly and starts revealing something more fundamental than cosmetic flaws or unlucky hardware.

Although I don’t typically write about end-user devices (most of my work sits in strategy, roadmaps, and broader technology portfolio decisions), I’m often asked for advice on laptop selections and desktop fleet approaches as part of those consulting and advisory engagements. When a device begins to materially affect my own work and patience to this degree, it becomes something worth sharing, if only to inform the organisations I support when they ask the inevitable question: “What laptop should we standardise on?”

The Surface Laptop 6 is a masterclass in how design can oversell capability. Or even mask engineering compromises. From the outside, it presents as a modern device. The kind confident executives love and IT teams quietly tolerate. But the aesthetic promise collapsed for me within a few weeks. The longer I used it, the more I began to see the competing behaviours operating just beneath the surface, working against the very experience the device was supposed to deliver. I had early buyers remorse.

A laptop designed for business must do two things exceptionally well. It must start consistently, and it must stay stable. That’s the baseline. The two units I’ve had so far (the original purchase and the first warranty replacement) have done neither. I now await the third with dread.

What makes this more disappointing is that I have always welcomed the promise of Microsoft hardware in the enterprise. Years ago, when I was Head of Technology at one of Australia’s capital city councils, I even pursued a Surface Pro rollout. The vision for a modern, flexible device ecosystem tightly integrated with the Microsoft platform was compelling. But the reality, from an ITSM and operating environment perspective, was simply too unstable at the time, and we ultimately standardised on HP EliteBooks instead.

So when I returned to the Surface line with the Surface Laptop 6 for Business, I did so with genuine optimism that the longstanding challenges had been resolved. I had also seen a few positive reviews from analyst colleagues that had attended events in Singapore for the launch of the new line, and thought it time to try again. Instead, I found myself facing the same fundamental reliability issues only now in a device positioned, priced, and marketed specifically for business use.

So what’s the problem? Well I am not a hardware engineer. But the event logs (which I’ve kept for verfication) tell a remarkably consistent story. It’s clear that, in this device, form won the argument over function at Microsoft HQ. And the consequences for my lived experience have been equally clear. The beautiful design introduces a significant thermal constraint that affects the entire behaviour of the system. In other words, this isn’t an isolated defect. It appears to be a platform issue.

To make a laptop this thin, light, and quiet (in other words, beautiful) something has to give. And in this model, what gives is cooling capacity. The thermal solution is physically elegant, but thermodynamically insufficient. In practical terms, when you place a modern Intel processor inside a chassis designed to prioritise silence and aesthetics over airflow, the physics eventually catch up. And catch up they do. Because this device runs hot.

It hits its thermal limits early and often. And once it does, the rest of the system begins to behave like it’s trying to move through soft sand. The CPU frequency collapses. Windows services time out. Start-up slows. Authentication fails. Drivers initialise late. Applications stutter. The entire system becomes unstable under basic workloads.

At one point I found myself browsing for gaming-laptop cooling mats and ventilation stands, which is precisely the kind of improvised workaround you’d expect from someone trying to cool a budget gaming tower, not a premium business laptop.

It is pretty obvious that none of this is ideal in a cloud-based working environment. Form me that meant critical shut downs during Zoom calls, Teams meetings, and pdocast sessions. But not just that . Collaborative documents and browser-heavy workloads sometimes trigger some instability. When that happens, the 6 can lock up or trigger a critical shutdown because of cascading thermal events. Your productivity doesn’t slow. It simply stops. As does the user’s trust.

This isn’t conjecture. It’s observable, measurable, repeatable and leads to one of the more ironic realities of the Surface Laptop 6 experience. The specs are are technically impressive but practically irrelevant.

What is the purpose of a 3.x GHz processor if it spends most of its operational life throttled down to around 1.8? On paper, the device delivers modern performance. In practice, the thermal envelope is so tight that the processor rarely operates in its advertised range. It’s the hardware equivalent of owning a high-performance car that looks incredible in the brochure but spends most of its driving life stuck in second gear. Not because of the engine, but because the cooling system can’t keep up. Kind of like a 1980’s Volvo. At some point, you stop blaming the engine and start questioning the design of the car.

The knock-on challenges from the hardware are consequential. Especially in the interplay between temperature, power management, and Windows boot sequencing.

When the 6 is already running hot during startup, the firmware steps in to protect the hardware. It throttles aggressively, delays power delivery, and forces the CPU to operate well below its intended baseline simply to keep temperatures under control. In practical terms, it takes a machine that is marketed as a thoroughbred and turns it into a donkey before it’s even out of the gate.

Windows, meanwhile, is trying to do what Windows must do. That’s a good thing. It has to authenticate the user (me), start essential services, attach to the network, initialise drivers, and bring the system to a point where you can actually begin working.

But with the heat problem, the result is a cascading failure pattern that became easy to recognise with uncomfortable familiarity. Before long, I was far too well-versed in hard-reset protocols and scrambling to remember where my BitLocker recovery key lived just to unlock the device and start again. This is not the workflow anyone imagines when buying a premium business laptop, yet it has become an oddly regular part of my 2025.

And, of course, the outcome is predictable. System services fail not because they are inherently unreliable, but because the OS is trying to sprint while the firmware has already decided it’s protecting a donkey. But you can’t simply flog a donkey to be fast out of the gate in the Melbourne Cup, and no amount of beautiful industrial design changes the physics underneath.

This forces the errors that show up in the system event logs. Not because Windows is misconfigured. Not because the laptop is faulty. But because the device is unable to maintain stable thermal and power conditions while starting.

What makes this more problematic is Microsoft’s positioning. This isn’t marketed as a lifestyle product. It’s not a student laptop. In fact by comaprison, my engineering student daughter’s ASUS laptop is highly performative at less than half the price. But the Surface 6 is explicitly sold in the business cateogry. And that carries certain expectations.

At its most basic that expectation is for reliability, consistency and predictable behaviour under load. Businesses do value appearance, but they value reliability more. And no amount of industrial polish compensates for a machine that can’t deliver dependable daily work.

For me, the real cost of these issues isn’t the technical noise but the practical impact. The disrupted meetings. The repeated troubleshooting. The replacement logistics (OMG!!) that should never be necessary, and a noticeable erosion of trust in the brand. At the end of the day, this device hasn’t supported my work. It has interrupted it. It has become a point of failure in what should be a straightforward, hybrid, remote-friendly working environment.

I blame myself. The Surface Laptop 6 is a beautiful machine. But its beauty cannot compensate for its instability. I’m now waiting for my third unit in under a year. That fact alone should tell the story.

During the first warranty replacement, a series of follow-up exchanges (messages, emails, and a Teams call) were arranged through a connection with the analyst relations team. In those conversations, I was offered some additional support due to the recurrence of issues, including assistance with the return process and a spare device (a smaller, lower-spec model) to use as a safeguard if the problems resurfaced.

The warranty replacement arrived. The spare never did. And when I followed up, the conversation simply stopped. It was an unfortunate experience and one that sits awkwardly alongside the “for Business” positioning of the device.

I really wanted the Surface Laptop 6 to be the perfect blend of form and function, and a dependable part of my daily workflow. Instead, it has become an ongoing case study in how technology can fail quietly, subtly, and consistently when the design brief is not aligned with operational reality.

I’ve deliberately waited months before publishing this to ensure it wasn’t written in frustration, though there has certainly been enough of that. We are where we are. What’s left is and a genuine desire to share my lived experience with others.

And with the warranty valid until 19 May 2027, I’m not entirely confident this will be the end of the story.

Subscribe now

For twenty years, the Australian local-government technology market was defined by stability. Not innovation. Not transformation. Stability. A handful of ERP providers held entrenched positions, councils cycled through the same replacement patterns, and vendors priced their products with quiet confidence that switching costs alone would do most of the defensive work.

TechnologyOne was the standout beneficiary of that era. A broad suite, accessible delivery motion, a maturing SaaS platform, and a customer base with limited alternatives. The company earned its premium ASX valuation because the environment allowed it. Low churn, predictable growth, and high margins built a defensible ANZ footprint.

But that world no longer exists.

And this shift exposes a deeper truth about TechnologyOne. It has always been a market leader in the ANZ local-government ERP space, but a laggard when measured against the global SaaS and ISV curve.

Within its niche, it has been the dominant incumbent for decades. But in a world now defined by platforms, ecosystems, and AI-native workflows, councils aren’t benchmarking their core systems against Civica or ReadyTech anymore. They’re benchmarking them against ServiceNow, Microsoft, Salesforce, and the global SaaS pattern-makers. The category has changed, and suddenly regional leadership is no longer the same as architectural leadership.

Over the past five years the gravitational centre of local-government technology has shifted. Albeit quietly at first, now more rapidly. And irreversibly. The ERP is no longer the centrepiece of the enterprise architecture. The platform is. The workflow layer is. The integration spine is. The AI-enabled service environment is. Councils are moving beyond monolithic system thinking and entering an era where capability matters more than modules, orchestration matters more than ownership, and outcomes matter more than suites.

This is the great decoupling. It is the loosening of ERP gravity and it has caught some vendors mid-stride.

TechnologyOne now finds itself navigating a transition at the exact moment the market it once dominated is fragmenting. Not collapsing mind you. Just fragmenting. The shift to SaaS-Plus is strategically sound but financially heavy because it front-loads delivery costs in a business that previously enjoyed the luxury of high-margin licence revenue. The company is still growing strongly, but it is a smaller software organisation (intenrationally speaking) facing the long, expensive part of a business-model transition without the decade-long cash reserves of the global platforms.

And the ground is moving beneath its feet.

Salesforce Public Sector Solutions is inserting itself into licensing, inspections, and citizen engagement workloads. ServiceNow, barely a footnote in the sector five years ago, is now fomenting customer service, regulatory workflows, and internal case management across councils. Microsoft and AvePoint have effectively captured the information governance and records landscape.

ReadyTech, newly consolidated through OpenOffice and CouncilWise acquisitions, is refirming for a push into property, regulatory, and rating workloads across the bottom third of the sector, while CouncilFirst, built entirely within the D365 platform, is moving with a clarity of purpose not seen in that portfolio for years.

Even Datacom is re-articulating itself around platforms, services, and outcomes rather than modules. And Civica, the vendor that has drifted in and out of competitiveness for decades, following periods of stagnation, under-investment, leadership churn, or customer dissatisfaction, is now rising again, because the structural shifts in the market have created openings that didn’t exist during the era of ERP monoliths.

This new ecosystem adds depth, competition, and architectural diversity, which naturally softens ERP’s old dominance. And even if you don’t buy that argument, the shift is significant enough to warrant some serious reflection.

In this environment, premium pricing for ERP requires more than historical position. It requires platform alignment. AI strategy. Integration maturity. Workflow extensibility. It requires a clear role inside a multi-system architecture where councils expect SaaS interoperability, PaaS capability, and the freedom to assemble their own service experience.

The margin pressure we now see in TechnologyOne’s financials, reflected in a 17% drop in share price yesterday1, is not the story. It is the signal. It is a symptom of a market recalibrating to the reality that local-government technology is no longer structured around a single vendor.

SaaS-Plus is not the problem. It is simply the cost of competing in a world where modern councils expect the implementation experience to be part of the value proposition. But when that model shift happens at the same time the sector is re-wiring itself around workflow platforms and AI-driven service layers, investors start asking harder questions.

Can a mid-sized Australian software company absorb multi-year delivery investment while global platforms target the same budget lines?

Can a legacy ERP maintain relevance in a market where the workflow engine, not the finance or rating or asset modules, defines customer experience?

Can councils justify premium ERP spend when the modern architecture is a federation of best-fit platforms with rich APIs and low-code extensions?

These are structural questions, not cyclical ones. The likely outcome is not collapse but correction. ERP will remain a very important part of the stack, but not the anchor. Councils will continue to modernise, but not around monoliths. Vendors will need to articulate interoperability, extensibility, and platform partnerships as clearly as they once articulated module roadmaps.

The winners in the next decade will not be those with the broadest suite. They will be those with the strongest gravitational pull towards the platforms that help councils orchestrate services, manage data, automate work, and integrate seamlessly with specialised line-of-business tools.

Local government has already shifted its centre of gravity. The procurement language has changed. The architecture diagrams have changed. The conversations with CEOs and CFOs have changed. The expectations placed on technology leaders have changed. A vendor can hold its place when it’s the sun. But not when the whole solar system drifts into a new region of the galaxy.

ERP is still in the room. It is just no longer at the head of the table. And that change, not yesterday’s share-price drop, is the story I’ve been tracking for nearly two years.

A Bentley Systems ad slid through my Instagram feed last week (I’ve posted it later in the article). It depicts a bridge stretching across calm blue water. Clean symmetry, the promise of precision. It read, “All sensor data in one intelligent platform”. Bring your sensor data to life with iTwin IoT. It was a small thing, but it stopped me. Not because of the ad itself, but because of what it represented. It’s a resurgence in the quiet convergence of infrastructure, telecommunications, and software into something that looks less like asset management and more like urban governance.

And what struck me most was that it’s not new. In fact, part of the reason I paused was because I’ve seen this cycle before, and it feels like it’s on the rise again. It’s been more than a decade since I first sat in a conference room at the now-demolished Mirage in Las Vegas during an early Amazon Web Services event and watched the commercial birth of IoT devices into enterprise platforms.

It was one of those moments that genuinely altered the course of my career, leading me to take on the role of City Innovation Director for one of Australia’s capital cities. I spent four remarkable years helping to kick start the digitisation of the city’s physical assets. Everything from parking, lighting, energy, bridges, parks, and transport into data models that could help rethink how the city managed outcomes, not just assets.

That’s why the Bentley ad caught me. It wasn’t just the precision of the bridge. It was the memory of that same promise, resurfacing a decade later in sharper focus.

In that image I didn’t just see a bridge. I saw a campus. The kind with buildings, roads, pipes, and poles. The kind that behaves like a miniature city but runs under a single operating budget.

Airports, hospitals, ports, universities, and recreation precincts have become the new frontier for digital transformation. They are self-contained economies, each with multiple classes of assets, thousands of endpoints, and an emerging expectation that everything within their boundaries can be not just monitored or modelled, but connected and continuously available and responsive to the people and businesses who depend on them.

Back in that first wave, the conversation was dominated by connectivity itself. By LoRaWAN, Sigfox, and other low-power, low-bandwidth networks that made it possible to instrument the physical world cheaply and at scale. They opened the field but also defined its limits due to narrow pipes, patchy reach, and constrained intelligence.

That’s where the real collision is happening now. The convergence of IoT, 5G, digital twins, and network intelligence isn’t just a technical shift. It’s an architectural one. It is a battle over who defines the truth about the physical world when it becomes software.

Every major vendor now sees this layer as strategic and its time we did too.

Schneider Electric approaches it from energy and building automation, wrapping every pump, motor, and HVAC unit in an efficiency story. Philips (Signify) extends its lighting heritage into connected luminaries and adaptive control systems, where a single light pole can act as a node for sensors, cameras, or Wi-Fi. Bentley Systems, traditionally the domain of engineers and civil modellers, is pushing iTwin as a digital-twin-driven data layer that spans sensors, structures, and spatial analytics1. IDT Snap4 takes the open-data route, trying to free telemetry from proprietary formats and feed it into whatever analytical engine the owner prefers.

And then there’s ServiceNow, which most people don’t think of as an IoT company at all. Yet its CMDB quietly absorbs IoT events through API connectors, allowing real-world devices to exist as configuration items that trigger workflows, incidents, and maintenance logic. It’s not about visualisation. It’s about operationalisation. Where Bentley might model a bridge, ServiceNow wants to orchestrate its upkeep, compliance, and lifecycle events through the same platform that handles HR requests and cybersecurity incidents.

This is the point where categories start to blur. The traditional notion of a campus management system becomes less about booking rooms or scheduling maintenance and more about managing a distributed, living infrastructure. A pole might contain a light, a sensor, a camera, and a 5G antenna. Each one is technically a different asset class, often belonging to different data hierarchies, yet all share the same physical coordinates and power source.

That blurring isn’t new. It’s just harder now. In most organisations, the physical estate has always been fragmented across multiple divisions. Property owns the buildings, engineering owns the road and energy networks, operations manages the maintenance, and IT historically stayed in the background. But the rise of new technology buying centres through digital experience teams, sustainability functions, and innovation hubs has layered new complexity over the old.

The result is a genuine decision point for CIOs and digital leaders. When every asset produces data and every division wants control, who actually defines the source of truth?

The hidden player in all of this is, of course, the network. Every connected object depends on a backbone that is itself transforming. 5G and Wi-Fi 6 are no longer just telco evolutions, they are the enablers of this municipal mesh. They collapse the boundary between public and private infrastructure, between what’s owned and what’s provisioned. Suddenly, a university network looks more like a telco. Every access point, switch, and gateway becomes part of an ambient computing fabric.

That’s where companies like Extreme Networks re-enter the conversation. For years, networking felt like plumbing. It was critical but invisible. Now, as IoT architectures scale, the network has become the nervous system that determines visibility, security, and performance. CIOs who once treated it as background infrastructure are being forced to re-elevate it to a strategic discipline. The network defines the enterprise perimeter, the latency of sensor data, and ultimately the credibility of the digital twin itself.

The industry is circling back to a phrase that used to make architects groan. The single pane of glass. It is the idea that all operational data, from lighting to elevators to air quality to asset depreciation, can be viewed and managed through one unified interface.

It failed the first time (I was there), because it was tech-led and data models and protocols and governance were too fragmented. But today’s digital-twin ecosystems, combined with service orchestration platforms, might finally make it viable. The pane of glass this time isn’t actually a dashboard. It is more like an ontology where that shared language connects telemetry (tech) to context (outcomes).

So when Bentley speaks of iTwin IoT, what it really signals is the merging of civil engineering with live operational data. When ServiceNow extends the CMDB into IoT, it blurs the line between IT and facilities. When Schneider and Philips embed intelligence into their respective domains, they move from product vendors to platform participants. Each is competing to become the anchor of the digital campus, and by extension, of the digital city.

For CIOs and CTOs, this presents a new dilemma. Where to centre digital engineering gravity in a world where every system is trying to pull the enterprise into its own orbit. Which layer should become the organising centre of the organisation’s digital fabric? The twin, the network, or the service platform?

If you lead with the digital twin, the world looks like geometry and assets. If you lead with the service platform and it looks like workflows and incidents. Lead with the network and it looks like packets and policies.

Each approach is rational, but each yields a different form of governance. And really, that’s potentially just more of the same blur that will perpetuate the same overlapping lines of ownership and accountability. Only now it will be amplified by data, automation, and expectation.

The challenge isn’t to choose one.

In fact, most organisations already have versions of all three, often multiplied by department or vendor. The strategic opportunity is to rationalise the sprawl and start by anchoring around a single organising principle for the layer that best aligns with how the organisation actually governs itself.

The most advanced campuses will still weave all three together. I think the future is a twin for context, a network for sensing, and a service layer for action. But they’ll do so deliberately, with clear lines of ownership and a defined centre of gravity. I can’t wait to see the global partner models emerge in this space in the coming years.

And this is why the campus has become such a revealing unit of analysis. It’s small enough to manage but complex enough to mirror the systems of a city. It contains every challenge that municipalities face. It has multiple vendors, overlapping asset classes, fragmented data, competing operational logics, and the constant tension between centralisation and autonomy. If we can learn how to govern a campus digitally, we may have the blueprint for governing cities themselves.

What Bentley’s ad hinted at, perhaps unintentionally, is that the next wave of digital transformation won’t be about apps or analytics. It will be about alignment and getting infrastructure, information, and intent to inhabit the same architectural space.

And that’s the real frontier.

When every pole, light, and pump speaks, the question isn’t how to listen. It’s how to make them agree on what they’re saying.

We talk about the evolution of smart cities and the growing energy challenge of artificial intelligence, from the power density of NVIDIA’s GPU roadmap to the realities of cooling, sustainability, and grid resilience. And then we explore what happens when these forces converge.

It’s a conversation that connects the dots between energy, architecture, and intelligence and what it means for the future of how we build, power, and govern our connected world. Have a listen.