Greenfield versus brownfield software systems

Concept · Chapter 5

The distinction

Borrowed from construction — greenfield is undeveloped land (a clean slate); brownfield is previously developed land being reused. One of the first design questions is which kind of system you’re building.

Greenfield systems

A brand-new application with no constraints from prior work. Two flavors:

• Well-understood (mature) domain — limited room for innovation (e.g. Windows desktop apps, standard mobile apps, enterprise web apps). Abundant existing frameworks, tools, and reference architectures to lean on. This is the more common case, and the accumulated knowledge from similar apps is a big advantage.
• Novel domain — new and not well understood; demands far more innovation and offers little supporting material. Instead of reference architectures, expect to build prototypes to test solutions.

Throwaway prototypes help here: build a small piece to get user feedback or test a quality attribute, then discard it. Because they’re not for long-term use, qualities like maintainability and reusability aren’t the point. They’re also a good way to try unfamiliar or new technologies.

Brownfield systems

An existing system that needs architectural changes — to fix defects, add or change functionality, or improve a quality attribute without changing behavior. Wholesale re-architecting is uncommon unless major rework is required.

• First, understand the existing architecture — its overall structure, elements, and relationships.
• From there, design proceeds much like a greenfield system that has already been through a few iterations to establish an initial architecture.
• Deeper treatment of legacy systems lives in Legacy applications.

Related concepts

• Top-down versus bottom-up design approaches
• Architectural drivers
• Leveraging design principles and existing solutions
• Domain-driven design

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.5 “Greenfield versus brownfield software systems”, pp. 288-291.