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.

It is not, by itself, enough.

Federal executives can leave a foundational engagement with perfect alignment on what their agency exists to deliver and still return to an organizational environment in which the structures surrounding them make delivering it nearly impossible.

The structural problem is this: in most federal agencies, the domains that define the agency’s mission and core activities, the authority and accountability structures that govern how decisions are made, and the physical and technical architecture that supports operations have been built independently of each other. They do not share the same boundaries. They do not mirror each other. And when they do not, the friction that results is not a people problem or a culture problem. It is an organization design problem, one that no amount of product thinking, agile delivery, or empowered teams can overcome at enterprise scale.

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 intentional design and implementation of an aligned operating model structure can accelerate and scale the adoption of a product operating model in the federal government. The path from foundational alignment to structural alignment is the subject of this article.

II. An Agency CEO’s Four Questions

In 2023, 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: mission domains and technical architectures that were built around different organizing principles and have never been reconciled.
• Slow technology delivery is the symptom of complex governance and misaligned authority: when the teams who are accountable for mission outcomes do not have the authority to make technology investment decisions, delivery priorities are not aligned.
• The absence of an integrated picture is the symptom of misaligned elements of an operating model: no one can show the relationship between the agency’s mission priorities and its technical investments because the two have never been mapped to the same domain structure.
• 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?

That question has an answer. It begins with a concept that software architects have known for decades and that organizational designers are only beginning to apply at scale.

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. But Conway’s Law, as typically applied, describes the problem without fully specifying the solution. 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. It does not tell you how to structure a product operating model at scale.

That is where domain-driven design and the concept of isomorphism enter.

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. Defining domains tells you what shape it needs to take.

IV. Mission Domains as the Starting Point

Before an agency can achieve this 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 value that is unique to the agency’s statutory purpose. For example, the core purpose of the State Department’s Bureau of Consular Affairs is to oversee and direct the consular functions of the United States, including passport services, visa administration, and protection of U.S. citizens abroad.

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. Continuing the Bureau of Consular Affairs example, the passport services would be one subdomain, visa administration would be another, and the various consular services that support and protect U.S. citizens abroad would be other subdomains. A supporting sub-domain is one that is critical to enabling the mission, but it is not unique to the mission. For example, a system that manages the flow for passport approval and issuance is critical to the Consular Affairs mission and may require custom configuration; the supporting case management capability itself is not unique to Consular Affairs. A generic subdomain is one that is performed the same in every agency. For example, the human resource, financial, and facilities management functions that support the Bureau of Consular Affairs or the Department of State overall are likely to be similar to the same functions in other 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 into portfolios (i.e., core, supporting, and generic) is the prerequisite for defining the other structures: value streams (e.g., the end-to-end flow of work that delivers value to customers through products or services²), 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, developed for the software engineering discipline, organizes systems around the business subdomains and bounded contexts that reflect the business domains they serve. The terminology, the logic, and the ownership boundaries of the software system are derived from the language and structure of the business it supports — as defined by the business domain experts. The Technology Business Management (TBM) discipline applies this logic to prioritize and inform technology investment decisions and track technology costs to business value delivered. Where DDD aligns technical architecture to business domains, the TBM discipline aligns technology funding, cost transparency, and investment prioritization to those same domains. Wardley Mapping, a strategic visual mapping technique, 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. Get the domains right, and the rest of the architecture and organization design follows.

For federal agencies, however, the starting point to defining domains begins with translating statute to domains. The boundaries of a federal agency’s domains are implicit in the language Congress used to create it, define its mandate, and establish its authorities. Identifying those domains begins with the statutory analysis Article 3 describes: reading the authorizing language together, as a leadership team, and deriving the domain structure from what Congress authorized instead of from the organizational history that has accumulated since. Clarifying which domains are core to mission, which are mission-supporting, and which are generic across federal agencies, is key to applying the disciplines.

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 of U.S. Citizenship and Immigration Services from 2010 to 2017. Schwartz was not simply introducing agile methods into an existing structure. He 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.

The shift across all six dimensions is documented.³ Governance moved from program stage gates and compliance reviews toward continuous operational stewardship of digital services, with decision authority moving closer to delivery teams within defined technical guardrails. Organizational structure moved from separate functional silos toward persistent cross-functional service teams with end-to-end accountability for design, build, deployment, and operations.

Service delivery moved from 18-month release cycles toward multiple deployments per week through continuous delivery pipelines. Technology moved from traditional data centers toward cloud infrastructure and self-service platforms that enabled rapid experimentation. Performance measurement moved from program schedule and budget compliance toward operational service metrics: deployment frequency, system availability, cycle time, and user adoption. And customer insight moved from system design driven by internal administrative requirements toward user-centered design for immigration applicants and adjudicators alike.

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 instead of program structures. The agency continued the journey, and by 2019 USCIS leadership was presenting at agile and value stream conferences using the functional language of a product operating model. The USCIS transformation is not a completed project. It is a continuing evolution that has now spanned more than a decade, which is itself evidence that the approach is durable rather than cosmetic. Federal operating model transformation cannot happen with a big bang, or an unfreeze-change-refreeze approach. It requires a foundation, and a leadership team willing to build on it iteratively over time.

