From Defined Domains to Organization Design

The Organizational Bridge

Edith A. Hughes, D.Sc.  ·  Adaptive Value Design LLC  ·  2026

I. Designing the Operating Model Structure

The foundational work this series describes in Articles 2 and 3 produces something genuinely valuable: a leadership team that sees its enterprise together. Federal executives who have worked through the Why, What, Who, and How of their agency’s value delivery emerge with a shared understanding they did not have before. They know what they exist to deliver, who their customers are, and how value flows through their system. That shared understanding builds a solid foundation for what needs to follow.

Shared understanding gives the leadership team the foundation to make organization design decisions with clarity and confidence. Shared understanding of what the agency exists to deliver does not by itself reorganize the agency around that purpose. It does not realign budget structures, redistribute decision authority, or reshape the technical architecture that has accumulated over decades. What it does is give the leadership team the clarity to take those actions deliberately, in the right sequence, and with a shared definition of the design.

In most federal agencies, the domains of work that deliver and enable the mission, the authority and accountability structures that govern decisions, and the technical architecture that supports operations have each been built with independent designs. They do not share the same structures, boundaries, and integration points. Like a car out of alignment, these differences slow decision-making and implementation, making it difficult to steer the organization. Mission priorities, organization design, and technical architecture each pull in a direction shaped by their own history rather than by the common purpose they exist to serve together.

This article examines that structural problem, why it persists, and what it takes to solve it. The solution has a name: structural isomorphism. It has a body of converging evidence behind it, from organizational theory, software architecture, investment management, and federal practice. The path from foundational alignment to structural alignment is the subject of Article 4.

II. An Agency CEO’s Four Questions

In 2024, the chief executive of a large federal agency was presiding over one of the most ambitious enterprise transformations in federal government history. A historic funding influx had created real opportunity. A consulting-firm “product and platform” operating model had been written into the agency’s Strategic Operating Plan. Consultants were engaged. Reorganizations were underway.

And the agency CEO had questions:

• Why is there so much friction between Business and IT?
• Why does it take so long to deliver technology solutions?
• What is the integrated picture that will help IT know what the transformation priorities are?
• How can we make business priorities more present as a driver of technology delivery?

Although he voiced these questions in the context of a specific transformation initiative, the questions themselves are not specific. They are the same questions that federal agency leaders have been asking, in different forms, for decades. They surface whenever a large organization attempts to modernize its technology without first addressing the structural conditions that govern how technology decisions are made, funded, and implemented.

Read as a diagnostic, the four questions point to the same underlying condition from four different angles. Friction between Business and IT is the symptom of misaligned structures. Slow technology delivery is the symptom of complex governance and misaligned authority. The absence of an integrated picture is the symptom of misaligned operating model elements. And when matrixed governance must work across different sets of boundaries and reconcile different priorities, decision-making and delivery implementation are delayed. The Agency CEO was not asking four different questions. He was asking one question, four different ways: why is our organization not aligned?

III. What the Questions Are Really Asking

In 1967, a computer scientist named Melvin Conway made a profound observation: organizations produce systems that mirror their communication structures. The architecture of a system reflects the architecture of the organization that built it, not because designers intend it to, but because the boundaries of communication determine the boundaries of design.

Ann Lewis and Jennifer Pahlka, writing for the Niskanen Center, have applied Conway’s Law to the federal government with precision and force. They make the case that federal agencies produce fragmented, misaligned technology systems because they are fragmented, misaligned organizations. Fix the organizational structure, and the systems will follow. The diagnosis is right. The solution is found through domain-driven design and striving for isomorphism. It tells you that structure and systems will mirror each other. It does not tell you what structure they should mirror, or how to achieve the alignment between the three distinct layers that need to be congruent.

Gene Kim and Steven Spear, in their book Wiring the Winning Organization, define isomorphism as the quality of related items having similar structures. Applied to organizations, the principle is this: the people who have authority to make decisions should also be held accountable for the outcomes of those decisions. Their scope of authority should align to the business domains they serve. And the physical and technical architecture they oversee should share the same boundaries as those domains. Three structures, one similar design.¹

When all three are congruent, value flows. Decisions are made by the people closest to the outcomes they affect. Technology investments align to mission priorities. Architecture reinforces accountability rather than cutting across it. The organization and its systems pull in the same direction — the direction of the mission and business strategy.

