Yes, it would be ideal if all development projects were greenfield in nature where we were starting with a clean slate and could design and build using the latest tools and methods. Unfortunately, that’s not the world we live in. More than likely, you are currently working on a brownfield application. What’s a brownfield application?

I will answer the above through the use of a metaphor that struck me as I was traveling to Decisions Days in NYC last month. As I got off the plane at Laguardia airport I was struck by a number of things. Initially I was impressed by the improvements to the terminal since the last time I had flown in. Next I could see all the construction taking place and was amazed at the scale of the project. It turns out that there is an $8 Billion dollar project to rebuild the Laguardia airport all while the airport continues to operate. This is the exact scenario that a large number of our newest clients are currently facing. They are having to refactor and slowly rebuild core applications while keeping them operational.

If this sounds familiar it’s because roughly 75% of application development projects today involve rebuilding existing applications onto modern architecture. Brownfield applications share all the pitfalls of Greenfield projects with the additional complexity of dealing with Legacy code. In some respects, understanding the overall requirements can be a bit easier if you have an existing application. On the other hand digging into hundreds of lines of undocumented code is full of hazards and unexpected complexities.

Here are a few strategies that can help you on your journey:

1. Define the Interfaces. You should begin by cataloging all the interfaces you will be dealing with and the associated data structures. This will also help in understanding the overall nature of the problem.
2. Layout the Data Objects. This too will assist in understanding the overall application. Keep an eye open for data and processes that can be modularized with a large number of interfaces or dependencies.
3. Modularize. Break the Legacy application into as many small pieces as possible. This can allow for a staged rollout where parts of the new and old application are operating simultaneously try to avoid a big bang replacement if at all possible. Even with a new data structure it can be possible to replicate so as to allow side-by-side operations.
4. Replicate. It’s not that difficult to create data replication between the new and existing database structures. This will allow for side-by-side operation and can keep the existing reporting until time is available to build this out in a new format.
5. Increment. By picking off small bits of functionality that can be migrated a little at a time you can make continuous progress and slowly replace your legacy application.

If you would like to talk about your existing legacy application, we love to discuss such things. Please reach out to us at sales@decisions.com.