The purpose of the Brownfield Dev project is to showcase patterns that empowers teams charged with care and feeding for a system with an outdated architecture.
Many GitLab clients are large organizations, some private sector, some pubilc sector, who cannot simply abandon old systems and start fresh with a NodeJS microservice on MogoDB. There are some example templates floating around that show one aspect or another of how GitLab can be used to build or deploy an older app. These are useful if the rest of the plan is sound, but in isolation do not provide enough context.
The term comes from “greenfield” being a “nice fresh new clean” sort of effort that has endless possibilities and no prior decisions need to be considered.
brownfield is the opposite.
Applications that are considered brownfield are typically older. Designed before the newer stacks
and patterns were established. Interestingly enough, even Ruby on Rails apps are starting to feel
brown at this point.
I’d actually recommend considering any application that is in production to be Brownfield due to the inflexibility that comes with a high uptime SLA. Applications get browner after they’ve passed between owners or have been officially consigned to “operating and maintenance” contracts with reduced resources.
A brownfield team typically has:
- established, old processes
- actions and procedures defined by how things were done in the past
- attrition of early direction-setting folks
- strong central command and control structure
Bringing scrutiny to the structure, roles, and activities in the team may play into some of the changes discussed in this project.
Teams are much easier to rejouvinate than applications. Improving internal processes and collaboration is easy and fun with quick results. A larger team that has more varied intrinsic goals becomes much more difficult to rejuvenate.
Any organization that has not embraced the
learning organization approach will inevitably become
brownfield due to the way bureaucracy tends to work. As risk aversion overwhelms growth, the
individual contributors tend to leave and the organization stagnates. The board sees the slowdown
and in order to prevent the decline from overwhelming shrinking margins, they offshore or outsource
or layoff or take some other destructive action.
In the public sector, it’s a little different. Your organization is hundreds of years old and under control of some oversight committee in congress. There is likely no way to revolutionize the organization as a whole. The best we can shoot for is loosening the reins a bit and enabling the smaller organization to do good things.
The last aspect of this project is going to focus on the reader. We can all contribute more by using techniques for better time management, better messaging and communicating, problem definition, and others. These will likely be references to existing works like Own the Room, Deep Work, or other relevant books, articles, studies, and techniques.