When these structures are not congruent, the Agency CEO’s four questions are inevitable. Friction between Business and IT is structurally guaranteed when technology authority is organized around one set of boundaries and business accountability around another. Slow delivery is structurally guaranteed when the people making technology decisions are insulated from the consequences of those decisions. The integrated picture cannot exist when mission domains, team structures, investment governance, and technical architecture have each been built to different designs. Conway’s Law tells you the mirror will form. Well-defined domains will tell you what shape the form needs to take.

IV. Mission Domains as the Starting Point

Before an agency can achieve structural isomorphism, its leaders must first agree on how to define the mission domains and subdomains. That agreement is not technical. It is a leadership decision, grounded in the statutory purpose for the agency. A mission domain is a coherent area of business capability through which an agency delivers a category of public value that is unique to the agency’s statutory purpose.

Within an agency’s operations, it has three types of sub-domains: core, supporting, and generic. A core sub-domain is a business activity that specifically supports the agency’s purpose. A supporting sub-domain is one that is critical to enabling the mission, but is not unique to the mission. A generic subdomain is one that is performed the same in every agency — the human resource, financial, and facilities management functions that are likely to be similar across federal agencies.

These sub-domains, when properly defined, are the meaningful areas of activity that can be further decomposed into value streams that are funded as a coherent investment and supported by an architecture that serves their specific requirements. Defining and correctly classifying the subdomains is the prerequisite for defining the other structures: value streams, organization design, team structure and empowerment, governance authorities and performance accountabilities, and technology investment all follow from clearly defining the domains, sub-domains, and boundaries.

Three independent disciplines have arrived at this same conclusion through different routes. Domain-Driven Design organizes systems around the business subdomains and bounded contexts that reflect the business domains they serve. The Technology Business Management discipline applies this logic to prioritize and inform technology investment decisions and track technology costs to business value delivered. Wardley Mapping plots capabilities along an evolutionary axis to identify which domains represent core mission differentiators, which are mission-supporting functions, and which are generic services that should be shared or outsourced. All three disciplines, developed independently, reach the same structural conclusion: the domain is the organizing unit.

One federal agency has demonstrated what this looks like in practice. USCIS undertook one of the most comprehensive operating model transformations in federal government history, influenced by Mark Schwartz, who served as CIO from 2010 to 2017. Schwartz was working with the agency leaders to realign all the elements that an operating model requires to function as a system: governance mechanisms, organizational accountability, service delivery practices, technology platforms, and performance measurement. By the time Schwartz departed in 2017, USCIS had demonstrated something the federal government had not previously shown at scale: that a highly regulated federal agency could align its governance, organizational structure, delivery practices, and technology architecture around mission service delivery streams rather than program structures.²

V. Embed Governance in Organization Design

Governance is frequently treated as a strategic function — something that sits above the organization and directs it. In federal agencies, this view manifests as layered approval bodies, interagency steering committees, and cross-functional working groups positioned at the top of the management hierarchy. The implicit assumption is that governance is about setting direction.

That assumption conflates two things that need to be kept separate. The outcomes of governance — including the institutional directions, priorities, mandates, and mission commitments that flow from authorized decisions — do belong at the strategic level. But the structure of governance — including who has authority to make which decisions, how those decisions are organized, what bodies are involved, and how accountability aligns to authority — is an organizational design question.

Matrixed governance bodies are optimized for representation and consensus. They are not optimized for decision velocity or delivery accountability. When no single person or team has both the authority to make a decision and the accountability for its outcome, decisions slow down, ownership diffuses, and friction becomes structurally inevitable. The person accountable for delivering an outcome must have the authority to make the decisions that determine whether that outcome is achieved.

Redesigning governance means redesigning that structure. It means aligning decision authority to the mission domains through which the agency delivers public value. It means replacing matrixed approval bodies — which distribute authority without distributing accountability — with clear ownership structures in which the team responsible for a value stream also has the authority to make the decisions that govern it. And it requires an executive team that is held jointly accountable for enterprise performance. That change is not a governance reform. It is an organizational design reform, and it is inseparable from how the organization is structured around its mission domains.

VI. Domain-Driven Design and Team Topologies: The Enterprise Scale Answer

