When Enough Is Not Enough: The Work-Enablement Problem
A modern technology environment can contain hundreds of applications, platforms, and infrastructures without necessarily making work more effective. As technologies accumulate, complexity, redundancy, dependencies, technical debt, and maintenance costs can grow alongside them. The real measure of technological maturity is therefore not how much technology exists, but whether the environment provides the right capabilities at a sustainable level of quality, relevance, integration, reliability, and cost. As needs evolve, technologies must be continuously evaluated—not only added and maintained, but also consolidated, replaced, or removed.
FIG 1.0 Delivering yet another new solution
When a problem occurs, we naturally need to solve it. Perhaps using what is available is complex and would require us to rework part of the solution. A simple option is to use readily available tools capable of solving our problem. This has become a commodity and one that will be expensive in the long run.
Related Insights
Productivity Is Not What We Think It Is
It Is Time to Return Engineering to Engineers
Agile: The Theory, the Ritual, and the Reality
MXI.STUDIO EDITORIAL
Innovation | Platform | Software | Design
The MXI.Studio Editorial is a collection of articles, ideas, and reflections written by the people behind MXI.Studio. We explore emerging technologies, innovation, industry trends, and the current challenges of an ever-evolving world.
Work-Enablement
A n organization can own hundreds of applications, dozens of platforms, a multitude of infrastructures and a very modernized technology portfolio, all while encountering a very simple problem: all this setup doesn’t necessarily provide a better ability to work.
The number of technologies deployed does not, in itself, constitute a measure of the quality of the technology environment. Research in information systems has long shown that the value of a technology depends, among other things, on how well it fits the tasks it is intended to support, on its quality, and on its actual use. The Task-Technology Fit model, in particular, establishes the role of the fit between the characteristics of a technology and the requirements of the tasks it supports.
It is within this space that work-enablement sits: not how people organize their work, but the quality of the technological means provided to make that work possible.
-
technology
-
capability
-
value in use
Several different technologies can provide the same capability, while a technology rich in features can provide relatively little value when it is poorly suited to the need.
"Possessing a technology or a platform does not equate having more capabilities or benefitting from it"
The problem doesn’t really start with bad technology
A technology can be well suited at the time of its acquisition and become progressively less adapted over time. The need evolves. The architecture changes. Another platform emerges. Security requirements are transformed. A functionality that was once rare becomes available elsewhere. Dependencies on the initial system are created.
The problem is not necessarily that the technology has become unusable. It may continue to work as intended. It can even remain critical. The problem is that a technology can continue to be maintained long after the conditions that justified maintaining it have changed.
Research on legacy systems shows precisely this difficulty. A study published in MIS Quarterly on the replacement of a legacy system describes how organizations can remain locked into technical environments that are difficult to replace because of dependencies, past investments, and the sociotechnical mechanisms that have developed around the system.
The persistence of a technology is therefore not only a technical question. It becomes a question of portfolio, dependencies, and the cost of transformation.
What This Enables. A user could, for example, benefit from:
The debt is not only in the code
Accumulation increases all types of debt and affect performance.
Technical Debt
The implied cost of additional rework caused by choosing an easy, short-term solution now instead of a better approach that would take longer.
Architectural Debt
The exponential cost of reformatting, changing, or eliminating core structural decisions once legacy traces become deeply embedded across systems.
FIG 2 — The workplace when it is overbearing, impossible to manage anymore. We don't even know where things are anymore.
The term technical debt is generally associated with code, aging infrastructure or development compromises. Scientific literature is broader. A synthesis study examining 94 publications distinguishes between several types of technical debt and shows that the concept extends across different artifacts and consequences resulting from deferred technical compromises.
This distinction is important for an enterprise environment.
A platform can create a future maintenance burden. An integration can become costly to modify. A technology can require skills that have become scarce. Two solutions can provide similar capabilities while imposing two different environments to secure and maintain.
From this perspective, the problem is not simply the age of a technology. It lies in the future cost of accumulated technical decisions. A reasonable decision can therefore become debt when it continues to generate costs, constraints or dependencies long after its initial benefit has diminished.
When complexity becomes a capability to maintain
"Technological complexity also carries a cost of its own."
An empirical study published in Management Science analyzed 23 applications and 29 improvement projects within an enterprise IT environment. The results show, among other things, a link between certain development practices, increasing software complexity and the effort required for evolution and maintenance.
The principle is broader than any particular software environment: a technically more sophisticated solution is not automatically a more effective solution from an organizational perspective. Complexity adds elements to understand, test, integrate, monitor and evolve.
The technological environment must therefore be evaluated not only according to what it can do, but also according to what must be maintained for it to continue doing it.
When designing system architecture, the primary goal is striking a balance between functional utility and the cost required to make that system portable across different environments. Evaluating these two factors along the same continuum reveals three distinct operational zones:
-
Under-Capability where we prioritize extreme portability or minimal overhead at the expense of feature richness
-
Balanced where we value portability and functionality providing genuine deployment flexibility without introducing unnecessary overhead.
-
Over-Complexity where we add so much hyper-flexible abstractions that exponentially inflates engineering and operational costs, while yielding negligible increases
The problem of accumulation
One of the most noticeable phenomena in modern technological environments is accumulation.
A new solution is added to deal with a particular need. Another is introduced because it offers better specialization. A third one arrives through an acquisition. A fourth is adopted because the team already possesses the corresponding skills. Taken one at a time, these choices can be perfectly sensible. The problem appears when all of these decisions are considered simultaneously.
An enterprise architecture can then contain several applications covering similar functions, several integration mechanisms, and several technologies addressing needs that partially overlap.
The question then becomes less “which tool should be added?” than “how many equivalent capabilities does the environment already carry?”
Application portfolio management is precisely an answer to this problem. McKeen and Smith describe portfolio management as an ongoing process of categorization, evaluation, and rationalization used to decide which applications should be maintained, invested in, replaced, or retired. This logic changes the perspective: a technology is no longer just an acquisition. It becomes an asset with a lifecycle.
A few choices were deliberately kept very close to yours: “taken one at a time,” “the problem appears,” and “all of these decisions.” I changed “during acquisitions” to “through an acquisition” because it is more natural English in this context, and “competences related to it” to “the corresponding skills,” which is the normal English expression.
More technology, but not necessarily more value
The relationship between technological investment and value is also more complex than a simple calculation of volume. Brynjolfsson and Hitt show, based on case studies and firm-level data, that the value of IT investments depends heavily on complementary organizational investments and that the benefits of information technologies can be difficult to measure directly. This leads to distinguishing three things that are often confused:
-
having a technology
-
having a capability
-
and obtaining a benefit
These three levels are not equivalent. The first is immediately observable: the platform exists. The second requires checking whether it actually provides the desired capability. The third requires establishing whether this capability actually produces the expected benefit.
This is also why usefulness and ease of use remain fundamental dimensions. Davis's work established and validated perceived usefulness and ease of use as important determinants of information technology acceptance.
A capability that is technically available but difficult to use, of little relevance, or poorly adopted therefore does not necessarily constitute a capability that is effectively available.
The digital environment as a portfolio
As the number of systems increases, the relationship between these systems starts taking as much importance as the systems themselves. Works on the complexity of information systems architecture show that architectural complexity constitutes a measurable dimension of the technological environment and can affect properties such as flexibility, transparency and predictability.
The same phenomenon appears in the dimensions of quality. The ISO/IEC 25010:2023 standard defines a quality model covering, among other things, characteristics that allow the quality of software products and computer systems to be specified, measured and evaluated throughout their lifecycle.
Security must also be considered as a property of the system and of its lifecycle. The NIST SP 800-160 framework explicitly addresses security, integration, resilience, architecture and lifecycle management within a secure systems engineering approach.
In a very large environment, each additional component can therefore become an additional element to integrate, maintain, secure, evolve or eventually remove.
Another question to ask
The central question of work-enablement is ultimately not to determine whether a company has enough technology. It is to determine whether the technological environment provides the right capabilities, with a sustainable level of quality, relevance, integration, reliability and cost.
This distinction opens a much broader field than technical debt alone. It naturally leads to the problems of over-engineering, accumulation of the technology stack, functional redundancy, fragmentation, underutilization, integration complexity, legacy technologies, hidden costs, security, reliability, scalability and rationalization.
All of these problems have one thing in common: they concern less the absence of technology than the composition of what is already there.
FIG 3 - Part of the cycle is also removal. And it shouldn't be complex part of the cycle.
We often see it, even at a personal level, adding tools, adding something to solve a particular problem is for some people a reflex. What we don't see much is integrating and knowing when something is due.
Conclusion
The real challenge of work-enablement is therefore not to build the largest technological environment possible. It consists in maintaining an environment in which every technology has a clear justification, every capability addresses an identifiable need, and every component can be evaluated according to its value, quality, cost and evolution over time.
Modernization is not only about adding something new. Technological maturity also means knowing how to evaluate, consolidate, replace and remove. This is the starting point of this series: understanding what happens when a company continues to add capabilities without sufficiently reassessing the ones it already has.
Because at a certain point, the problem is no longer knowing what can still be added. The problem becomes knowing what still deserves to remain.