From Blueprints to Gardening: The Evolution of Emergent Architecture

-

A common friction point in modern software development is the clash between Solution Design and Agile delivery. Traditional architects want a blueprint before construction begins ("Big Design Up Front"). Agile teams want to start coding immediately to get feedback.

If you have too much design, you block the team. If you have too little, you end up with "Spaghetti Code."

The solution lies in shifting our mindset from being "Construction Managers" to becoming "City Planners." This guide explores how to manage design decisions, embrace emergent architecture, and use technical debt as a strategic tool.

1. The Mindset Shift: From Blueprint to Gardening

Agile doesn't mean "no design"; it means continuous design. The goal is to make the cost of change low so that decisions can be made at the "Last Responsible Moment."

Traditional Principle Agile Equivalent Practical Application
Completeness Emergent Architecture Start with a "Walking Skeleton" (end-to-end connectivity) and flesh out details sprint by sprint.
Future-Proofing YAGNI (You Ain't Gonna Need It) Don't build generic layers for future use cases. Build exactly what is needed now, then refactor.
Standardization Automated Guardrails Replace manual review boards with automated "linting" for architecture in the CI/CD pipeline.

2. Managing Decisions: The "Door" Framework

Not all architectural decisions require the same level of scrutiny. To move fast, we categorize decisions based on reversibility.

Type 1 Decisions: One-Way Doors (Irreversible)

Examples: Choosing a Cloud Provider, defining the Database paradigm, selecting a primary language.

Action: Slow down. These require a formal Architectural Decision Record (ADR), a Proof of Concept (PoC), and consultation with the Guild.

Type 2 Decisions: Two-Way Doors (Reversible)

Examples: Internal class structure, library choices, UI component naming.

Action: Move fast. If the team gets it wrong, the cost to fix it is low. Prioritize speed over perfection.

3. Who Decides? The Delegation Poker Model

Ambiguity kills velocity. The question "Am I allowed to decide this?" creates bottlenecks. We use Delegation Poker (a Management 3.0 practice) to agree on decision rights.

Imagine a scale from 1 (Manager decides) to 7 (Team decides fully):

  • Level 1 (Tell): The Architect sets the Global Security Standards. The team must follow.
  • Level 4 (Agree): The Architect and Team define the API Contract together. Neither can force the other.
  • Level 6 (Inquire): The Team decides on internal code patterns. The Architect only looks at it during the Retro.

Tip: Create a matrix on your wiki explicitly listing who owns what (e.g., "Database Schema" = Level 4, "Variable Naming" = Level 7).

4. The Strategy: Runway vs. Emergence

How do architects stay ahead of the team without blocking them? By balancing two concepts:

The Architectural Runway (Sprint N+1)

The Solution Designer works one step ahead of the team to pave the "runway." These are Enabler Stories—setting up the infrastructure, security patterns, or CI/CD pipelines needed for the next sprint's features. If the runway runs out, the team crashes (gets blocked).

Emergent Architecture (The "Desired Path")

Once the runway is paved, the team builds the features. We don't over-design the internals. We use the Red-Green-Refactor cycle:

  1. Make it work: Write the simplest code to satisfy the story.
  2. Listen to the code: Identify friction or duplication.
  3. Refactor: Extract design patterns after you see the need, not before.

5. Technical Debt as a Design Tool

In Agile, technical debt is not always a failure; it is a financial lever. We can distinguish between:

  • Reckless Debt: Skipping tests because of laziness (Bad).
  • Prudent Debt: Hard-coding a logic block to hit a critical market deadline (Good/Strategic).

The Rule: If you take on Prudent Debt, you must issue a "Promissory Note" in the form of an ADR. Define the repayment plan (e.g., "We will refactor this when we hit 1,000 users").

6. The Compass: Start with "Why"

Finally, the most effective tool for an Agile Solution Designer is the Problem Statement.

Before designing a solution, ask "Why?" five times. If you don't understand the core business problem, you cannot safely delegate to the team. Providing Commander’s Intent (The Why) allows the team to innovate on the "How."

Example:

  • Request: "We need a Blockchain architecture."
  • The "Why": "We need to ensure audit logs aren't tampered with."
  • Agile Solution: "We don't need Blockchain. We can use an immutable ledger database for 10% of the cost."

Summary

To succeed in Agile, Solution Design must shift from controlling to enabling.

  • Focus on One-Way Doors and let the team handle the rest.
  • Use Delegation Poker to clarify autonomy.
  • Build the Architectural Runway just in time.
  • Treat Technical Debt as an investment.
  • Always start with the Problem Statement.

Comments

Post a Comment

Popular posts from this blog

Building a Scalable Test Automation Framework for Large Applications: TypeScript, Playwright, Screenplay & Serenity BDD

-
Testing large, complex web applications is a monumental challenge. As applications grow, so does the test suite. Traditional test automation frameworks, often built on the Page Object Model (POM), can become brittle, hard to maintain, and difficult for non-technical stakeholders to understand. What if we could build a framework that was not only robust and scalable but also produced living documentation that the entire team—from developers to business analysts—could use? In this post, we'll build a production-grade test automation framework from the ground up. We'll combine the power of modern tools and patterns to create a solution that is maintainable, readable, and ready for the demands of large-scale applications. Table of Contents The Dream Team: Our Technology Stack Why This Stack? The Core Concepts Setting Up the Project: The Bluepri...
Read more

A Deep Dive into GitHub's Engineering System Success Playbook

-
In the fast-paced world of software development, engineering teams are the engine driving business innovation and success. But how do you ensure this engine is running at peak performance? GitHub's new Engineering System Success Playbook (ESSP) offers a comprehensive framework designed to help organizations measure and improve their engineering performance, leading to better business outcomes. This playbook isn't just about writing code faster; it’s a holistic guide that emphasizes the synergy between quality, velocity, and developer happiness. By adopting a systems thinking approach, the ESSP helps teams identify bottlenecks, implement meaningful changes, and foster a culture of continuous improvement. The Core Philosophy: Four Zones of Success Inspired by leading industry frameworks like SPACE, DORA, and DevEx, the playbook introduces a layered system of four "foundational zones" that underpin engineering excellence. Developer H...
Read more

Setting up a global .gitignore on a Mac

-
I work with multiple OSes, programming languages and frameworks so here is a tip on keeping your git repos clean. I create a global .gitignore file to exclude platform related files (OS and IDE) and then when I create a new project I create a project specific .gitignore for the project related files which is specific to the languages and frameworks I am using in the project. Creating a global gitignore on a Mac You may name the file and place it where you want. I typically just name it .gitignore and store at '~/.gitignore'. Set it by running the following in a terminal: git config --global core.excludesfile '~/.gitignore' Example global gitignore Here is my global which I place at '~/.gitignore' Project specific gitignore GitHub have created a repo as a guide for what to include in your .gitignore for specific languages and frameworks: https://github.com/github/gitignore .
Read more