To quote Marc Andreeson, “Software is eating the world”. To those in the technology industry this should be self-evident since we see new software applications being created each day. A question rarely asked is what happens to all that software as it gets older and needs to change to meet new market demands. To answer this, we need to split software development into two categories: Greenfield Development and Brownfield Development.
Greenfield Application Development
Greenfield Development refers to brand new applications – ones that start from scratch (or as Wikipedia puts it “…lacks any constraints imposed by prior work”). This can mean a new application that solves a previously unaddressed business problem, or a system that completely replaces an existing system which is inadequate in some way.
In greenfield development, the feature set and interfaces are dictated only by the problem being addressed. The different aspects of the problem can be solved in any way the development team sees fit, as long as it solves the described problem.
Greenfield development can be quite time consuming since it requires all aspects of the new system be defined and constructed. For new applications that are meant to replace something that already exists the process can be just as lengthy. Though it would seem that when replacing an existing application much of the work has already been done, the very fact that the existing system needs to be replaced indicates that the current system is inadequate, therefore duplicating what is already there is insufficient.
Due to its very nature, a greenfield project can only begin adding value to the business when it is complete. While still in process, there is insufficient functionality to provide any benefit, and can even do harm if the system is put into production too soon.
Brownfield Application Development
Brownfield development takes an existing application and enhances it. In brownfield, significant portions of the existing code is reused instead of building new. Brownfield development can include adding new features to an existing application, or reworking an older system that has become difficult to maintain.
Since brownfield development enhances an existing system, the interfaces with other systems are already defined and functional.
Differences Between Greenfield and Brownfield
An examination of the differences between the two types of projects can help in understanding the advantages and disadvantages of each.
If we consider the existing legacy system a sunk cost, the effort required in a brownfield project is significantly less that that needed for a greenfield project.
In brownfield projects there is usually some effort that must be expended to update the existing infrastructure – effort that is not required in greenfield efforts. Depending on the age of the existing system, the architecture may not support the latest approaches to application development and thus not be able to take advantage of emerging technologies. Implementing a newer architecture to support these technologies can open doors previously closed to the legacy application.
However, in greenfield projects ALL the code must be written from scratch. When updating an existing system, there is a significant amount of functionality that is already present and already bringing value to the company. Though implementing a single feature can require some extra effort over that required to implement it in a greenfield project, the net effort to get a functional feature in the hands of the users is significantly less.
Time until Break Even
A good way to measure the success or failure of a development effort is the time required before the accumulated advantages provided by the system equal the time and expense invested.
Using this measurement, brownfield development clearly provides the most ROI. Greenfield projects must be completed, installed, and new business processes implemented before they can begin bringing value to the company. Elapsed time and investment necessary before the first derived advantage is given can be measured in years and hundreds of thousands of dollars. Furthermore, the entire investment must be made before any return is seen. If it turns out that the project is misguided in some way, this won’t be discovered until the entire budget is spent.
Brownfield development, however, provides a much shorter timeframe to payback since new features and architectural enhancements can be rolled out along the way. Often the first improvements can be pushed out to users within a few weeks of the start of a project. Whether these improvements are additional features, performance improvements, or internal architectural enhancements, can be decided by the development team, but whatever is scheduled first can be in production and providing value quickly.
System Availability and Project Schedules
In Greenfield projects, development of new features for the existing system is normally stopped and all available resources put onto the project to replace the existing system. For larger systems, this can lead to extensive time where the current system is not improved and changing business needs are not addressed. For a system that is used by internal customers it can be inconvenient and frustrating to wait so long for necessary enhancements. For a commercial system that is being sold to customers, delaying delivery of new features means the competition can catch up and get ahead.
Brownfield development allows for adding features while any shortcomings of the application are being fixed. Work necessary to improve a poorly performing system can be done at the same time as new feature creation resulting in continued releases as frequently as necessary. The balance between legacy system improvement and new feature development can be adjusted on each release to accommodate the changing business requirements.
An advantage system reengineering has over building new is the maintenance of existing undocumented features. Despite the best efforts to document the existing system in preparation for replacement so all the existing functionality can be maintained, there are going to be nuances which are missed or incorrectly recorded. Developing an application from scratch is likely to change or lose functionality that is required by the business.
Enhancing an existing application can maintain these undocumented features – sometimes without even knowing it. One goal of brownfield development is to use as much of the existing code as possible. Therefore, the nuances of the existing system should not be affected.
Brownfield and greenfield development both arrive at a given goal, but go about it in very different ways. Often reengineering an existing system provides significant advantages over building from scratch, though it can be a more complicated process. In experienced hands, a brownfield development project can provide budget and schedule advantages, as well as more functionality.