USCIS demonstrates what structural isomorphism looks like when applied in a federal context. The domains are there. The alignment is achievable. The evidence is in the official record. What is required, as Article 2 argues, is having a leadership team that is willing to work together to redesign the operating conditions.

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 that are positioned at the top of the management hierarchy and consulted before major decisions are made. The implicit assumption is that governance is about setting direction.

That assumption conflates two things that should 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. They shape what the organization is trying to achieve and why. 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. Treating it as a strategic question rather than a design question can create a significant obstacle to successfully scaling a product operating model.

The reason is straightforward. High-level, 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. When authority and accountability are separated, the organization produces exactly the dysfunction that separation guarantees.

The large federal agency transformation described earlier illustrates what the dysfunction looks like in practice. The CIO had authority over technology decisions and priorities while the business units had accountability for mission outcomes. Neither owned both. The result was the CEO’s four-question diagnostic: friction between Business and IT, slow delivery, no integrated picture, business priorities failing to drive technology. These failures were the structural outputs of a governance design that separated authority from accountability across an organizational boundary that no amount of product thinking could bridge.

This condition is why the Deputy CIO’s diagnosis, developed with the Senior Technical Advisor on the business side, never reached the Agency CEO. It was not that the right insights were absent. It was that the organizational design had created a matrixed governance structure that maintained a risk-averse, process-compliance culture that inhibited new ideas from gaining visibility and consideration.

Redesigning governance means redesigning its structure. It requires aligning decision authorities to the mission domains through which the agency delivers public value. It means organizing decision rights around the same boundaries as delivery accountability. It means replacing matrixed approval bodies, which distribute authority without distributing accountability, with clear governance structures that give teams who are accountable for value stream outcomes the authority to make the decisions that enable those outcomes. And it requires an executive team that is held jointly accountable for enterprise performance. That change is more than a governance reform. It is an organizational design reform, and it is inseparable from how the organization structures its teams around its mission domains.

The system structure determines the outcome, not the people.

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, including 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. When they do not mirror each other, every change becomes a negotiation across boundary lines that were never designed to align. Strategic domain-driven design applies this concept to organization design.

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. When mission domains, technical architecture, and investment structures all share the same boundaries, the integrated picture the Agency CEO asked for becomes possible to produce. When they do not, it cannot exist.

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. Where DDD and TBM define the domain boundaries for architecture and investment, Team Topologies defines how to structure the human organizations and interactions within and across those domains to maximize flow and minimize friction.

Together, these three disciplines can help make a product operating model work at enterprise scale. Not only in pilot teams or digital service units, but across the whole agency. DDD ensures the technical architecture mirrors the domain structure. TBM ensures that technology investment decisions and cost tracking align to those same domains. Team Topologies ensures the organizational structure reinforces rather than undermines the domain boundaries that DDD and TBM establish. It also defines not only how teams should be structured but how they should interact. The interaction patterns between stream-aligned teams, platform teams, and enabling teams are as consequential as the team types themselves: they determine how decisions flow across boundaries, how dependencies are managed without creating bottlenecks, and how the organization accelerates change without re-creating the silos that domain-based design was intended to dissolve.

The connective tissue essential to the success of all three disciplines is the alignment of decision authority with delivery accountability at every level of the organizational stack. This alignment is not only an executive-level governance question. It runs from the leadership team that holds shared accountability for enterprise outcomes — the team Article 2 argues must be built before anything else — down through the value stream teams, platform teams, and enabling teams that Team Topologies defines. At each level, the team accountable for delivering an outcome must have the authority to make the decisions that govern it. Where that alignment exists, value flows. Where it does not, the Agency CEO’s four questions reassert themselves at whatever level the misalignment occurs. When all three disciplines are applied with that alignment principle running through the entire organizational stack, the three structures that should have similar structures — business domains, decision authorities, and technical architecture — naturally converge. Conway’s Law still applies, but now it produces the right mirror.

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.

The qualification is important. 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: the end user whose needs anchor the Wardley Map. 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. A domain structure that does not account for Approver relationships will produce the same misalignment it was designed to solve, now dressed in more sophisticated terminology.

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, including their internal and external dimensions, and their needs and expectations that define public value. 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 the 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. Without that foundation, the tool will produce well-designed systems organized around the wrong domains, serving an incomplete picture of the customers they exist to serve, and misaligned with the statutory authorization that gives the agency its legitimacy in the first place.