Image by Paul Brennan from Pixabay

IN THIS SECTION, YOU WILL: Understand the context in which the ideas in this book developed.

KEY POINTS:

  • To better understand any idea or solution, it is crucial to understand the context in which it developed.
  • The Grounded Architecture approach evolved in global, loosely coupled organizations that are diverse, nonlinear, and under transformation pressure.


Fast-moving global organizations create a distinctive architectural challenge. They want the benefits of scale, shared platforms, and coordinated direction, but they also need local autonomy, rapid execution, and room for different businesses, teams, and markets to operate effectively. That combination creates constant tension.

This book emerged from working inside exactly that kind of environment. My experience building and running architecture practices is grounded in practical work, as Chief Architect at AVIV Group, eBay Classifieds and Adevinta. The ideas in this book were shaped less by theory than by repeated exposure to the same class of organizational problems.

Grounded Architecture is therefore not presented as a universal formula detached from context. It is a response to organizations that are large, diverse, decentralized, and under continuous pressure to change without losing coherence. The main characteristics of that environment were the following:

  • Global Scale
    The organizations I worked with operated across multiple countries and continents, supporting platforms with millions of users.

  • Multidimensional Diversity
    These companies were diverse in nearly every aspect, including customer segments, workforce cultures, business models, team structures, and technology stacks.

  • Nonlinear Growth Dynamics
    Growth was not solely organic; it involved mergers, acquisitions, and divestments, which introduced constant complexity and shifting priorities.

  • Synergy and Transformation Pressures
    Large organizations strive for economies of scale, seek to reduce duplication, and often undergo transformation programs to align their business and technology better.

  • Decentralized, Loosely Coupled Structures
    While business units operated with considerable autonomy, they were expected to align around shared goals, platforms, and architectural principles.

This environment required an architectural approach that was collaborative, adaptive, data-informed, and scalable. Grounded Architecture emerged as my response to those conditions.


Practicing Architecture at a Global Scale

I refined this approach in genuinely global and multicultural organizations operating at massive scale:

  • Covering diverse geographies, cultures, and languages
  • Serving millions of users every day
  • Collaborating with thousands of software developers across hundreds of product and engineering teams
  • Managing systems with hundreds of millions of lines of source code

Image by Pete Linforth from Pixabay

The Opportunities of Global Scale

Operating globally creates several strategic advantages:

  • Reduced duplication through shared platforms and capabilities
  • Economies of scale that lower unit costs for infrastructure and tooling
  • Resilience and flexibility gained from distributing operations across regions
  • Access to global talent, resulting in stronger teams and broader innovation
  • Capacity for nonlinear growth, including mergers, acquisitions, and partnerships

These advantages enable organizations to build robust, cost-effective, and strategically aligned ecosystems capable of serving large and diverse markets.

The Challenges of Global Complexity

Scale also creates significant complexity:

  • Thousands of internal communication pathways that make alignment difficult
  • A fragmented technology landscape with deeply interconnected services
  • High workforce costs related to hiring, onboarding, and managing talent globally
  • Massive infrastructure demands necessary to support always-on global services
  • Significant operational variability across time zones, markets, and regulatory environments
  • An expanded attack surface—with more systems, more users, and more risks
  • Ultimately, manual processes don’t scale—mapping systems, dependencies, and teams manually becomes unmanageable

Why Grounded Architecture Was Necessary

Balancing these opportunities and challenges has been one of the most demanding parts of the work.

The sheer scale of complexity and interdependence pushed us to treat architecture as a data-supported practice, not only as a collection of meetings and documents. We developed Lightweight Architectural Analytics to maintain a reliable, current picture of our systems. We also relied on decentralized, cross-functional Collaborative Networks to balance local autonomy with global alignment.

Scale did not just influence the architecture. It changed how we had to practice architecture.


Multi-Dimensional Diversity

The organizations I worked with also exhibited diversity across multiple dimensions, each of which added both richness and complexity:

  • Cultures – A globally distributed workforce and customer base, encompassing many languages, cultural norms, and working styles.
  • Organization – Units of varying sizes and structures, ranging from tightly knit startups to large, hierarchical departments.
  • Product – A broad array of features designed to meet the needs of diverse customer segments across multiple markets.
  • IT Architecture – A variety of architectural styles, from legacy monoliths to modern microservices and serverless models.
  • Technology – An extensive range of programming languages, libraries, tools, cloud providers, and infrastructure paradigms.

Image by Simon from Pixabay

