Would you trust a dentist who has mastered a new laser but cannot use a drill? Most IT conferences feel like that. We applaud the next tool. We rarely talk about what failed, why it failed, and how to fix it. Are we learning anything, or just changing the soundtrack?
We have a delivery problem, and it is ours. Across engineering, product, operations, data, architecture, and leadership, we overhype new technology and underinvest in fundamentals. The logos change every few years. The root causes do not. Messy data, weak boundaries, thin security, little domain understanding, and shallow governance keep showing up because we do not do the hard work first.
Why fundamentals, not new tools, drive real outcomes
Look at the pattern:
95% of AI pilots flare and fade because strategy, data, and measurement are unclear.
Source: Forbes – “Why 95% of AI Pilots Fail and What Business Leaders Should Do Instead”
76% of Iot projects never reached production, not because sensors failed, but because basics and ownership did.
Source: IoT For All – “Why 76 Percent of IoT Projects Fail”
New technology did not solve old problems. It amplified them.
We should be honest about our culture too. Conference talks focus on what sells. Vendors need airtime. Success stories are safe to present. Failure is awkward and often under NDA, so we hide lessons and repeat mistakes.
High performers can improve speed and stability together when they focus on foundations and flow. There is no trade-off if you design for it.
Source: Dora Research
Across every layer, the responsibility is shared
Engineers rush to wire with a new technical feature, but skip naming and data contracts. Team leads chase velocity, but neglect testability and observability. Product owners talk features, not outcomes. Architects draw target states without fixing the problems in today’s systems. Executives approve platform spend before defining both value and criteria. Each role has a part in this.
The last year produced a wave of overnight AI experts. Many can call an API. Fewer can explain the business case, the data model, the operating cost, or the risk. That is not expertise. That is theatre. Other professions earn trust on fundamentals and a track record, then add new methods. So should we.
New tools do not fix old structures
Cloud without FinOps or application redesign is a bigger invoice with the same bottlenecks. ERP without process optimisation is the same queue in a shinier UI. AI on dirty data is confident nonsense. These are not arguments against cloud, ERP, or AI. They are reminders that technology is a multiplier. It multiplies whatever you already have, good or bad.
If you want the cloud to pay back, move cost into design, not month-end. Make cost visible, attribute it to products, and hold teams accountable over time. Treat Finops as a lifecycle of inform, optimise, operate, embedded in delivery, not as a reporting team on the side.
The POC habit that becomes a liability
“Stick it until it works” is fine for learning. It is poor delivery. Too many proofs slide into production without redesign for scale, resilience, security, and cost. The bill arrives later as outages, extra work, and rewrites.
The fix is weak and effective: stage gates.
A POC proves a narrow hypothesis.
A pilot proves value in a real slice with clear measures.
Production follows a hardening cycle.
What doing it right looks like
Doing it right is not easy. It requires skills across business understanding, process thinking, data, architecture, operations, cost, and risk. Most teams have never been trained to combine all of this. This is exactly where enterprise architecture should add value: not as a document factory, but as a continuous process that connects business goals to delivery decisions.
When architecture is treated as a process instead of a phase, it helps teams make trade-offs visible early, reduce rework, and avoid repeating the same mistakes across initiatives. Because we often shortcut this work, we are simply not used to doing it properly. It feels heavy, but it works.
Doing it right pays off because it makes change cheaper, safer, and faster over time. Decisions become easier. Costs become predictable. Systems become understandable instead of fragile.
1) Start with purpose
Define the outcome, the value measure, and the kill criteria. Fix the real process before automating it.
Enterprise architecture plays a key role here by translating business goals into clear capabilities, constraints, and principles. This prevents teams from solving the wrong problem with the right technology.
2) Treat data and design as products
Model and clean the data. Give it clear ownership. Align naming and semantics. Design for operations on day one. SLOs, error budgets, telemetry, and runbooks are not overhead; they are what reduce incidents and support cost.
3) Align everyone to the same scoreboard
Cost, reliability, and delivery should move together, not against each other. Enterprise architecture should make these trade-offs explicit and visible across teams, instead of letting them surface later as incidents or cost overruns.
The best teams do not choose between speed and stability. They build both.
Source: Dora Research
A better conference culture
We need fewer predictions and more honest lessons. Talks that show baselines, deltas, and cost, not only screenshots and preview features. Case studies that explain what hurt, what we changed, and what still hurts. The goal is not perfection. It is collective learning.
Innovation is not the newest framework. Innovation is the repeatable ability to solve real problems with focus and good practice. Fundamentals are not nostalgic. They are the parts that compound for ten or twenty years while tools turn over. Separation of concerns. Clean, consistent data. Security by design. Clear ownership. Simplicity over ornament. Domain understanding deep enough to say no.
Innovation, on adult terms
Innovation is not the newest framework. Innovation is the repeatable ability to solve real problems with focus and good practice. Fundamentals are not nostalgic. They are the parts that compound for ten or twenty years while tools keep changing. Separation of concerns. Clean data. Security by design. Clear ownership. Simplicity. Domain insight deep enough to say no.
Across all layers of IT, we need to wake up, take responsibility, and self-reflect. Be honest about delivery. Stay curious. Use new technology when it clearly multiplies value, and only after the groundwork is solid. If we do that, confidence returns. Not from slogans, but from outcomes. Not from hype, but from craft.