Brownfield Projects
All software that is used, must be maintained.
It’s been estimated that 75% of software development effort is spent on maintenance, and not new functionality. Business rules build up over time, and budget constraints don’t always allow for sweeping rewrites. The danger of a rewrite going wrong is great. But over time, the risk of doing nothing is even greater. Eventually, developers won’t want to touch the code and external dependencies can become completely outdated. All of this can make a project insecure, unstable and unwieldy. It can be very difficult for a team to modernize a project in such a way that does not break existing functionality. We understand this and we specialize in it.
If it’s working, don’t break it.
This is rule #1 for project maintenance, and it starts with understanding your business. The rules put into place in your software should be respected, so we read the code and talk with you to make sure we know them like the back of our hand. Then, we write automated tests to validate your business rules, without touching any of the existing code just yet. This early analysis is a crucial step that is often overlooked by a novice team.
Evolution, not revolution.
Once we understand your business, and your code, and have automated tests set up to enforce those rules, then we can start on a rewrite. We find an area of the code that is most concerning to you, and we bring it into the present (or even the future) by pretending we are developing it from scratch, using our proven methodology of project organization.
Divide and conquer. Not endless rewrites.
The bigger the project, the more likely it is that it will fail. So we chose to improve your software in phases, over a period of time, to keep the feedback loop tight and focused. An effort like this can be done in combination with developing new features, so that rewrites don’t have to slow down the pace of delivering new features. Because at the same time, your project is getting more secure, stable and manageable.
Make new functionality brownfield-proof.
Our software architecture method is designed to be scalable for any size project, by dividing up the codebase into logical components depending on the type of activities they perform, and making them all testable. This has the advantage of allowing the different tiers to be upgraded in small pieces, so you won’t have to worry about a risky rewrite ever again. We also only chose a tech stack that has already stood the test of time and proven to be adaptable to future business needs.
Integrate properly with complex legacy applications.
Sometimes, the entire tech stack doesn’t need to be re-engineered. Instead, it makes more sense to properly interface with it. Mainframe applications, in particular, have advantages and complexities that make complete rewrites ill-advised. Instead, these can be treated as a source of data or business intelligence that can be interfaced with, keeping the advantage of both your new code and the legacy code that functions as the core of your business.