Structural isomorphism gives the problem a name and prescribes the shape of the solution. Three structures — mission domains, decision authority, and technical architecture — must share the same boundaries. But naming the required shape is not the same as knowing how to achieve it. The disciplines that make isomorphism operational at enterprise scale are Domain-Driven Design, TBM as a discipline, and Team Topologies. Together they provide a practical framework for translating the structural principle into organizational and technical reality.

Domain-Driven Design, a concept developed by Eric Evans for software engineering, organizes systems around bounded contexts that reflect the business domains they serve.³ The core insight is that the language, logic, and ownership boundaries of a software system should be derived from the structure of the business it supports rather than from technical convenience or historical precedent. When a software system’s boundaries mirror its business domain’s boundaries, changes to the domain can be implemented without cascading disruptions across unrelated systems.

The TBM discipline extends this logic to investment decisions. Where DDD aligns technical architecture to business domains, TBM aligns technology funding, cost transparency, and investment prioritization to those same domains. That practice connects budget decisions to mission outcomes, makes the cost of delivering value by domain visible to leadership, and enables the kind of mission-aligned investment prioritization the Agency CEO’s four questions were implicitly demanding.

Team Topologies, developed by Matthew Skelton and Manuel Pais, applies the same domain-based design logic to team structures and across the organization.⁴ Its central argument is that team structure is not separate from system architecture — it is part of it. Teams should be organized around the streams of change that matter most to the mission, with clear ownership of the domains they serve, interaction modes designed to minimize cognitive load, and platform teams providing the shared capabilities that stream-aligned teams need without creating bottlenecks.

VII. The Federal Sequence and What It Makes Possible

The disciplines are powerful. Many organizations, across industries, have applied them successfully and at scale. The evidence base is substantial. The methodology is mature. And for federal leaders who have done the foundational work this series describes, they are directly applicable.

Directly applicable does not mean directly transferable. Federal agencies operate in a context that the private sector frameworks were not designed for, and applying those frameworks without accounting for that context produces the pattern Article 1 diagnoses: a model adopted without the foundation required to make it work.

Susanne Kaiser’s Architecture for Flow Canvas⁵ offers a precise illustration of both the value and the limits of leading private sector frameworks in a federal context. Kaiser’s Canvas integrates Wardley Mapping, Domain-Driven Design, and Team Topologies into a structured collaborative process for designing adaptive sociotechnical systems. It is rigorous, well-sequenced, and grounded in a decade of practitioner experience. It begins with users and their needs, maps the business landscape, categorizes domains by strategic importance, and derives team organization from the value streams that serve those users. For private sector organizations, that sequence is exactly right.

Federal agencies need two additional steps.

The first is statutory analysis. Federal agencies do not choose their missions. Their missions are assigned by law, and the boundaries of their domains are implicit in the authorizing language Congress used to create them. No amount of Wardley Mapping or domain categorization produces the right domain structure if it does not begin with the question Article 3 describes: why did Congress legally authorize this agency to exist, and what are they required to do? Kaiser’s Canvas starts with users. The federal sequence must start one step earlier, with the statute that defines who the users are and what the agency is authorized to deliver to them.

The second is the customer roles framework. Kaiser’s Canvas, like most private sector frameworks, is oriented primarily toward the consumer. Federal agencies serve Consumers, Producers, and Approvers simultaneously, and all three categories must be mapped into the system picture before domain boundaries can be correctly defined. Approvers are not external to the value stream. As the Census Bureau engagement demonstrated, Congress is an active participant in the oversight of the system, not a passive recipient of its outputs.

The federal sequence, then, runs as follows: Statutory analysis establishes the mission authorization and purpose. Mission definition translates that authorization into a shared statement of the public value the agency exists to deliver. Customer role mapping identifies the Consumers, Producers, and Approvers for each value stream. Domain definition and value stream mapping traces how value moves through the system and establishes the domain structure that will organize everything that follows. Executives need this foundation before they can apply Wardley Mapping, DDD bounded contexts, and Team Topologies team design tools to the design of the sociotechnical system.

This sequence extends Kaiser’s framework to make it fully relevant for the federal context. The Architecture for Flow Canvas is a powerful set of tools that federal agencies will be ready to use once the upstream foundational work has been done. The foundation ensures the Canvas produces systems organized around the right domains, serving the full picture of the customers they exist to serve, and grounded in the statutory authorization that gives the agency its legitimacy.