A useful tell that a skill is “softening” is when you stop hiring specialists for it and start expecting everyone to have it. Not as a bonus. As table stakes.
I’ve watched this happen in slow motion before.
Computer literacy used to be a hard skill. People took classes just to learn how to operate a computer. In the early mainframe era, organizations had dedicated teams for “computer operations” because the machinery, the interfaces, and the failure modes were unfamiliar. There was a clear boundary between “the business” and “the computer people.”
Then the boundary moved.
Today, a teenager can troubleshoot Wi‑Fi, share files, manage multiple identities, and assemble a gaming rig with better monitoring than some enterprise stacks. The old “press any key” joke doesn’t land because the world normalized the underlying competency. The skill didn’t disappear; it got absorbed into baseline expectations.
That same pattern is now repeating inside enterprises with architecture.
Enterprise architecture used to be a specialized hard skill. A small set of people owned the hard problems:
System boundaries and interfaces, tradeoffs across platforms, governance, cross-portfolio roadmaps, capability mapping, reference architectures, risk posture, standards, and the “so what” narrative for executives. Many organizations structured this as an EA function because the cost of getting it wrong was high, and the craft took years to internalize.
But the boundary is moving again.
Look at job postings today: Data Architect, Integration Architect, Platform Architect, Security Architect, and increasingly “GenAI Architect.” Many roles now list what used to be classic EA expectations:
- Systems thinking across domains and lifecycles
- CXO-level communication and decision framing
- Deep business acumen (not just tech depth)
- Ability to diagram anything quickly and accurately
- Patterns, best practices, reference architectures, and governance instincts
In parallel, engineering roles have been drifting toward “full-stack” expectations. What started as “Java dev vs. front-end dev” became “you own the slice.” And once a team owns a slice, it must internalize architecture, even if no one calls it that.
So yes: EA is softening.
Not because architecture is less important, but because modern delivery forces architectural thinking earlier and more locally. Microservices, event streaming, domain-driven design, platform engineering, regulatory pressure, distributed data, and now AI-enabled workflows all amplify the cost of “just ship it.” The tradeoffs surface in every sprint, not only in quarterly planning cycles.
The implication is not that architects are obsolete. It is that the center of gravity shifts.
When a skill becomes baseline, the specialist role survives only by moving up the value curve toward harder problems that others cannot consistently solve. In enterprise environments, those “harder problems” are rarely about drawing diagrams. They are about aligning incentives, controlling risk, and creating repeatable decision systems.
What this means for enterprise architecture
As EA becomes more of an expected competency across senior engineers and delivery leaders, the EA function must evolve from “review board” to “operating system.”
In practice, that means:
1. Architecture becomes productized Reference architectures, paved roads, golden paths, reusable patterns, and platform capabilities need to be consumable. If the organization has to “request architecture,” it will route around architecture. When architecture is embedded into templates, pipelines, and platform defaults, adoption happens without heroics.
2. Governance shifts from approvals to constraints The future is fewer meetings and more guardrails:
- policy-as-code where feasible
- standardized landing zones
- pre-approved patterns
- automated checks in CI/CD This is how you scale safety without slowing delivery.
3. The architect’s new job is decision quality at scale The most valuable architects will be those who can:
- clarify the decision being made (and by whom)
- quantify tradeoffs (cost, latency, resilience, compliance, operability)
- identify second-order effects (organizational load, integration debt, vendor lock-in)
- design feedback loops (telemetry, SLOs, FinOps, incident learning)
When EA softens, architecture leadership hardens.
Now the next wave: AI softening
AI is going to go through the same transition arc, just faster.
Right now, AI is treated as a specialist domain. “Prompt engineer” is a job title. “RAG pipeline” is something you need a dedicated team to build. “Model orchestration” sounds exotic. It feels like early cloud, early data platforms, early containers.
But in enterprise terms, the destination is predictable: AI becomes a commodity capability.
Not because it becomes trivial, but because it becomes embedded, like email, relational databases, event streaming, and queueing. The organization stops debating whether to use it and starts assuming it exists.
When that happens, every technologist will be expected to understand the basics:
- Prompting patterns and failure modes (hallucination, instruction leakage, tool misuse)
- RAG as an integration pattern, not a magic trick (retrieval quality, chunking, ranking, citations)
- AI workflow orchestration (tools, agents, guardrails, human-in-the-loop)
- Evaluation and monitoring (quality metrics, drift, safety, cost)
- Data governance and security boundaries (PII, IP, retention, access, auditability)
AI will to become a soft skill. And just like computer literacy, the bar will rise quietly.
The new “hard” in an AI-embedded enterprise
Once AI is baseline, the differentiator won’t be “we have AI.” It will be whether the organization can run AI safely, economically, and predictably in production.
The hard problems will look familiar to anyone who has shipped enterprise systems:
- Designing bounded contexts for AI so blast radius is controlled
- Building governance that is enforceable without being bureaucratic
- Managing model and vendor risk (availability, data residency, licensing, exit plans)
- Creating evaluation harnesses that survive contact with real users
- Operating AI with SLOs, incident response, and cost controls
- Aligning incentives so teams don’t optimize for demos over durability
In other words: the hard part is the platform and the operating model.
If EA is softening and AI will soon follow, what should technology leaders do?
This is where senior technology leaders need to be precise. When skills soften, organizations often react in two unhelpful ways:
- Declare the specialty “dead” and remove it (creating chaos)
- Keep the specialty frozen in time (creating bureaucracy)
I suggest a third option: deliberately re-scope.
- Expect architecture literacy from senior engineers and engineering managers.
- Reposition the architecture function as the team that designs the guardrails, paved roads, and decision systems.
- Treat AI like any other enterprise capability: budget it, secure it, test it, monitor it, and govern it.
- Make “good defaults” the primary scaling mechanism.
If you want a decision principle to take into 2026 planning cycles: as skills soften, move specialists up the value curve and embed their expertise into platforms, policies, and repeatable patterns.
That’s how you scale competence without scaling meetings.
