In nearly every organization, the same gap appears in different forms: the executive wants one thing, and the IT team understands something else entirely. Both sides speak in good faith. Both are professionals in their own domain. Yet between them stands an invisible wall — one with a name, a history, and a story that spans half a century.
Picture this scene. An executive asks for a report on branch performance. The systems analyst responds with a barrage of questions: Which database? Which metric? Which time period? Do you mean financial or operational performance? The meeting ends in mutual frustration. The executive thinks IT complicates simple things. The analyst thinks the executive doesn’t know what they want. Both are wrong, and both are right, at the same time.
This isn’t a rare problem or a personal misunderstanding. It’s an institutional phenomenon — studied by academics, written about by practitioners, responsible for entire university disciplines, jobs that didn’t exist before, and successive waves of intellectual and operational frameworks.
In this article, we’ll take a journey through the history of this gap: from its birth in the 1980s, through the wave of professional roles created to address it, to the academic disciplines born from its womb, and finally to the present moment — where the gap is splintering into dozens of smaller gaps, and new frameworks like DevOps, MLOps, and FinOps emerge in response.
The central question this journey will answer: Why, after half a century of technology, are we still complaining about the same problem under new names?
The birth of the gap — three waves of transformation
Before we can understand the gap, we need to understand when it appeared. The short answer: it didn’t emerge overnight. It grew gradually through three waves of technological change.
Wave one: the age of priests (1960s–70s)
In this era, IT consisted of massive mainframes housed in sealed, air-conditioned rooms, managed by a small group of specialists. IT was closer to a priesthood than a service department. Management would submit a request on paper, then wait weeks for a printed report.
At that time, “the gap” wasn’t painful — because expectations of IT were low. Management didn’t really know what the new technology could offer them, and IT was handling very specific accounting tasks.
Wave two: the personal computer explosion (1980s)
The 1980s brought the great shift. The PC spread everywhere, and every department began building its own system: sales had a system, the warehouse had a system, finance had another. Data multiplied, but it scattered.
Management started asking new questions: “How many active customers do we have?” — and got three different answers from three different departments. This is when the gap began to genuinely hurt, because expectations rose while reality grew more complex.
The moment of academic awareness (1987–1995)
Between these years, the problem received an official name and a scientific vocabulary, and academic framing began.
1987 — The Zachman Framework. John Zachman published his famous paper in IBM Systems Journal, presenting the first systematic framework that connected the perspectives of different stakeholders — from executive to programmer. Zachman argued there is no single “architecture” for information systems, but a set of architectures. What the programmer sees differs from what the manager or analyst sees, and they’re all correct.
1993 — Henderson & Venkatraman Model. This model argued that an organization’s success in the technology era isn’t achieved through a two-way alignment between business and IT, but through aligning four domains together: business strategy, IT strategy, organizational structure, and technical infrastructure — with vertical harmony between each strategy and its execution, and horizontal harmony between the worlds of business and technology, in a continuous dynamic motion rather than a single moment.
1995 — The TOGAF Framework. The first major practical framework for enterprise architecture appeared, translating alignment theory into actionable steps. TOGAF is a “roadmap” guiding an organization to build itself in an organized way — starting from “why are we here?”, then designing its business, data, systems, and technology in a logical sequence, executing change and measuring it — so the organization doesn’t devolve into chaos of scattered systems and decisions.
What did the gap look like in daily life?
To make the problem concrete, the gap manifests on the ground in five recognizable symptoms — familiar to anyone who has worked in a medium or large organization.
1. Projects that fail after they’re completed. The famous Standish Group CHAOS report in 1994 revealed that more than 70% of IT projects fail, exceed their budget, or exceed their schedule. Strikingly, the failure usually wasn’t technical. The systems worked — they just didn’t do what business stakeholders actually wanted.
2. Two languages in one meeting. The manager says: “I want to grow our market share.” The programmer responds: “Okay, what are your tables and columns?” Both know what they want, but no shared language exists between them. The manager speaks the language of objectives; the programmer speaks the language of execution.
3. IT as a cost center, not a partner. IT gets called in after the strategic decision is made, not before. They’re told “execute this,” instead of “help us decide.” The result: patched solutions for every decision, and inflated numbers in every budget.
4. Conflicting information silos. Sales says there are 10,000 active customers. Marketing says 8,000. Finance says 12,000. They’re all correct! The problem is that “active customer” means something different in each department, and no single party is responsible for unifying the meaning.
5. Shadow IT — silent resistance. When employees lose trust in the official IT department, they build their own solutions: complex Excel files, Access databases, SharePoint tables. The work gets done — but a parallel data chaos grows outside any control.
Each of these symptoms demanded a remedy. And the remedy came in two successive waves: a wave of professional roles that invented intermediary jobs between the two worlds, then a wave of academic disciplines that established university programs to systematically produce these intermediaries.
The wave of new roles — bridges between two worlds
The first and most natural solution was creating intermediary roles: people who spoke both languages, attended management meetings and understood, attended programmer meetings and understood, and carried meaning from one side to the other without loss. Tracing these roles in order of appearance reveals how our understanding of the gap itself evolved.
- Systems Analyst The grandfather of all intermediary roles. Emerged in the 1970s with mainframes. The job: convert user needs into executable technical specifications. The focus was more technical than managerial — which would later create the need for a role closer to management.
- Chief Information Officer (CIO) The first IT executive to sit at the boardroom table. The job isn’t purely technical, it’s strategic: linking IT investments to organizational goals, and translating management needs into a technical roadmap.
- Business Analyst Standing right in the middle, between the two worlds. They understand the language of management (processes, objectives, KPIs) and the language of IT (requirements, systems). Their core mission: requirements elicitation and documentation in an executable form. This role emerged to overcome the managerial limitations of the systems analyst.
- Enterprise Architect The whole-organization view. Works across four interconnected layers: business architecture, data architecture, application architecture, and technical architecture. Their mission: ensure the four layers are aligned and harmonized with the organization’s overall strategy.
- Data Steward Not a technical role, but a governance role. Responsible for ensuring the quality, meaning, and integrity of a specific set of organizational data. The guardian of unified definitions. Example: a customer data steward ensures that “active customer” means the same thing across sales, marketing, and finance — and that the data is clean and trustworthy.
- Chief Data Officer (CDO → CDAO) Data as a strategic asset. The first person to hold the CDO title was at Capital One in 2002. The role spread strongly after 2010 with the big data wave. After 2015 it evolved into CDAO — encompassing data, analytics, and AI under one leadership.
- Product Owner The agile version of the business analyst. Represents the customer’s voice inside the development team, and prioritizes features week by week.
The wave of disciplines — when academia responds
Roles and jobs alone weren’t enough. Organizations needed thousands of these intermediaries, and universities weren’t producing this kind of graduate. Business specialists came out of management schools. Technologists came out of engineering or computer science. So who would produce the person who understood both?
This is where universities stepped in, establishing a set of hybrid disciplines that combined the worlds of management and computing.
Management Information Systems (MIS) — the parent discipline. The first academic MIS department was founded at the University of Minnesota in 1968. The core idea was simple and ahead of its time: if companies need people who understand both management and computing, let’s create a hybrid discipline that studies both. The MIS graduate understands organizations, processes, and management — and at the same time understands how systems and databases work. The discipline goes by different names at different universities (Information Systems, Business Information Systems, Computer Information Systems), but the essence is the same.
Wirtschaftsinformatik — the German school. In the 1970s, German-speaking universities (Germany, Austria, Switzerland) developed a parallel school. What distinguishes it from American MIS is that it goes deeper technically — graduates can program and design systems at a level close to a software engineer, with full management understanding. This model later spread in English as Business Informatics, becoming Europe’s preferred discipline for bridging the two worlds.
Enterprise Architecture. In the first decade of the 2000s, after TOGAF and Zachman matured, some universities began offering standalone master’s programs in enterprise architecture — an advanced specialty for architects designing the big picture of large organizations.
Data Science and Business Analytics — a new wave. William Cleveland used the term “Data Science” in 2001, but the academic discipline truly flourished after 2010 with the explosion of big data. In the same period, specialized master’s programs in Business Analytics emerged (such as those at MIT and NYU Stern) to bridge a new gap: between data scientists and managers.
Universities don’t produce disciplines from a vacuum — they follow gaps. Every major institutional gap eventually produces, a few years later, a new academic discipline to graduate the people who will fill it.
From annual alignment to daily agility
Until the late 1990s, the conversation about “alignment” took place at the high strategic level: an annual meeting between the CEO and CIO to set the year’s plan. That was sufficient when markets moved slowly.
But at the start of the new millennium, the internet rewrote the rules. It was no longer enough for strategy to be aligned once a year. Markets shifted monthly, then weekly, then daily. Digital competitors emerged launching new features every week, and users expected continuous updates to their applications.
A different kind of alignment became necessary: daily operational alignment, not annual strategic alignment. This radical shift gave birth to an entirely new philosophy, formally announced in the Agile Manifesto of 2001, which forever changed the shape of software development.
The era of X-Ops — when the gap fragments
This is where we reach the most important shift in the story. The original gap was vertical: between management (above) and technology (below). But as technology itself grew more complex, new horizontal gaps appeared within technology — between different technical teams, each speaking a different language. The battle was no longer in the management conference room, but in the depths of the engineering rooms.
Yet the spirit of the response remained the same: tear down barriers, unify language, link technology to business value. Only the field had changed.
DevOps (2009) — the first wave. The term emerged after Patrick Debois’s session at the DevOpsDays conference in Belgium. It addressed a chronic gap inside IT itself: developers (Dev) want fast releases and continuous change, while operations (Ops) want stability and reduced risk. The result before DevOps: cultural conflict, delayed releases, and blame-shifting. The developer threw code over the wall to operations and washed their hands of it. Operations threw it back with complaints. Although this gap was internal, it translated to management as: “Why is the feature 6 months late?” and “Why did our site crash at peak sales?” In other words, the Dev-Ops gap was one of the causes of higher-level strategic alignment failure.
MLOps — the 87% shock. With the AI explosion, a devastating new gap emerged. Data scientists were building excellent models in Jupyter Notebooks, while production engineers couldn’t reliably run those models in real environments. The shock came from a VentureBeat statistic published in 2019: more than 87% of data science projects never reach production. Organizations had invested billions in hiring data scientists between 2012 and 2018, only to discover the ROI was nearly zero — models stayed locked in laboratories. MLOps emerged to say something simple and decisive: “We won’t consider an AI project successful until it generates continuous operational value.” This is precisely the essence of strategic alignment philosophy — but in 21st-century language.
The full X-Ops family. What started with DevOps became a unified intellectual pattern. Every time a new gap appears between technical teams, a new framework is born to bridge it.
Notice FinOps specifically. This framework is conceptually closest to the classic Business-IT gap, because it explicitly addresses miscommunication between engineering and finance teams around cloud costs. The gap returned through its original door: between money and technology.
The common thread — one philosophy across half a century
After this entire journey, from Zachman in 1987 to LLMOps in 2023, the scene may look crowded with names and terms. But when you step back and look at the full picture, you see that all these roles, frameworks, and disciplines follow a single philosophy, applied in different forms depending on the nature of the gap.
- Break down barriers Whether silos between departments or between teams. The first step is always tearing down walls.
- Unify the language Create shared terms and meanings that everyone uses the same way.
- Connect technology to value No technology for technology’s sake. Every technical investment must translate into tangible business value.
- Build human bridges Intermediary roles whose sole purpose is translation between worlds.
- Measure success in business metrics No technical success without commercial success, and vice versa.
What appears as variety in names and tools is, at its core, different applications of one idea: the more complex the technology becomes, the more gaps multiply, and the more new bridges are needed to span them.
The gaps to come — what awaits us?
History teaches us that gaps don’t end — they transform. The original gap between management and technology has shrunk significantly, but new gaps are emerging, each likely to require a new role, a new framework, and perhaps a new academic discipline.
The AI–Governance gap. AI teams build powerful models, but compliance and ethics teams later discover those models carry biases or violate privacy. The new gap: between what can be done technically and what should be done ethically. New roles are emerging like AI Ethics Officer and Responsible AI Lead.
The AI–Business gap. Organizations adopt AI without a clear understanding of what they want from it. They buy expensive tools without a use plan. Here the Analytics Translator role emerged, championed by McKinsey since 2018, alongside the AI Product Manager.
The organizational knowledge gap. With the spread of large language models, a strange paradox appeared: ChatGPT knows less about your company than your newest junior employee. How do we make AI understand our organization’s specific context? A new discipline is being born called Enterprise Knowledge Engineering.
The data–privacy gap. The tension between leveraging data for smart decisions and protecting individuals from privacy violations has become a full institutional gap, giving rise to roles like Privacy Engineer and DPO (Data Protection Officer).
The question every organizational leader should ask today is not “What’s the latest technology I should adopt?” but rather: “What new gap is silently growing inside my organization right now?”
Four lessons for today’s practitioner
After half a century of this story, what do we take with us?
- The gap isn’t a flaw — it’s a feature Every technical advance generates a new gap. The right question isn’t “How do we avoid it?” but “How do we close it quickly before it destroys our investments?”
- Intermediary roles are an organization’s treasure The analyst, the translator, the architect, the data steward — these people represent the difference between a successful tech investment and a failed one. Invest in them before you invest in tools.
- Don’t import a framework without understanding the gap it was made for Implementing MLOps in an organization that doesn’t have a single AI model in production is form without substance. Every framework was born to address a specific pain. Understand the pain before adopting the cure.
- Watch the gaps, not the trends Smart organizations don’t chase the latest buzzword. They ask themselves: “Where is the real gap inside my organization, and what bridge fits it?” Trends change every year. Gaps change every decade.
And finally…
The story of the gap between business and IT is not the story of a problem solved once. It’s the story of an ongoing phenomenon that renews itself with every new technology wave. Whoever understands this story understands the real secret of digital transformation: it isn’t in the tools — it’s in the bridges we build between people.
This article was edited and refined with the help of AI.