enterprise-design

A coherent metamodel for a Digital Enterprise Operating Model—connecting context, products, organization, capabilities, processes, information, digital solutions, assets, and governance without reducing the enterprise to a hierarchy of boxes.

The enterprise-service taxonomy divides first by delivery mechanism, then by primary consumer and promised capability across Digital and Human-Delivered Services.

Human involvement in a digital service can mean three different things — restoring a broken promise, extending it for one customer, or building capability outside it entirely — each with different economics and management responsibilities.

Four recurring digital-service types — Customer-Facing, Business-Enabling, Platform, and Infrastructure — classified by primary consumer and promised capability, and how the DSLC Model varies its approach according to service purpose.

A seven-layer model — Offering, Interface, Application, Platform, Virtualization, Hardware, Data Center — for understanding what a digital service offers, how it is consumed, why its boundary can stop at any layer, and how commercial labels like SaaS, PaaS, and IaaS describe what's exposed at that boundary rather than everything behind it.

Position, role, and capability are not synonyms — each belongs to a different owner and fails in a different way when misread. This post defines the three, maps how they interact, and identifies three distinct gaps that emerge when they fall out of alignment: a compensation problem, an enterprise delivery problem, and a personal one that only the individual can resolve.

Every IT organization has an operating model — the question is whether you designed it or it designed you. Without intentional design, teams default to informal networks, ownership gaps, and structural failure modes that no amount of good hiring or better tooling will fix.

After working with various organizational models—from matrix structures to Team Topologies—I've discovered a pattern that emerges when organizations successfully implement team-based frameworks: they converge on X-as-a-Service as their primary interaction mode and evolve toward five distinct service types. This approach reduces coordination overhead, creates clear team boundaries, and enables genuine autonomy while maintaining system coherence. The fifth service type—Stewardship Services—treats enterprise design itself as a consumable service, filling a critical gap that becomes apparent at scale.

This post challenges the dominance of the architectural metaphor as the primary lens for enterprise design and explores more dynamic alternatives. By examining how metaphors shape our thinking, we consider machines (emphasizing efficiency), ecosystems (highlighting interdependence), cities (balancing design with emergence), and ultimately gardening as a framework that naturally resolves tensions between structure and adaptability, control and autonomy, stability and innovation. Rather than providing definitive answers, the post cultivates questions about how shifting metaphors might transform leadership approaches, team dynamics, and organizational capabilities to better address the complex challenges facing modern enterprises.

Enterprises function as systems where intentional design of operating models, interfaces, and feedback loops can dramatically reduce coordination overhead, accelerate decision-making, and create sustainable competitive advantage.