Most people can use enterprise technology without knowing very much about what’s happening underneath it.
An employee signs into a platform and gets access to the applications they need. A developer selects an approved deployment option and releases new code. A customer completes a payment. A manager approves a request, and several systems update before they’ve closed the page.
From the user’s perspective, each action feels simple. It’s supposed to. Much of the progress made in enterprise technology has come from hiding difficult technical work behind interfaces, services and automated processes that more people can use. Nobody should need to understand cloud networking before opening a customer record.
A developer shouldn’t have to configure every infrastructure component before testing an idea. Finance teams don’t need to know how an application stores data before they can approve an invoice. Hiding complexity has made advanced technology easier to adopt, operate and scale.
But there’s a difference between simplifying an experience and simplifying the system producing it. Cloud services, software-as-a-service platforms, managed infrastructure, application programming interfaces, identity systems and automation have steadily increased the distance between what a user does and what the organisation has to operate.
Artificial intelligence is extending that distance again. The result is a growing enterprise technology risk that’s easy to overlook. Which is that organisations can use their systems successfully every day while gradually losing the ability to explain how those systems work together.
Abstraction Made Modern Enterprise Technology Possible
Technological abstraction sounds more complicated than it is. It simply means hiding lower-level technical detail behind something easier to use. A person interacts with the service, interface or workflow without needing to understand every component supporting it.
Cloud computing is an obvious example. Instead of buying servers, installing them in a data centre and managing the physical infrastructure, teams request computing resources through a platform. Software-as-a-service, commonly called SaaS, takes this further.
The customer uses the application while the provider manages much of the hosting, maintenance and underlying technology. Managed services transfer more specialist work to an outside provider. Internal platforms give developers approved ways to deploy applications without asking them to configure every security, networking and infrastructure decision themselves.
Automation completes repetitive processes without requiring someone to move information between systems by hand. Each layer has made powerful technology available to a wider group of people. Google’s DevOps Research and Assessment guidance describes reducing developer cognitive load as one of the main goals of platform engineering.
Rather than asking every developer to become an expert in Kubernetes, networking and security policy, platform teams move that complexity into reusable internal services and approved workflows. This is sensible. Modern technology environments are far too specialised for every employee, developer or administrator to understand every component.
Cloud-native infrastructure alone now includes a deep mix of containers, orchestration platforms, managed databases, deployment pipelines, security controls and monitoring systems. The Cloud Native Computing Foundation found that 82 per cent of container users were running Kubernetes in production in 2025.
The technology is no longer an experimental addition. It has become part of the foundation supporting modern applications and AI workloads. Abstraction makes environments like these usable. It doesn’t make them simple. The technical work still exists.
It has simply moved into platforms, providers, specialist teams, policies and automated controls that most users never see.
Complexity Doesn’t Disappear When It Is Hidden
Every time one team stops managing part of the technology directly, someone or something else takes responsibility for it.
A cloud provider manages physical infrastructure. A SaaS vendor operates the application. An internal platform team creates approved deployment paths. Security teams define access policies. Integration tools move data. Managed service providers oversee specialist systems. Automated rules decide when processes can continue.
The user sees one service. The organisation depends on the combined work of all those layers. HashiCorp’s 2025 Cloud Complexity Report drew on responses from 1,100 business and technology leaders. It found that 97 per cent of organisations used multiple tools or services to manage their cloud environments.
The research also identified fragmentation, tool sprawl and misaligned teams as continuing barriers to effective cloud operations. Adding specialists can improve each individual part of the environment. It doesn’t automatically help the organisation understand the complete system.
The cloud team may understand the infrastructure. The application team understands the software. Security understands the controls it owns. An external provider understands the service it operates. Nobody may be responsible for assembling those pieces into one reliable picture.
This is where cloud complexity becomes something more specific than an environment with many tools or platforms. Understanding becomes fragmented along the same boundaries as ownership, monitoring and support. Teams can know their part very well while still being unable to explain how the whole process behaves.
The Enterprise Estate Is Larger Than What IT Owns
There was a time when the technology estate mostly referred to systems the organisation bought, hosted and managed. That boundary has become much harder to draw. Business teams can adopt SaaS applications without building anything themselves. APIs connect those tools to internal systems, cloud services and external providers.
Identity platforms control which people and machines can access them. Internet infrastructure carries the traffic between everything. The organisation’s operations now extend far beyond the technology it directly owns. Different teams may also hold different versions of the truth.
Finance knows which applications appear on invoices. IT knows what it officially supports. Security knows which services it has discovered. Business teams know what they’re actually using. Vendors understand parts of the service their customers can’t inspect. None of those views is necessarily wrong. They’re simply incomplete.
Identity infrastructure shows how quickly this becomes difficult to manage. Cisco Duo’s 2025 research found that 94 per cent of surveyed leaders believed complexity in identity infrastructure reduced their overall security. Three quarters said they didn’t have full insight into identity vulnerabilities across their organisations.
And identity no longer belongs only to people. Applications, devices, service accounts, automated processes and APIs all need credentials to prove what they are and what they’re allowed to do. CyberArk’s 2025 machine identity research was based on responses from 1,200 security leaders across six countries.
Half reported a security incident or breach linked to compromised machine identities during the previous year. The wider point isn’t only about security. Identity has become another operational layer that business processes depend on, even though most users never know it’s there.
What one ordinary transaction can depend on
Consider something as ordinary as a customer completing a payment. They choose a product, enter their details and press a button.
Behind that button, the organisation may need to verify the customer’s session, check inventory, calculate tax, call a payment provider, run a fraud check, update a database, trigger a confirmation message and send information into finance and fulfilment systems. Several APIs may carry those requests between different platforms.
The user experiences one transaction. The organisation operates a chain of dependencies spread across internal systems and external providers. Uptrends analysed more than two billion checks against live production APIs for its 2025 State of API Reliability report.
The research covered more than 400 companies across 20 industries and found that rising complexity was increasing the pressure on API reliability. When something fails, the effect may appear in a completely different place from the cause. The customer sees a payment error.
The ecommerce platform appears healthy. The network is available. The real problem may sit inside a provider several connections away. Monitoring can show that something went wrong. Understanding why may require several teams, tools and companies to piece the transaction back together.
Automation Moves Business Logic Between Systems
Automation was once relatively easy to picture. A rule lived inside an application. When a defined condition was met, the system completed a specific action. Modern workflow automation often spreads that logic across several places.
The trigger may come from one platform. An integration tool moves the data. A script changes its format. An identity service provides access. Another application applies the business rule. A final service completes the task.
The process still works, but its logic no longer lives in one obvious place. Employee onboarding is a good example. Adding someone to a human resources platform might trigger account creation, payroll enrolment, device ordering, software access, training assignments and manager notifications.
Each action may rely on a different system, provider or automated workflow. The person who built the automation may eventually move to another role. The platforms may change. New conditions get added. An old integration remains because removing it feels risky and nobody is completely sure what else depends on it.
Teams may know what the automation does without understanding every decision supporting it.
This is why a process diagram isn’t always enough. A useful record also needs to show what starts the process, which systems it touches, what authority it uses, where decisions happen, how exceptions are handled and what stops working when one dependency becomes unavailable.
Otherwise, the organisation understands the intended process without necessarily understanding the live one.
AI Adds A New Layer Between People And Technology
Earlier forms of abstraction mostly hid infrastructure and process complexity. AI is starting to hide parts of the interaction itself. An employee may not need to know which application contains the information, which query will retrieve it or which sequence of steps completes the task.
They ask for an outcome, and an AI assistant works out some of the path on their behalf. AI agents can take this further by selecting tools, retrieving information and initiating actions across connected systems. This makes the enterprise estate easier to use. It can also make the path between the request and the result harder to follow.
Google Cloud’s 2026 infrastructure research, based on responses from 1,402 global IT leaders, found that 83 per cent believed their organisations needed infrastructure upgrades to support agentic AI. The finding reflects a larger change: AI is becoming part of the technology environment rather than remaining a standalone application.
That environment was already heavily abstracted. An agent may work across SaaS platforms, internal databases, APIs, cloud infrastructure and identity controls that few people understand together. The user sees one conversation. The action may depend on half a dozen systems.
Traditional automation usually follows a route someone defined in advance. An agent may select its route according to the request, available tools and information it finds. Two similar tasks may not move through the environment in exactly the same way. The concern, then, isn’t only whether an AI-generated answer can be explained.
Leaders also need to know which information, permissions, systems and external services contributed to the result. AI hasn’t created the comprehension problem on its own. It has made the gap much harder to ignore.
Visibility Is Not The Same As Comprehension
By this point, a pattern starts to emerge. Cloud, SaaS, automation, APIs, identity systems and AI have all made enterprise technology easier to use. At the same time, they've increased the distance between the experience people see and the systems supporting it.
The result is what we’re calling the enterprise comprehension gap.
And we’re describing the enterprise comprehension gap as the distance between how deeply an organisation depends on its technology environment and how effectively it can explain, trace and reconstruct how that environment works. It's an organisational problem, not a test of whether one employee understands the entire estate.
Visibility can tell a team which assets exist, what events occurred or where an error appeared. Comprehension goes further. It connects those signals to the business process, its dependencies, ownership, decision logic, permissions, recent changes and likely consequences.
An organisation can have extensive monitoring and still struggle to explain why a process behaved the way it did. Architecture diagrams and inventories help, but they're usually records of a particular moment. Live environments continue changing through application releases, infrastructure deployments, policy updates, SaaS changes, new integrations and automated decisions.
A static document can't maintain understanding on its own. The goal isn't complete knowledge of every technical detail. That would be unrealistic and probably not very useful. The goal is system traceability. When something changes, fails or produces an unexpected result, the organisation should be able to reconstruct the relationships that shaped what happened.
Understanding Has To Be An Organisational Capability
No chief information officer, architect or operations leader will ever hold the whole enterprise estate in their head. They shouldn’t need to. Modern technology depends on deep specialist knowledge across internal teams and outside providers. The organisational challenge is making those separate pieces available as one usable picture when they’re needed.
For a critical process, leaders should be able to answer several basic questions.
- What systems support it?
- Which providers does it depend on?
- Where are decisions and access controls applied?
- Who understands each component?
- What changed recently?
- What happens when one service becomes unavailable?
The answers can’t live only with one engineer, contractor or vendor. People leave. Suppliers change. Platforms evolve. A workflow built three years ago may still be running long after the original assumptions behind it have disappeared.
Maintaining organisational knowledge means connecting technical documentation with process ownership, operational history and business impact. Architecture, security, platform, operations, resilience and business teams each hold part of that knowledge. Comprehension comes from joining it together.
Five Questions That Reveal A Comprehension Gap
A useful assessment doesn’t need to begin with the whole technology estate. It can start with one business process the organisation can’t afford to lose.
Can we trace the complete dependency chain?
Start where the process begins and follow it until the outcome is complete. Record the internal systems, APIs, identity controls, automation tools and external providers involved. Separate what the organisation owns from what it only consumes. Then ask whether teams could reconstruct the same route after a failure.
Do we know where decisions are made?
Business rules may sit inside applications, policies, integration tools, automated approvals or AI systems. Identify which decisions are fixed, which depend on context and who can change them. A rule nobody knows exists can still shape thousands of transactions.
Is ownership clear across every layer?
Owning an application isn’t the same as owning the business process it supports. A critical workflow needs both technical and business accountability. External services should also have clear escalation paths before something goes wrong, rather than while several teams are trying to work out who has the right support contract.
Is critical knowledge distributed or concentrated?
Look for systems that only one person, team or supplier understands. Then consider what would happen if that knowledge suddenly wasn’t available. Current documentation, workable handovers and shared operational records reduce the risk of an important system becoming impossible to change safely.
Do we know when the system has changed?
Changes don’t only come through formal internal releases. SaaS providers update services. Permissions change. APIs are replaced. Integrations are adjusted. AI tools behave differently as models, prompts or connected information change. The organisation needs a way to connect those updates to the processes they affect.
Otherwise, diagrams and documentation slowly describe an environment that no longer exists.
Why Comprehension Is Becoming Part Of Resilience
Traditional resilience planning often focused on infrastructure the organisation owned. Critical services now cross public cloud, SaaS, identity providers, APIs, managed platforms and internet infrastructure. A provider can remain generally available while one feature the organisation depends on stops working.
Teams may see the operational effect long before they understand its cause. Cisco ThousandEyes found that outages observed during the first half of 2025 increasingly involved subtle functional failures and service degradation where symptoms appeared disconnected from the source of the problem.
That changes what recovery requires. Restoring a service isn’t only about bringing a server or application back online. Teams need to know what failed, which processes were affected, who controls the relevant component and what can operate safely while the dependency is unavailable.
The organisation may not own the service that failed. It still owns the consequences for its customers, employees and operations. That makes comprehension part of operational resilience. The faster teams can reconstruct the environment, the faster they can make informed decisions about containment, recovery and temporary alternatives.
Final Thoughts: Simplicity Still Needs Understanding
Enterprise technology works at its current scale because most people don’t need to understand every component underneath it. That shouldn’t change. Removing abstraction would make systems harder to use, slower to build and more expensive to operate.
Cloud services, SaaS platforms, automation and AI have created enormous value by handling complexity on behalf of the people using them. But the complexity hasn’t gone away. It has moved into platforms, integrations, external providers, specialist teams, automated rules and increasingly dynamic decisions.
The risk begins when dependency continues growing while the organisation loses the ability to trace what the experience depends on. Comprehension doesn’t require one perfect map or one person who knows everything. It requires connected knowledge that can be assembled when a process changes, an outcome needs to be challenged or a critical service fails.
The next stage of enterprise maturity may depend less on how much complexity technology can hide and more on whether the organisation can still reason about what sits behind the simplicity.
As those layers continue to multiply, EM360Tech will keep examining the systems, dependencies and operating choices shaping how organisations build technology they can rely on and still understand.
Comments ( 0 )