How Diversity Showed Up in Practice

  • Organizationally: I collaborated with teams that ranged from just a dozen people to several hundred. The team structures varied significantly—from single, co-located squads to complex, multi-tiered arrangements. Architectural responsibilities also differed: some teams had dedicated architects, while others distributed architectural duties among senior developers or team leads.

  • Technologically: Our systems encompassed a wide range of architectures—from traditional monoliths to cloud-native microservices and serverless systems. We maintained our infrastructure across AWS, GCP, Azure, and private data centers. The technology stack was equally diverse:

    • Backend: Java, C#, Go, Scala, PHP, Node.js
    • Mobile: Swift, Objective-C, Kotlin, Java, Flutter/Dart
    • Frontend: React, AngularJS, Vue, jQuery, and others
    • Databases: MySQL, PostgreSQL, MongoDB, Cassandra, AWS RDS, and more

Each domain had its own history and legacy systems, requiring us to continuously adapt and integrate without losing momentum.

Opportunities from Diversity

This diversity created clear opportunities:

  • Greater innovation: A broader technology landscape fostered experimentation and creative problem-solving.
  • Fit-for-purpose tooling: Teams could choose the most suitable technologies for their specific needs.
  • Wider talent pool: Specialized tools and approaches allowed us to attract experts with diverse platforms and skill sets.

Challenges of Diversity

Diversity also introduced serious challenges:

  • Increased complexity: Managing, securing, and aligning diverse systems heightened the cognitive load for both teams and architects.
  • Limited flexibility: With talent and knowledge deeply entrenched in specific tech stacks, reorganizing or reallocating teams became more challenging.
  • Higher technical debt: Diverse stacks increased the risk of outdated, under-maintained, or redundant technologies, necessitating greater oversight and governance.

How Diversity Shaped Grounded Architecture

Diversity shaped the Grounded Architecture approach in important ways:

  • We developed lean, stack-agnostic tools that operated across a broad ecosystem—prioritizing coverage and flexibility over deep specialization.
  • We adopted a flexible, adaptive governance model—favoring a blend of nudges, incentives, and selectively applied mandates tailored to how different teams functioned.

We learned to treat diversity not as something to eliminate, but as something to design for.


Nonlinear Growth Dynamics

The organizations I worked with were also highly dynamic and nonlinear. They evolved through both organic and inorganic change, and each type introduced distinct architectural challenges.

Image by Pexels from Pixabay

Understanding the Growth Patterns

Two growth patterns mattered most:

  • Organic growth refers to internal expansion—new teams, features, customers, or geographies driven by the organization’s momentum.
  • Inorganic change involves mergers, acquisitions, divestments, or opening new business units through strategic investments.

Together, these create nonlinear growth dynamics—sudden, unpredictable shifts that can rapidly change the organization’s structure, scale, or focus.

Opportunities from Nonlinear Growth

When handled well, nonlinear growth creates clear advantages:

  • Rapid expansion into new markets, customer segments, or geographic regions
  • Acceleration of innovation through the integration of new technologies, talent, and services
  • Strategic repositioning via targeted acquisitions or divestments, aligning the portfolio with evolving business priorities

Architectural Impact

At the same time, such changes can disrupt architectural stability and clarity. The main impacts include:

  • Increased organizational complexity: New teams, reporting lines, and stakeholder groups must be integrated quickly and coherently.
  • Technology sprawl: Acquired companies bring their stacks, tools, processes, and architectural patterns.
  • Higher uncertainty: Ongoing change creates ambiguity around standards, ownership, and long-term direction.
  • Architectural flexibility becomes essential: Architectures must accommodate not only growth, but also divestitures, temporary transitions, and parallel systems.

Architectural Response

In response, our architecture practice evolved in several ways:

  • We prioritized transparency—creating tools to track ongoing organizational and technological changes in near real-time.
  • We collaborated closely with business and finance stakeholders, developing shared economic and risk models for evaluating the impact of acquisitions, investments, and divestments.
  • We designed flexible governance and data-driven tooling that could adapt quickly to structural shifts without requiring a complete reset.

Nonlinear growth is not something to resist. It is something to architect for.


Synergy and Transformation Pressures

In complex organizations, the goal is not only to grow in size but also to enhance efficiency, impact, and strategic alignment. Investors and stakeholders expect these organizations to become more than the sum of their parts—they aim to unlock synergies, scale efficiently, and accelerate innovation.

Image by MustangJoe from Pixabay

Opportunities from Synergy and Transformation

Pursuing synergies and business transformation creates significant opportunities:

  • Cost savings through reduced duplication and shared infrastructure
  • Freed-up resources that can be redirected toward innovation
  • Reusable capabilities, such as shared services or platforms
  • Increased efficiency and lower unit costs as processes are streamlined
  • Accelerated time-to-market by consolidating expertise and leveraging shared assets

