Let’s cut to the chase. Technology selection is broken. We swung from one extreme to another and forgot that the middle ground was where the real value always lived. Yesterday it was top-down vendor driven decisions, handed down from consultants who lived in ivory towers and designed architectures that looked flawless on paper but collapsed in practice. Today it is bottom-up engineer driven adoption, where complexity is worn as a badge of honour and every new tool promises salvation. Neither approach serves the enterprise. Both produce waste. Both create white elephants.

Enterprise Architecture became a dirty phrase for good reason. TOGAF certified consultants pushed frameworks that often delivered theory instead of impact. Businesses learned the hard way that “perfect” architectures often failed when exposed to real workloads and real people. Engineers rebelled, and Shadow IT was the result. Business units bought the tools that solved their problems without waiting for the IT department to catch up. And for a while, that was a good thing. Shadow IT actually delivered.

But here we are, years later, and we have overshot. The rebellion has become normalised. Now we are guilty of the opposite sin. It is not architecture for the sake of architecture anymore. It is technology for the sake of technology. Teams assemble stacks of tools because they can, not because they should. Kubernetes clusters layered with unnecessary abstractions. Pipelines bloated with integrations nobody fully understands. Monitoring systems so complex they need monitoring of their own. This is engineering perfectionism masquerading as progress.

What we need is not nostalgia for the ivory tower, nor blind celebration of the engineer’s playground. What we need is pragmatic architecture. A way to merge the rigor of the past with the urgency of the present. A way to ensure that technology decisions deliver value, not vanity.

The forgotten pillars of architecture

Pragmatic architecture stands on three pillars: non-functional requirements, functional requirements, and constraints. These principles are not glamorous, but without them you get chaos disguised as innovation. With them you get technology that is fit for purpose, sustainable, and actually useful to the business.

Non-functional requirements

Ignore these and you are setting yourself up for pain. Non-functional requirements are the guardrails that keep technology alive when the novelty wears off. They are the difference between a shiny new system that thrives and one that rots in production.

• Supportability. Can you get help when things break? Is there a vendor who offers real SLAs or a market of talent you can afford? A tool that depends on self-support from unicorn engineers is a liability, not an asset.
• Maintainability. How easy is it to keep the tool current? What is the release cadence? Can your team realistically keep pace with upgrades and patches, or will you fall behind and introduce risk?
• Survivability. What is your plan if the vendor disappears or the open-source community evaporates? Betting on fragile ecosystems is a gamble that too many CIOs lose.
• Scalability. Can you start small and grow, or does the tool demand enterprise-scale rollout from day one? Tools that only work at scale are traps.
• Availability. Does the solution align with the SLA your business requires? A “best effort” promise does not work for banks, hospitals, or governments.
• Resiliency. When something fails, how quickly can you recover? If the answer is “slowly,” you already know the outcome.
• Usability. Does the user experience match your team’s skills? Tools that require months of training are not accelerators, they are anchors.
• Security. Does it fit your enterprise posture without endless bolt-ons? Hoping to fix security later is not a strategy.
• Deployability. Can you deploy it securely yourself, or does it require high priests to configure it correctly? There is a huge gap between “it runs” and “it is production ready.”

Non-functional requirements are the boring questions that save you from expensive mistakes. They are the reason some technologies survive while others become cautionary tales.

Functional requirements

This is where too many enterprises fail. They are dazzled by feature lists and forget to ask whether the tool actually improves how their teams work. Functional requirements are about jobs to be done, not marketing promises.

• Start with the reality of today.
• How long does it take to deploy an application?
• How painful is a rollback?
• How quickly can security patches be applied across environments?

Unless you measure these workflows now, you will not know whether tomorrow is any better.

Then define what good looks like.

• If an environment takes four hours to spin up today, good might mean two.
• If resolving incidents takes a day, good might mean six hours.

Improvement must be tangible and measurable. And here is the rule: a new tool should deliver at least 20 percent improvement from day one. Not after two years, not after endless integrations. If it does not deliver immediate efficiency, it has not improved anything. It has simply changed the wallpaper.

Do not stop with the engineers. The true end users of a platform are the business stakeholders who consume its outputs.

• Does the solution reduce the number of support tickets?
• Does it give faster access to reliable data?

If the platform slows the business down, you have not delivered progress. You have introduced another layer of complexity dressed up as innovation.

Functional requirements are your reality check. They ensure you are solving real problems rather than collecting tools like trophies.

Constraints

Constraints are not excuses. They are reality. Ignore them and you end up in fantasy land. Respect them and you deliver something that actually works.

• Fiscal constraints define what is affordable. A brilliant tool that consumes half the IT budget is not brilliant at all.
• SLA constraints define what success looks like. If the business needs 99.99 percent uptime, your platform must prove it can deliver that. Paper promises are worthless.
• Timeline constraints define feasibility. You may dream of a platform that takes two years to build, but if the business needs results in six months then you must adapt.

Constraints are not barriers to creativity. They are the framework that forces prioritisation and discipline. Good architecture works within them, not in spite of them.

Why pragmatic architecture matters

Enterprises can no longer afford extremes. The ivory tower produced elegant failures. The engineer’s playground produces chaotic complexity. Both waste time, money, and talent.

Pragmatic architecture is the alternative. It does not worship frameworks, and it does not celebrate complexity. It applies discipline through three questions. Does this meet our non-functional requirements? Does it improve our functional jobs to be done? Does it respect our constraints?

The future of enterprise technology depends on asking these questions relentlessly. Because in the end, a platform that is not supportable, maintainable, survivable, scalable, resilient, usable, secure, and deployable, while also making the lives of its users demonstrably better within the constraints of budget and time, is not an asset. It is a liability. Another white elephant. Modern in appearance, useless in reality.