What is Brownfields Development?
Before we begin, the first step is to identify and agree upon what a brownfields development is vs a greenfields development. For the sake of this article we'll follow Grady's Booch's definition from a 2008 IBM interview. Chris outlays the following definition.
"There's a phrase emerging called Brownfield development. Greenfield development, you have no legacy to worry about. But most economically interesting software these days is not Greenfield but it's Brownfield, meaning that you're continuing to evolve a system that you can't turn off any more." Grady Booch, 2008.
Now, if you've read that and don't have existing legacy systems that can't be turned off within your business, great, you have yourself a greenfield project! I would recommend that you head over to our Resource Centre or check out our Way of Working which outlines our process for new projects.
If you do have existing legacy software that can't be turned off, don't worry you're not alone. As the definition insinuates, brownfields are the most economically important! It's likely that your business lives and breathes this system. It's also likely causing your business a significant amount of pain. There are three options for you to progress with the development of the system. Each of these have their own key risks which we'll highlight below.
What are the key risks?
When addressing risk, it's important to assess the degree of probability and the potential impact of each risk. Therefore, we'll take a brief look at each option's top risk.
Option 1: Continue developing the brownfields application
Risk: Slower Velocity
Degree of probability: Highly Likely
Impact: High
This is the easiest solution for the short term but, has the least business value long term. You can begin working immediately on progressing the system. However it is highly likely that velocity will slow as technical debt builds. Second to this you're likely going to end up with a monolith that cannot be broken into microservices, as well as slow release cycles. As time progress and technology moves on you may end up in a situation similar to what America is currently facing.
A limited supply of trained resources on an older technology stack leading to greater demand with slow releases means a compounding business cost in both time and agility. This is already a major problem for most major Australian banks running Cobol on their mainframes.
Option 2: Migrate the legacy code to a newer tech stack
Risk: Garbage in garbage out
Degree of probability: Highly Likely
Impact: Moderate
At face value this is the most attractive option. Port your system from the old code to a new code base and voila, you've modernised! Wouldn't it be great if there was a magic box that did this. When you think a little further though it becomes very apparent as to what would need to happen. Let's assume you do successfully convert your old code to a newer tech stack. You've just traded one problem for another. As a hypothetical, let's assume you've migrated from COBOL to Java. Great, now you've moved to a modern language. But what about the old legacy code that's now in Java? What about the documentation? What about the changes to your process?
It quickly becomes clear that there is a lot of information that needs to be sorted through. "If you try to take a legacy system and run it through some sort of migration tool, you will get all the garbage on the other side as output." Dr. Eban Escott, Bot's that Code, 2.2. Inescapable Truths, p.40. The Bots that Code book explains this in detail. You can download the book here. The impact of having to re-sort the garbage is going to stifle business agility as it is highly likely the technical debt will remain.
Option 3: Modernise the business process to a new code base
Risk: People/Software fit
Degree of probability: Likely
Impact: High
The third option is to migrate the brownfields project to a brand-new codebase. This is like turning a brownfields project into a greenfields project with all of your existing learnings and business process. That's the good news. The bad news unfortunately is that you have to rebuild/re-design the application again. If viewed as an opportunity to refresh the business process this is excellent. However, the single biggest risk is user resistance to change and a poor people/software fit. It is likely that users will be resistant to the change and this can have a severe impact on the business. However, with the right mitigation strategies that can be turned into an opportunity for a business to digitally transform.
How to mitigate the risks
After reading the options and risks above we believe that option 3 is an inevitability. In our opinion it is the only way to realistically escape the legacy trap! Even if you want to progress with options 1 or 2, there may still be some value in reading ahead. This section is going to detail our approach to a modernisation of the process to a new codebase. Our approach is simple but, it does have some rules.
At a high level there are three steps:
Step 1: Get the legacy system supported
We offer a fixed term support approach for an application that we have not developed. This allows the business process to be stabilized whilst the new application is in development. It also means we can access the knowledge of the old legacy system. To do this, we have the following ruleset that the application must qualify for.
- The customer has plans to rebuild within the next 6/12 months. Fixed term support contract, the support will have a fixed term for the old system.
- Support is on a time and materials basis. - Fixed length monthly support agreement in place but time and materials per issue raised in relation to the old system.
- A paid transition mission is completed to document the Application and ensure support can be provided. This includes development of the target codebase, releases etc. Estimated at 1-2 weeks.
- We retain the right to not support for any reason as part of discovery in point 3 support mission.
- The Application is hosted on the customers own servers (preferably in AWS or Azure - we can set this up for you).
- The support team are confident in the skills they have to support the Application. i.e. fits our existing skills and expertise.
These rules may sound strict, but it ensures that we can deliver what we promise during the transition period. Once that application is supported and stable, a pathway for modernisation can be scoped.
Step 2: Scope the new solution and migration
Outlined above is a workflow of WorkingMouse's approach to Government/Enterprise/Migration projects, where the solution is well defined and does not require extensive design work. The focus of the scope is primarily on transferring knowledge, validating any assumptions made and testing with users.
As you can see the process involves all of the key stakeholder groups. It enables the risk of the people/product fit to be mitigated in designing the new solution through their involvement.
The outputs provide everything needed for the development of the new codebase, including scientific estimations to provide a fixed time, variable scope approach.
Step 3: Develop, release and migrate the data
Lastly, it's now time to develop. When developing we follow our Way of Working. This ensures a consisted and de-risked agile approach to delivery.
Secondly, we also develop using the Codebots PAAS.
The platform has been developed to increase the speed and quality of software development but also continually mitigate the risk of legacy creep for the new project. There are two development patterns that Codebots provides for a Brownfields project.
The first is a Firecracker migration pathway. This enables us to import the old systems database schema into an application model and have the bot's rewrite the new codebase from here. This is perfect for small applications and database modernisation projects. We used this method for Police NSW. The divide and conquer approach is for larger monolithic applications. It enables the two applications to run side by side as different parts are incrementally modernised. Please see the Bots that Code book for full pathway descriptions.
Lastly, once the new application is built the most essential part of the process must be done, the data migration! As the old system's data is accessible, we can create custom update scripts that allow the old data to be migrated across to the new system. This helps provide a seamless experience for the business to progress forward.
Following this migration pathway means that you can modernise the application, business process and user experience whilst retaining your business data. We aim to simplify where we can and as always we're here to help if you need to contact us.
