Skip to content

org-design.md

Latest commit

 

History

History
141 lines (79 loc) · 9.58 KB

org-design.md

File metadata and controls

141 lines (79 loc) · 9.58 KB

Organizational Structure and Design

1. Company Overview

Offgrid is an e-commerce business. It is an online retail destination for adventure enthusiasts, offering a curated selection of high-quality gear for exploration and outdoor pursuits. Specializing in hiking, camping, climbing, winter sports, and water sports equipment. Operating exclusively online, Offgrid delivers adventure-ready gear directly to thrill-seekers and nature lovers nationwide.

2. Guiding Principals

The following 2 concepts are employed as part of driving the Offgrid organizational design:

  • Conways Law: A socio-technical principle about the impact of organizational communication on system architecture.

  • Domain Driven Design: A prescriptive software design methodology focused on aligning code with business domains.

Considering both Conway's Law and Domain-Driven Design (DDD) during organizational design is important because they address complementary aspects of building effective software systems and aligning teams with business goals. If helps ensure that organizational design supports both technical excellence (modular, maintainable systems) and business alignment (software that reflects domain needs). Conway’s Law guides how to structure teams to produce the desired architecture, while DDD ensures the architecture serves the business domain. Together, they create a cohesive approach to building scalable, effective software systems and organizations.

2.1 Conways Law

Conways law is categorized as an Organizational-System Alignment Principle.

2.1.1 Description

Conway's Law, articulated by Melvin Conway in 1968, states the following:

Note

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

-- Melvin Conway

In summary, the organizational structure and how teams communicate will be reflected in the products, services, and systems created. Therefore, the architecture of a software system tends to mirror the structure of the organization building it.

See Conways Law for more information.

2.1.2 Key Characteristics

  • Focus: Relationship between organizational structure and software architecture.
  • Domain: Socio-technical systems, organizational design, software architecture.
  • Implications: To design effective systems, align team structures with desired system architecture (e.g., microservices require small, autonomous teams).
  • Category Type: Observational principle or heuristic, not a prescriptive methodology.
  • Application: Used to understand or influence team organization to achieve desired system designs, often in Agile or DevOps contexts.

2.1.3 Aligning Team Structure with System Architecture

Conway's Law observes that a system's architecture mirrors the communication structure of the organization building it. When designing an organization, consider the following:

  • Impact on System Design: If teams are poorly structured (e.g., siloed or overly centralized), the resulting software will likely reflect those inefficiencies, leading to monolithic, tightly coupled, or fragmented systems.

  • Organizational Implications: To achieve a desired architecture (e.g., modular microservices), you must design team structures that support it. Small, cross-functional, autonomous teams are better suited for modular systems.

  • Avoiding Misalignment: Ignoring Conway’s Law can lead to a mismatch between team communication and system design, causing delays, technical debt, or systems that don’t meet business needs.

  • Example: If you want a modulith or microservices architecture, Conway’s Law suggests organizing small, independent teams aligned with specific services to avoid creating a monolithic system due to centralized team communication.

2.2 Domain Driven Design (DDD)

Note

See companion guide Domain Driven Design Guide that covers:

  • Domain
  • Sub-Domain
  • Bounded Context
  • Ubiquitous Language

Domain Driven Design is categorized as a Software Design Methodology/Paradigm.

2.2.1 Description

Introduced by Eric Evans in 2003, DDD is a software development approach that emphasizes aligning the software model with the business domain. It focuses on creating a shared understanding between domain experts and developers through a ubiquitous language, modeling complex domains, and structuring code around business concepts.

2.2.2 Key Characteristics

  • Focus: Modeling software based on the business domain, emphasizing collaboration and clear communication.
  • Domain: Software design, architecture, and business alignment.
  • Implications: Encourages modular, maintainable code through concepts like Bounded Contexts, Entities, Aggregates, and Domain Events.
  • Category Type: Prescriptive methodology with specific patterns and practices.
  • Application: Used in complex software projects, particularly in microservices, to ensure software reflects business needs and logic.

2.2.3 Aligning Software with Business Domains

Domain-Driven Design focuses on modeling software around the business domain, ensuring the system reflects real-world business needs and processes.

  • Business-Technical Alignment: DDD emphasizes collaboration between domain experts and developers to create a shared ubiquitous language and modular Bounded Contexts, ensuring software is meaningful to the business.

  • Organizational Implications: DDD encourages teams to be organized around domain-specific responsibilities. Each team can focus on a specific Bounded Context, fostering deep domain knowledge and reducing complexity.

  • Scalability and Maintainability: By aligning software with the business domain, DDD helps create systems that are easier to evolve as business needs change, but this requires teams to be structured in a way that supports domain ownership.

  • Example: In a retail company, DDD might lead to separate Bounded Contexts for inventory, pricing, and customer management, with dedicated teams for each to ensure focused expertise and clear ownership.

3. Synergy Between Conway’s Law and Domain Driven Design (DDD)

When used together, Conway’s Law and DDD create a powerful framework for organizational design:

  • Team-to-Domain Alignment: DDD’s Bounded Contexts naturally map to team boundaries, and Conway’s Law reinforces the need to structure teams to match these contexts. For example, a team responsible for a specific domain (e.g., payments) should have clear communication channels and autonomy to avoid cross-team dependencies that could lead to tightly coupled code.

  • Reducing Friction: Misaligned team structures (per Conway’s Law) can undermine DDD efforts by creating communication overhead or conflicting priorities. Aligning teams with domains ensures smoother collaboration and cleaner system boundaries.

  • Enabling Scalability: Combining DDD’s domain-focused modularity with Conway’s Law-driven team structures supports scalable systems and organizations. Autonomous teams working on distinct domains can deliver independently, improving agility and reducing bottlenecks.

  • Example: A company adopting microservices can use DDD to define Bounded Contexts (e.g., order processing, user authentication) and apply Conway’s Law to form small, domain-aligned teams, ensuring the system and organization evolve cohesively.

4. Organizational Design

The Offgrid Organization has been designed with both Conways Law and Domain Driven Design (DDD) in mind. The goal is to align the team structures with the core business capabilities (Bounded Contexts) of an e-commerce platform, ensuring that the communication flows will naturally support the desired system architecture.

The core philosophy is to align the organizational structure directly with the business's core problems and capabilities, rather than with technical layers and/or capabilities (e.g., frontend, backend, database). This can be summarized as follows:

  • Problem Space over Solution Space: The "problem" is what the business exists to solve for customers. This is where the core business capabilities can be found.

  • Strategic Domain-Driven Design (DDD): Helps model the business domain, identify core subdomains (key differentiators), supporting subdomains (necessary but not core), and generic subdomains (off-the-shelf solutions).

  • Conway's Law Reversal: Instead of your communication structure dictating your system design, you're intentionally defining your business capabilities and then creating a communication and team structure that supports that design. This is a deliberate "Conway's Law reversal."

The following 4 Step process takes a practical application to Organizational Design:

  • Step 1 - Define Domains with DDD:

    • Use DDD to identify Bounded Contexts and core business domains through collaboration with stakeholders.

    • Please see the Domain Model Design. This is based on a Strategic Domain Driven Design (DDD).

  • Step 2 - Structure Teams per Conway's Law:

    • Organize teams to align with these Bounded Contexts, ensuring each team has clear ownership, autonomy, and minimal cross-team dependencies.

  • Step 3 - Foster Communication:

    Establish a ubiquitous language (DDD) within teams and ensure team communication structures (Conway’s Law) support the desired system architecture.

  • Step 4 - Iterate:

    Continuously refine team and system boundaries as the business evolves, using both principles to maintain alignment.