These opportunities are particularly attractive for large, distributed organizations that seek to scale intelligently and operate more cohesively.

Challenges of Transformation

However, these benefits come at a cost. Transformation and synergy efforts present real challenges:

  • High initial investment with no guaranteed returns
  • Execution risk, especially when aligning diverse teams, systems, and goals
  • Short-term performance pressure, as teams are expected to deliver results while undergoing significant change
  • Disrupted productivity, as transformation initiatives compete with daily operations
  • Post-transformation complexity, including new dependencies on centralized systems, shared platforms, or newly aligned processes

From an architectural standpoint, these transformations often lead to increased interconnectivity—and with this comes a greater risk of unintended side effects.

Architectural Response

For an architecture practice, these pressures necessitate precision, clarity, and accountability. In response, we have focused on:

  • Tracking costs, value, and risk at a more granular level
  • Supporting data-informed decisions for both legacy retirement and innovative investments
  • Developing tools to model the economic trade-offs and technical impacts of transformation initiatives
  • Facilitating alignment without rigidity—ensuring that shared services and reusable components support flexibility rather than hinder it

Ultimately, the architecture practice must evolve into a strategic partner in transformation, helping the organization move faster, smarter, and with more confidence.


Decentralization and Loose Coupling

The concepts of tight and loose coupling—introduced by organizational theorist Karl Weick—help explain how organizations are structured and operate.

  • A tightly coupled organization is coordinated through shared rules, centralized decision-making, and formal feedback mechanisms. In such systems, management can align departments toward a unified strategy through direct oversight and top-down control.

  • A loosely coupled organization, in contrast, consists of autonomous units that operate with limited formal coordination. Teams may follow different rules, processes, and goals, adapting locally rather than conforming to central mandates.

Image by Andrii Yalanskyi from iStock

Our Reality: Loosely Coupled by Design

In my experience, most of the organizational units I’ve worked with were deliberately loosely coupled. These companies often grew through acquisitions and operated across multiple markets, each with unique local needs. The business strategy intentionally promoted this independence, allowing each unit to innovate, execute, and adapt locally.

In many cases, business units had their own:

  • Development teams
  • Budget and P&L ownership
  • Local leadership (CFOs, CMOs, and even CEOs)
  • Autonomy in technology and product decisions

This structure made sense—and it worked—especially in fast-paced, market-driven environments.

Advantages of Loose Coupling

Loose coupling creates significant value:

  • Flexibility – Units can act quickly, make independent choices, and evolve at their own pace.
  • Speed to Market – Fewer dependencies mean teams can deliver quickly and pivot easily.
  • Innovation – Decentralized teams are free to experiment and explore new ideas in smaller, low-risk contexts.

The Architectural Challenges

However, loose coupling also creates challenges that architectural practices must address:

  • Duplication of Effort – Teams often solve similar problems in parallel without sharing knowledge or reuse.
  • Accidental Diversity – Independent decisions can lead to a fragmented technology landscape, with multiple stacks solving the same problem in different ways.
  • Limited Scalability – Without coordination, it’s harder to consolidate solutions, scale them, or transfer personnel between teams.
  • Lack of Alignment and Control – Organization-wide change becomes difficult when each unit has its roadmap and priorities.

From an architectural perspective, this creates a core tension: How do we enable local autonomy while still achieving global alignment?

Our Architectural Response

To navigate this balance, we adopted a model of “hands-off, eyes-on.”

  • Teams retained full autonomy in their work and decision-making.
  • We built systems to provide complete visibility into the technology and organizational landscape.
  • Our Lightweight Architectural Analytics platform helped track divergence and overlap.
  • Our Operating Model emphasized decentralized decision-making while enabling cross-unit collaboration and strategic alignment.
  • We avoided rigid standardization and instead used nudges, incentives, and transparency to promote alignment.

This approach enabled us to scale architectural efforts without central bottlenecks, giving teams the freedom to innovate while keeping leadership informed and connected.

That is the broader role of this chapter in the manuscript. It defines the conditions the book is responding to, so that the later framework, principles, and examples can be read as pragmatic responses to real organizational complexity rather than abstract architectural preference.


Questions to Consider

Use the following questions to reflect on the organizational context your architecture practice actually has to operate in.

  • What are the unique characteristics of your organizational context?
  • What is the scale of your organization, and how does it affect your architecture practice?
  • How diverse is your organization?
  • What are the growth dynamics of your organization?
  • Are you experiencing synergy and transformation pressures?
  • How (de)centralized is your organization?
Introduction
Introduction
← →