Mitigating the risks of brown­fields de­vel­op­ment


What is Brownfields Development?

Before we be­gin, the first step is to iden­tify and agree upon what a brown­fields de­vel­op­ment is vs a green­fields de­vel­op­ment. For the sake of this ar­ti­cle we’ll fol­low Grady’s Booch’s de­f­i­n­i­tion from a 2008 IBM in­ter­view. Chris out­lays the fol­low­ing de­f­i­n­i­tion.

“There’s a phrase emerg­ing called Brownfield de­vel­op­ment. Greenfield de­vel­op­ment, you have no legacy to worry about. But most eco­nom­i­cally in­ter­est­ing soft­ware these days is not Greenfield but it’s Brownfield, mean­ing that you’re con­tin­u­ing to evolve a sys­tem that you can’t turn off any more.” Grady Booch, 2008.

Now, if you’ve read that and don’t have ex­ist­ing legacy sys­tems that can’t be turned off within your busi­ness, great, you have your­self a green­field pro­ject! I would rec­om­mend that you head over to our Resource Centre or check out our Way of Working which out­lines our process for new pro­jects.

If you do have ex­ist­ing legacy soft­ware that can’t be turned off, don’t worry you’re not alone. As the de­f­i­n­i­tion in­sin­u­ates, brown­fields are the most eco­nom­i­cally im­por­tant! It’s likely that your busi­ness lives and breathes this sys­tem. It’s also likely caus­ing your busi­ness a sig­nif­i­cant amount of pain. There are three op­tions for you to progress with the de­vel­op­ment of the sys­tem. Each of these have their own key risks which we’ll high­light be­low.

What are the key risks?

When ad­dress­ing risk, it’s im­por­tant to as­sess the de­gree of prob­a­bil­ity and the po­ten­tial im­pact of each risk. Therefore, we’ll take a brief look at each op­tion’s top risk.

Option 1: Continue de­vel­op­ing the brown­fields ap­pli­ca­tion

Risk: Slower Velocity

Degree of prob­a­bil­ity: Highly Likely

Impact: High

This is the eas­i­est so­lu­tion for the short term but, has the least busi­ness value long term. You can be­gin work­ing im­me­di­ately on pro­gress­ing the sys­tem. However it is highly likely that ve­loc­ity will slow as tech­ni­cal debt builds. Second to this you’re likely go­ing to end up with a mono­lith that can­not be bro­ken into mi­croser­vices, as well as slow re­lease cy­cles. As time progress and tech­nol­ogy moves on you may end up in a sit­u­a­tion sim­i­lar to what America is cur­rently fac­ing.

A lim­ited sup­ply of trained re­sources on an older tech­nol­ogy stack lead­ing to greater de­mand with slow re­leases means a com­pound­ing busi­ness cost in both time and agility. This is al­ready a ma­jor prob­lem for most ma­jor Australian banks run­ning Cobol on their main­frames.

Option 2: Migrate the legacy code to a newer tech stack

Risk: Garbage in garbage out

Degree of prob­a­bil­ity: Highly Likely

Impact: Moderate

At face value this is the most at­trac­tive op­tion. Port your sys­tem from the old code to a new code base and voila, you’ve mod­ernised! Wouldn’t it be great if there was a magic box that did this. When you think a lit­tle fur­ther though it be­comes very ap­par­ent as to what would need to hap­pen. Let’s as­sume you do suc­cess­fully con­vert your old code to a newer tech stack. You’ve just traded one prob­lem for an­other. As a hy­po­thet­i­cal, let’s as­sume you’ve mi­grated from COBOL to Java. Great, now you’ve moved to a mod­ern lan­guage. But what about the old legacy code that’s now in Java? What about the doc­u­men­ta­tion? What about the changes to your process?

It quickly be­comes clear that there is a lot of in­for­ma­tion that needs to be sorted through. “If you try to take a legacy sys­tem and run it through some sort of mi­gra­tion tool, you will get all the garbage on the other side as out­put.” Dr. Eban Escott, Bot’s that Code, 2.2. Inescapable Truths, p.40. The Bots that Code book ex­plains this in de­tail. You can down­load the book here. The im­pact of hav­ing to re-sort the garbage is go­ing to sti­fle busi­ness agility as it is highly likely the tech­ni­cal debt will re­main.

Option 3: Modernise the busi­ness process to a new code base

Risk: People/Software fit

Degree of prob­a­bil­ity: Likely

Impact: High

The third op­tion is to mi­grate the brown­fields pro­ject to a brand-new code­base. This is like turn­ing a brown­fields pro­ject into a green­fields pro­ject with all of your ex­ist­ing learn­ings and busi­ness process. That’s the good news. The bad news un­for­tu­nately is that you have to re­build/​re-de­sign the ap­pli­ca­tion again. If viewed as an op­por­tu­nity to re­fresh the busi­ness process this is ex­cel­lent. However, the sin­gle biggest risk is user re­sis­tance to change and a poor peo­ple/​soft­ware fit. It is likely that users will be re­sis­tant to the change and this can have a se­vere im­pact on the busi­ness. However, with the right mit­i­ga­tion strate­gies that can be turned into an op­por­tu­nity for a busi­ness to dig­i­tally trans­form.

