I deliberately speak of architectural decisions and design criteria. Autonomy does not reside in a single decision, nor in a single architectural layer. Rather, it emerges through the accumulation of design choices over time. This makes autonomy a challenging topic in the governance of digital transformation.

Design and Governance
In practice, digital systems are never neutral. They determine how processes are structured, where decision-making takes place, and what forms of dependency emerge. As a result, they do more than merely support the organization—they also shape the way it functions.

Many organizations evaluate IT decisions based on immediate criteria such as functionality, cost, and time-to-market. These are logical and necessary considerations, but they overlook an important question: what does this choice mean for the organization's ability to adapt, replace, or redesign later on? The answer to that question can be decisive for an organization's future effectiveness.

Digital autonomy should therefore be a dimension that is considered in every make-or-buy decision.

From Vendor Lock-In to Dependency Networks
The discussion around digital autonomy is reminiscent of the debate on vendor lock-in, but it is more complex. The traditional notion of vendor lock-in provides only a limited view of reality, because dependency in modern digital environments is less concentrated and far more distributed.

Organizations operate with a combination of cloud platforms, identity services, SaaS solutions, data platforms, and integration layers. These components do not exist in isolation; together they form a network in which functionality, data, and management are tightly interwoven.
Dependency is therefore embedded in the architecture itself, not merely in contracts or individual supplier relationships. As a result, it is less tangible, yet highly influential in determining an organization's strategic freedom of action.

Efficiency and Strategic Flexibility
Many choices in digital architecture can be readily explained by efficiency considerations. Standardized platforms, managed services, and integrated suites help reduce complexity—effectively outsourcing it—and accelerate delivery.

However logical this outsourcing of complexity may be, it also removes part of the organization's design capability and capacity for change. The challenge is that this effect is rarely visible in a single decision. It emerges gradually, as the cumulative outcome of individual optimizations that each make perfect sense on their own, but collectively may restrict the organization's room for maneuver.

Autonomy Is Not Independence
Digital autonomy is sometimes interpreted as striving for independence from vendors or technologies. In practice, this is neither realistic nor necessarily desirable. Modern organizations operate within ecosystems of platforms and specialized services.

The essence of autonomy, in my view, lies in how those dependencies are structured. Can you still adapt when circumstances change? Can you replace components without putting the entire system under strain? And does sufficient design freedom remain to make new choices without becoming trapped by previous decisions?

Autonomy is therefore less a state of being and more an architectural characteristic: the extent to which movement and flexibility remain possible within a network of dependencies.

Implications for the CIO Office
When digital autonomy is viewed through this lens, the role of the CIO Office changes. Managing systems as isolated entities becomes less of a priority, making way for steering coherence and monitoring dependencies across the landscape.

This requires decision-making to focus on additional considerations. Not only whether a solution works and what it costs, but also what its structural impact will be on the enterprise architecture.
The architecture function thus becomes—or should become—an integral part of strategic governance, addressing questions such as: Which dependencies are being strengthened or reduced? And what do those changes mean for future adaptability?

Part of Good Design
Digital autonomy rarely disappears because of one major decision. More often, it is the result of a sequence of smaller, rational choices, each of which is individually defensible.
The challenge for CIOs and CIO Offices is therefore not to add autonomy to the agenda as a separate objective, but to incorporate it into the decisions they make—as an inherent element of good design.

Not everything needs to be fully autonomous. Yet through every decision—from governance to data architecture—an organization can determine the degree of dependency it is willing to accept.

Feel free to contact Thijs Willems if you have any comments or questions.