The definition of brownfield software development is the development and deployment of new software and systems in the presence of existing and legacy systems.

Sound familiar? That’s because unless you’re part of a brand new startup, you’re already doing this. It’s the reality for anyone working in an enterprise IT environment.

If we were all working within our “happy path” plans, we’d be able to develop new software and systems that immediately worked with our existing ones, and integration between system would be easy. But just like a 15-year-old car doesn’t have built in GPS, neither do legacy systems operate in the same way as new software.

Brownfield development must take into consideration how it will interoperate with the existing systems to prevent causing more problems than the new software solves.

What is Brownfield Development

The term brownfield is borrowed from the construction industry. Brownfield land describes a new building location that, in the proves of planning and construction, must take into account the area’s existing structures and work around those to prevent causing problems.

The value in brownfield development is that it extends the in-place systems. The critical piece is context – to understand the environment that the development is being done in so that it doesn’t disrupt current software operations.

To gain this value, however, the project cannot be planned or executed in a vacuum.

Brownfield vs Greenfield

Many software projects assume a clean slate, or what is alternatively called a greenfield development environment. Requirements are gathered, schedules developed, and software is built.

Greenfield software is developed under the pretext that it is either standalone or that the system it will be inhabiting is clean a fresh. These kinds of projects are, for obvious reasons, extremely rare.

When projects must be developed in the presence of legacy applications, ignoring existing applications to develop a new application only adds technical debt to what is likely already overloaded IT schedules and resources.

When planning a new application within an existing ecosystem, gaining an understanding of the touch points between it and the applications it must touch is only part of the project’s considerations. The effect that the software will have on the system must be taken into account as well. End to end clarity of the enterprise architecture and the new application’s place within it can reduce the negative impact of its development.

Strategies for Brownfield Application Development

Bring Together the Right Resources

When executing a brownfield software project, having the right brains considering the problem is the first step to success.

Go beyond those that will build the application and include on the team those that have an understanding of the bigger picture. This should include:

• Enterprise Architects – provide an end to end understanding of the systems
• Business owners – keep requirements on track
• Stakeholders – ensure the application being built is providing value
• Subject Matter Experts of adjacent products – will provide insight into the inner workings of other applications

These team members should be included throughout the initial planning process. If you’ve engaged an outside firm to help with the development, make sure they are also included in these planning meetings.

Create a Minimally Viable Product

Based on the agreed upon requirements and business needs, the team can begin building what is known as a minimally viable product.

By creating an application that accomplishes a minimum set of functionalities and placing it within the ecosystem, a better picture is gained around both the effect it will have on the systems and the unforeseen challenges of integration.

This requires building a product that actually works – this isn’t a proof of concept to be thrown away after. Instead, this product will be what future iterations will be built upon.

Investigate Modern Integration Methods

As your application goes through planning, you may discover that it needs to communicate with others in the ecosystem or access data from other parts of the system. While you may already have integrations between applications in place, this may be the time to re-evaluate the value of how you connect those applications.

These choices should be part of your early planning as they can impact your application design. Consider the following integration and application design patterns:

• Point to Point: These integrations allow two applications to communicate, but are not flexible. However, they are rapid to develop and work well depending on the number of integrations needed in an ecosystem
• APIs: Application Programming Interfaces, or APIs, are flexible connections between applications, allowing them to use functionality and data from far reaching software
• Microservices: Microservices take API designs to the next level. Building loosely coupled services increases application interoperability

The likelihood is you’re already building in a brownfield application environment. But you’re also probably approaching your projects like they are greenfield endeavors. Stop ignoring the intricacies of developing against existing applications and instead include the resources and strategies to launch a successful software project.