How to mit­i­gate the risks

After read­ing the op­tions and risks above we be­lieve that op­tion 3 is an in­evitabil­ity. In our opin­ion it is the only way to re­al­is­ti­cally es­cape the legacy trap! Even if you want to progress with op­tions 1 or 2, there may still be some value in read­ing ahead. This sec­tion is go­ing to de­tail our ap­proach to a mod­erni­sa­tion of the process to a new code­base. Our ap­proach is sim­ple but, it does have some rules.

At a high level there are three steps:

Step 1: Get the legacy sys­tem sup­ported

We of­fer a fixed term sup­port ap­proach for an ap­pli­ca­tion that we have not de­vel­oped. This al­lows the busi­ness process to be sta­bi­lized whilst the new ap­pli­ca­tion is in de­vel­op­ment. It also means we can ac­cess the knowl­edge of the old legacy sys­tem. To do this, we have the fol­low­ing rule­set that the ap­pli­ca­tion must qual­ify for.

  1. The cus­tomer has plans to re­build within the next 6/12 months. Fixed term sup­port con­tract, the sup­port will have a fixed term for the old sys­tem.
  2. Support is on a time and ma­te­ri­als ba­sis. - Fixed length monthly sup­port agree­ment in place but time and ma­te­ri­als per is­sue raised in re­la­tion to the old sys­tem.
  3. A paid tran­si­tion mis­sion is com­pleted to doc­u­ment the Application and en­sure sup­port can be pro­vided. This in­cludes de­vel­op­ment of the tar­get code­base, re­leases etc. Estimated at 1-2 weeks.
  4. We re­tain the right to not sup­port for any rea­son as part of dis­cov­ery in point 3 sup­port mis­sion.
  5. The Application is hosted on the cus­tomers own servers (preferably in AWS or Azure - we can set this up for you).
  6. The sup­port team are con­fi­dent in the skills they have to sup­port the Application. i.e. fits our ex­ist­ing skills and ex­per­tise.

These rules may sound strict, but it en­sures that we can de­liver what we promise dur­ing the tran­si­tion pe­riod. Once that ap­pli­ca­tion is sup­ported and sta­ble, a path­way for mod­erni­sa­tion can be scoped.

Step 2: Scope the new so­lu­tion and mi­gra­tion


Outlined above is a work­flow of WorkingMouse’s ap­proach to Government/Enterprise/Migration pro­jects, where the so­lu­tion is well de­fined and does not re­quire ex­ten­sive de­sign work. The fo­cus of the scope is pri­mar­ily on trans­fer­ring knowl­edge, val­i­dat­ing any as­sump­tions made and test­ing with users.

As you can see the process in­volves all of the key stake­holder groups. It en­ables the risk of the peo­ple/​prod­uct fit to be mit­i­gated in de­sign­ing the new so­lu­tion through their in­volve­ment.

The out­puts pro­vide every­thing needed for the de­vel­op­ment of the new code­base, in­clud­ing sci­en­tific es­ti­ma­tions to pro­vide a fixed time, vari­able scope ap­proach.

Step 3: Develop, re­lease and mi­grate the data

Lastly, it’s now time to de­velop. When de­vel­op­ing we fol­low our Way of Working. This en­sures a con­sisted and de-risked ag­ile ap­proach to de­liv­ery.

Secondly, we also de­velop us­ing the Codebots PAAS.

The plat­form has been de­vel­oped to in­crease the speed and qual­ity of soft­ware de­vel­op­ment but also con­tin­u­ally mit­i­gate the risk of legacy creep for the new pro­ject. There are two de­vel­op­ment pat­terns that Codebots pro­vides for a Brownfields pro­ject.

The first is a Firecracker mi­gra­tion path­way. This en­ables us to im­port the old sys­tems data­base schema into an ap­pli­ca­tion model and have the bot’s rewrite the new code­base from here. This is per­fect for small ap­pli­ca­tions and data­base mod­erni­sa­tion pro­jects. We used this method for Police NSW. The di­vide and con­quer ap­proach is for larger mono­lithic ap­pli­ca­tions. It en­ables the two ap­pli­ca­tions to run side by side as dif­fer­ent parts are in­cre­men­tally mod­ernised. Please see the Bots that Code book for full path­way de­scrip­tions.

Lastly, once the new ap­pli­ca­tion is built the most es­sen­tial part of the process must be done, the data mi­gra­tion! As the old sys­tem’s data is ac­ces­si­ble, we can cre­ate cus­tom up­date scripts that al­low the old data to be mi­grated across to the new sys­tem. This helps pro­vide a seam­less ex­pe­ri­ence for the busi­ness to progress for­ward.

Following this mi­gra­tion path­way means that you can mod­ernise the ap­pli­ca­tion, busi­ness process and user ex­pe­ri­ence whilst re­tain­ing your busi­ness data. We aim to sim­plify where we can and as al­ways we’re here to help if you need to con­tact us.

Discover Software


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Legacy System Migration Do’s and Don’ts

19 November 2018

Using the fire­cracker method for legacy mi­gra­tion

02 March 2020

Web Apps vs Excel: Which to Use When

20 October 2020

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion