Patterns of Legacy Displacement


We have now spent many of the final couple of many years serving to giant
organizations overhaul their legacy programs. In doing this we have discovered a
nice deal about what works and seen many paths that result in failure. We have
determined to put aside a while to writing down what we have discovered within the type
of varied patterns that we have seen used.

This text acts because the hub for these patterns. Too usually we have seen
organizations caught on a treadmill of half-done legacy alternative efforts. We
assume the important thing to breaking this cycle requires 4 actions accomplished considerably in
sequence however principally iteratively over an organization’s life. We use these actions
as our main construction for organising the patterns that we describe.

We have all the time believed that efficient software program growth entails gradual
launch of priceless options, and we predict the identical is true of writing –
particularly within the age of the
. We have began with this narrative article and can regularly
add patterns as we write up their particulars, in addition to different examples that present
how they mix. We will not promise any dates, since our precedence is our consumer
work, which isn’t wanting legacies to displace. In case you are concerned with
listening to about extra elements of this work as they seem, they are going to be introduced
on Martin’s twitter feed,
and this web site’s RSS

The Legacy Alternative Treadmill

We have now labored with many organizations who’ve made a number of makes an attempt at
eradicating legacy programs. In a single pretty typical group
they’d been by way of an entire collection
of 3-5 12 months lengthy modernization programmes. Every time they’d outline a brand new
tech method, after which work in the direction of that new method as half of a giant
multi 12 months modernization programme.

Sooner or later throughout every programme they hit a disaster level the place altering
enterprise wants would overtake their present tech technique and therefore set off
the necessity to begin over. The place they’d taken a waterfall “massive bang” method to the
programme this meant abandoning nearly all of the work. In different instances
with extra incremental supply approaches, the method taken was to only add a
layer of barely newer applied sciences on prime of an already complicated
panorama. For each situations they had been unable to decommission any of their
legacy stack, key enterprise objectives for value financial savings and danger discount remained
unmet, an all too frequent final result for a lot of legacy alternative efforts.

A number of key elements had been in play of their repeated failures.

Firstly the poor outcomes they had been seeing had been largely a product of
the group; particularly it is management, construction and methods of working.
They thought by simply deciding on newer applied sciences, however leaving every thing
else roughly unchanged, that they’d get completely different outcomes from the
previous. In hindsight this was clearly unrealistic.

Secondly the modernization was to be delivered by a big change programme,
itself comprising a collection of initiatives and groups. These initiatives had been handled
as orthogonal to any BAU (Enterprise As-Normal) efforts. So BAU supply of enterprise necessities
continued towards the prevailing programs whereas the brand new challenge groups delivered
towards a set of necessities agreed initially of the alternative

Over time they noticed a widening hole between what the enterprise really
wanted and what was really signed off at first of the programme. The longer every
programme ran for, the extra acute this hole between the programme plan
vs. BAU and future wants. Whereas change management processes had been
in place so as to add new necessities to a programme, these had been vastly
time-consuming and, because of upfront provider contracts, prohibitively costly.

A 3rd key think about a number of of the failures was the need for
Characteristic Parity with the prevailing set of programs and enterprise processes.
These makes an attempt started by promising to present the enterprise precisely what they
had right now with one way or the other, behind the covers, the expertise having been
“improved”. Having by then seen a number of failures and worrying about
disruption, the enterprise leaders felt this was a decrease danger technique.
The problem right here was even defining and agreeing present “as is”
performance was an enormous effort and it led to a plan for a big single
“massive bang” cut-over launch.

Our observations from this and lots of different organizations is that
expertise is at most solely 50% of the legacy downside, methods of working,
group construction and management are simply as vital to

Breaking the cycle

Clearly there’s a want to interrupt out of the cycle of “expertise alternative
programmes”. Briefly organizations want to have the ability to proceed to ship
enterprise wants whereas on the identical time changing outdated expertise, all
towards a background of accelerating technological change and a more durable
aggressive local weather.

There are a collection of approaches we’ve got discovered may also help with these challenges.
They assist with the problem of breaking the issue into smaller elements to
enable supply of recent necessities in parallel with improved expertise.
Broadly talking they match into 4 classes:

  1. Perceive the outcomes you need to obtain
  2. Resolve how one can break the issue up into smaller elements
  3. Efficiently ship the elements
  4. Change the group to permit this to occur on an ongoing foundation

Perceive the outcomes you need to obtain

It’s vital for a company to agree the outcomes they need to
obtain when tackling legacy. Whereas this will appear apparent, all too usually
completely different elements of a company can have fairly completely different views on the
desired outcomes. Most legacy modernization initiatives contain a number of of
the outcomes we listing under, nevertheless it’s important to determine which of them are
the precedence earlier than setting out on the journey.

Lowering the price of change

A key tipping level in lots of organizations in deciding to deal with legacy is
that desired enterprise modifications begin to value excess of any anticipated
advantages, both because of alternative value (aka delay) or implementation value.
An early warning signal is having to spend weeks and 10’s or 100’s of 1000’s
to make a change to a web site that brings solely a small enhance in enterprise

At this level it’s usually now not attainable to justify making
any modifications that do not ship giant returns on funding. In different
phrases the state of the expertise has began to dictate the scale of change
the enterprise could make. For a lot of organizations this implies the distinction
between making a ‘BAU’ change or having to instigate a bigger challenge.
These bigger initiatives then turn out to be magnets for all of the small modifications
that weren’t beforehand justifiable thus growing their scope, value
and danger

Enhancing the enterprise course of

We have now seen numerous examples of the place enterprise processes have developed
subsequent to legacy programs, the processes turn out to be tightly coupled to the
means that system works with constraints within the system and sometimes workarounds “off system”
shaping the enterprise processes individuals comply with to do their jobs.

One instance we noticed is an airline check-in system that used “inexperienced display”
terminals, because of constraints within the legacy system the method needed to
be adopted in a strict order that means corrections or errors meant
beginning the check-in course of over. Additionally initially the airline had
not provided connecting flights, when this was added it needed to be accomplished
as a separate workflow within the legacy system because of constraints in that
expertise. So if, at check-in, a passenger didn’t point out
they’d a connecting flight the mistaken course of was adopted
together with printing the mistaken baggage tags, solely after this might the
system flag the connecting flight. The roles of the check-in employees and
the passenger’s expertise might have been a lot improved by altering
the method, however this was unimaginable as a result of legacy system.

Given this it needs to be no shock that to replace and alter enterprise
processes in flip requires modifications to the how the supporting expertise works.
Attempting to vary working processes with out altering the expertise usually
leads to “off system” working the place individuals resort to extracting knowledge
into spreadsheets or comparable, engaged on it there, earlier than importing the
knowledge again into the legacy system.

In a single group the entire inventory ordering course of was really accomplished
on a Microsoft Entry DB working on the crew managers PC. They’d
turn out to be annoyed because the legacy system couldn’t assist the
newer working practices of their suppliers. They might do an import
and export of the information a number of instances per week, within the meantime the remainder
of the group would see old-fashioned figures as nobody realized
what was happening.

It’s value noting right here that necessities for a alternative system to
assist import and export of information can usually have a root trigger on this
form of workaround.

Retire an outdated system

The necessity to retire an outdated system is a typical purpose for legacy modernization.
That is usually pushed by challenges in supporting older {hardware} or software program,
with points reminiscent of escalating assist prices and reaching end-of-life
on assist contracts for each {hardware} and software program.

We have discovered it helpful to view the retirement of outdated programs by way of the lens of
the enterprise. So a system being constructed on outdated expertise is just not in of itself
ample purpose for alternative. As a substitute we have to have a look at the enterprise
impression this creates such escalating run prices or the chance created by lack of
assist or data of the system.

Whereas some organizations do plan nicely for obsolescence of older applied sciences,
many appear to disregard the difficulty till it reaches disaster level. In flip, this
tends to drive organizations in the direction of modernization approaches that appear like
low disruption choices or fast wins, these are often anti-patterns
and we describe a few of these pitfalls later.

We have been shocked over time at what number of giant organizations are
working their companies on unsupported {hardware} and software program, shopping for
spare elements on eBay is surprisingly frequent story to listen to. You probably have
legacy tech it’s nicely value doing a correct survey and making a calendar
that includes the varied end-of-life assist dates.

Whereas many organizations give retirement of outdated programs as a key final result
for legacy modernization it isn’t unusual to seek out this does not really
occur, the legacy remains to be getting used on the finish with the related
enterprise objectives remaining unmet.

Imminent Disruption

For some organizations the precise tipping level on tackling legacy can
come up because of an exterior issue reminiscent of a regulatory change, a brand new “begin up”
competitor or a major change by an current competitor. It is usually
at this level when confronted with a “should do” change it turns into clear the cash
and the time required to reply has grown too giant.

The exterior occasion is the factor that makes clear to a company’s
management that they now not have the power to make modifications for a
Proportionate Price.

Newer expertise

Adoption of newer expertise shouldn’t be the rationale for legacy
modernization, simply having newer tech for it is personal sake isn’t a
key purpose for any group. Quite it needs to be chosen and chosen in
ways in which finest meet the present and future wants of the enterprise. A problem
right here is that tempo of technological change is accelerating, the “helpful”
lifetime of expertise is getting shorter. The precise definition
of “helpful” is dependent upon the group, however typically we have to
contemplate issues reminiscent of:

  • Permits a aggressive benefit
  • Match competitor or market choices
  • Permits a Quicker tempo of change
  • Cheaper to vary
  • Has a decrease run value

The alternatives we make right now about the perfect and most helpful expertise will
doubtless be overtaken by higher alternate options in a comparatively quick timeframe.
This makes getting the choice proper on discovering expertise to satisfy future
wants probably very dangerous.

A superb method right here is to not make any selections that can’t simply be
“accomplished over” with 2-3 years. This has implications for each expertise
choice but in addition for general design and method. Choosing an enormous
platform with a 5-10 years pay again time is tough to justify once we
acknowledge this accelerating tempo of change.

Resolve how one can break the issue into smaller elements

Broadly talking this entails discovering the precise “seams” within the present
enterprise and technical structure. Importantly, you must contemplate how
parts of the present answer map to completely different enterprise capabilities. For
legacy programs this often means discovering how one giant technical
answer meets a number of enterprise wants after which seeing whether it is attainable
to extract particular person wants for impartial supply utilizing a brand new answer. Ideally these
needs to be deliverable with minimal dependencies on one another.

A standard objection is that discovering these seams is just too tough. Whereas we
agree it’s difficult at first, we’ve got discovered it to be a greater method than
the alternate options which all too usually lead to Characteristic Parity and Huge Bang releases.
We have additionally noticed that many organizations rule out such an method as a result of
they’re wanting on the expertise, or the enterprise processes, in isolation.
Altering only one a part of the expertise, or updating only one enterprise
course of independently is more likely to fail, but when we are able to contemplate after which
implement the 2 collectively there are methods to “eat the elephant”.

Getting Began

Legacy modernization can appear a most daunting proposition at first of the journey. Like all journey, we
should first try to perceive the preliminary path to take. Additionally, like all journeys, you have to begin from
the place you’re. One frequent downside we encounter is that we frequently appear to start out in a forest with no view of the
panorama forward and subsequently no thought of the path to take. Step one, then, is to climb a tree and
take a great go searching! This implies getting nearly as good an understanding of the present programs and structure
as attainable within the shortest period of time. That is usually tremendous laborious to do and it is simple to get slowed down in
an excessive amount of element.

Luckily there are a selection of actually helpful instruments that can be utilized collaboratively
to get a ok understanding to proceed. These instruments are mentioned
intimately elsewhere however a abstract listing would come with
Occasion Storming,
Wardley Mapping,
Enterprise Functionality Mapping and Area Mapping.
Discover on this listing that we’re primarily taking a look at how enterprise ideas
are mapping into the programs structure, and in flip understanding
how that
structure helps worth era.
It is a view that’s usually lacking particularly for legacy programs.

Patterns for Understanding the Downside
Worth Stream Map † Artefact that describes how customers accomplish their work
Occasion Storm † Method used to grasp enterprise processes

Particularly we discover individuals usually cease discovery model actions on the
boundaries of the legacy programs, “right here be dragons”, go no additional.
With out crossing the boundary and uncovering how legacy programs assist
(or hinder) enterprise course of and actions it’s difficult to seek out
and extract skinny slices to ship.

One other oft neglected and really priceless supply of data are the customers of the programs themselves. In
truth, within the authors expertise that is usually the place you could find the shocking quantities of helpful stuff and
particularly expose the numerous workarounds and shadow IT ecosystem that often builds up round older programs –
that’s, the Entry Databases and versioned Excel Spreadsheets that really run the enterprise. Buyer
Journey Mapping, creating Service Blueprints and Worth Stream Mapping are instruments which were used to good impact
to floor this sort of element.

Efficiently ship the elements

The necessity for quicker change and the power to incrementally ship and
independently change parts of the enterprise with out giant dependencies usually
results in “agile” supply approaches alongside a microservices based mostly structure.
Steady Supply turns into a will need to have for these individually deployable elements.
What makes this difficult past only a regular piece of software program supply is discovering
methods for lower over from, co-existence with and, finally alternative of
parts of an current giant answer. A number of profitable methods exist
together with parallel run, fork on ingress and diversion of movement.

Patterns for Supply
Canary Launch † Roll out a change to a subset of customers
Cease the World cutover † Droop regular enterprise actions whereas slicing over to new system
Revert to Supply † Establish the originating supply of information and combine to that
Divert the Move † Divert key enterprise actions and processes away from legacy first
Darkish Launching † Name a brand new again finish function with out utilizing outcomes as a way to assess
its efficiency impression.
Legacy Mimic † New system interacts with legacy system in such a means that the outdated system is just not conscious of any modifications.
Occasion Interception † Intercept any updates to system state and route a few of them to a brand new

Change the group to permit this to occur on an ongoing foundation

If we step again and have a look at the entire strategy of delivering new enterprise
necessities we are able to shortly see that is solely partly a expertise downside. If
we use newer expertise to chop time and price of constructing options we’ll
then spotlight any points round agreeing necessities and getting the change
into manufacturing.

We want group construction and course of modifications to take
full benefit of the higher expertise, and by “Conway’s Regulation” we
additionally want an structure for our expertise that facilitates this. If
groups and their communications are organized across the current legacy
answer and processes we could have to reorganize them utilizing the
Inverse Conway Maneuver to match the brand new
answer and it is structure.

Legacy programs can constrain and restrict the power to undertake extra
trendy engineering practices particularly these related to eXtreme
Programming and Steady Supply. When changing legacy programs it
is vital to ensure methods of working are modified to make sure we
do not find yourself again with a system that’s gradual, tough and costly
to vary.

Legacy can be the product of an organizations
tradition and management, with out broader change you must anticipate the
identical outcomes as seen beforehand.
We have now noticed many legacy modernization efforts fail because of
“company antibodies” which spot one thing new occurring and act to
reject it from the group.

To present only one instance of the best way a broad group can reject
change; we labored with a really giant telecommunications firm who needed
to construct software program for cell phones. The management all understood this
meant a lot quicker suggestions cycles and extra frequent modifications than they
noticed with current programmes which had been centered on mounted infrastructure.

Whereas the management understood this no modifications had been made to current
working apply or to the center administration who ran these processes. So
current change management processes had been rigorously utilized. Ultimately
the software program groups had been spending extra time filling in change management
types and attending change management conferences than they had been producing
software program. The “company antibodies” labored efficiently to reject the
new means of working.

Organizational change is a giant subject with a lot literature already accessible,
the important thing problem with legacy is usually time associated. Few organizations can
afford to delay legacy modernization whereas they rework (or rebuild, for
outsourcing victims) their complete supply method alongside facet their
group construction and key enterprise processes. Whereas the broader subject
of group transformation is past our scope we do suggest some
methods for making use of and defending new methods of working within the context of
legacy. When you simply change the legacy and do nothing else it’s honest to
anticipate you may changing legacy once more with a number of years.

Patterns for ongoing organisational change
Begin as you imply to proceed † Create your legacy alternative in the best way you could proceed as soon as it’s reside.
Protected Pilot † Create a pilot program for brand new work and detach it from the conventional
company governance course of
New Co † Type a model new firm to pursue a market disruption

There are positively different methods and approaches to group
transformation, we simply highlighted these two as to a point they
enable work to be began on the legacy modernization sooner reasonably than

An instance: Integration Middleware Removing

This instance describes how one among our groups used plenty of Legacy
Modernization Patterns to efficiently exchange integration middleware
crucial to the operation of their consumer’s enterprise as half of a bigger
legacy modernization programme. They mixed patterns and refactorings to
efficiently handle danger to the enterprise, and facilitate consuming this
notably gristly a part of the elephant.

Understanding the outcomes

The problem confronted by our crew was how one can exchange integration middleware
that was out of assist, laborious to vary and really expensive with a brand new
supportable, versatile answer for the enterprise. With out disrupting or
placing in danger current enterprise operations. The middleware in query was
used to combine between a backend finish system and a retailer entrance. Collectively
these programs had been chargeable for promoting excessive worth distinctive merchandise value
tens of thousands and thousands of kilos on daily basis.

This work was a excessive precedence half of a bigger programme. The whole thing of
the backend programs supporting the enterprise had been being changed, and the
retailer entrance was additionally going to be topic to a modernization programme inside
a few years.

So, as per step 1 above, the enterprise outcomes the crew wanted to attain had been outlined:

  1. Enhance the enterprise course of
  2. How? This explicit integration middleware answer contained a major quantity of logic together with guidelines
    core to the enterprise, like which channel to promote a product on, or how and when to current a product on the market
    throughout the retailer entrance. This current system was very laborious to vary, stifling enterprise innovation, and flaws
    within the logic resulted in points like having durations when a product was not even on sale!

  3. Retire outdated system as quickly as attainable
  4. Why? To scale back current (and growing) license and assist prices. Moreover, to mitigate the chance to
    the enterprise created by working crucial capabilities on aged out of assist middleware and database
    applied sciences.

Breaking the issue up: the primary seam and a refactoring

Throughout Inception the crew ran a workshop
with individuals who had deep data of the legacy system, to collaboratively
visualise each the as-is and to-be software program architectures.
Having accomplished this, they discovered a technical seam that might be exploited in
the type of messaging based mostly integration between the legacy backend and the Integration
Middleware. The Legacy backend, an getting older J2EE software, positioned “publish product” messages
onto a queue supplied by a really outdated model of SwiftMQ. The Occasion Interception sample can be helpful right here,
and if carried out as a Content material-Primarily based Router
would enable management over how messages from the legacy backend had been routed,
and create an choice enabling messages to be routed to new programs.

The mixing middleware additionally dealt with messages coming from the Retailer
Entrance (e.g. for product gross sales), utilizing JDBC to immediately replace state within the
Grasp Database behind the legacy backend. Collectively the asynchronous
messaging through SwiftMQ and the JDBC database updates shaped the interface
between the Legacy Backend and the Integration Middleware.

Branch by abstraction

Though, not noticed on the time, the crew had been ready to make use of the Department by Abstraction sample, at a sub-system scale, as
the technique to allow the alternative of the legacy middleware. The
abstraction layer being the queues and the JDBC. By making certain that the brand new
implementation adhered to that abstraction layer it might be swapped for the
“flawed provider” with out impacting the enterprise operations.

The very first thing the crew did was to implement occasion interception by
including an Occasion Router through a refactoring.

(P)Refactoring to add Event Interceptor

The Occasion Router (1) was created with three principal capabilities in

  1. To de-queue messages from one SwiftMQ queue and en-queue them onto
    one other SwiftMQ queue (2). A trivial change of some config enabled the
    Integration Middleware to eat messages from this new queue(2).
  2. Total the refactoring left the observable system behaviour unchanged,
    however the Occasion Router was now a part of the Transitional Structure,
    having been inserted into the message processing pipeline.

  3. The imaginative and prescient for the Occasion Router was to allow, by way of configuration,
    routing of messages to an alternate vacation spot – enabling the brand new
    implementation to course of the publish messages. Occasion Interception
  4. The Occasion Router would additionally present a bridge from the outdated SwiftMQ
    expertise to the brand new ActiveMQ expertise chosen for the goal

Implementing the Occasion router was not as straight ahead because it might
have been. Integrating with SwiftMQ was problematic because of lack of accessible
drivers / libraries and the method was challenged plenty of instances. The
crew understood the worth of the choices that this method would unlock,
and accomplished the work and launched into manufacturing. They monitored the brand new
part within the wild and had been set to incrementally improve its functionality
utilizing new Steady Supply pipelines.

Efficiently ship the elements: constructing out the performance, sustaining the contract

New Implementation and Rollout

The brand new Retailer Entrance Supervisor(1) was now iteratively constructed out by the crew
. Related to this instance, that construct included the Grasp Database
Adapter (2) implementing the Legacy Mimic sample. This was required as half
of the abstraction layer, to replace the Grasp Database with gross sales
data acquired from the Retailer Entrance. Because the Occasion Router didn’t
remodel messages, a Legacy Occasion Adapter (3) (Message Translator) was created to rework messages
into a brand new format, not exposing the legacy world to the brand new, and aligning to
the rules of the brand new structure. The Legacy Storefront Adapter(4) was additionally carried out between the brand new Retailer
Entrance Supervisor(1) and the Legacy Retailer Entrance to isolate the brand new
implementation from future modifications that might be coming when the shop entrance
was changed.

A brand new API was launched on the Legacy Retailer Entrance (5) that the brand new Retailer
Entrance Supervisor was to make use of. Moreover, a function was added enabling name
backs for merchandise printed on the brand new API to be despatched to the brand new Retailer
Entrance Supervisor’s adapter (4). Critically, this enabled the legacy
implementation and the brand new implementation to be run in parallel.

Efficiently ship the elements (cont.): transitioning into reside service – utilizing a second seam

With all the items in place the enterprise had been in a position to check the brand new
answer, however how one can roll it out into reside service in a danger managed means.

To do that they took benefit of one other seam – this time utilizing the
Phase by Product sample. The Occasion Router was enhanced so as to add
configurable routing (6) by product sort in addition to by distinctive
product IDs. The crew had been in a position to check the publishing, administration and sale
of particular person merchandise by ID, after which over time configure the router with
progressively increasingly more product sorts, basically growing the
share of merchandise dealt with by the brand new answer.

When all merchandise had been being dealt with by the brand new programs, the legacy
Integration Middleware was decommissioned, realising the numerous £
saving in license, assist and datacenter internet hosting charges.

Legacy Gone

Altering the organisation to permit this to occur on an ongoing foundation

Our groups had already been working with the consumer, in one other a part of the organisation and had already
efficiently displaced a distinct legacy system.

At an engineering degree throughout the organisation steady supply and good supporting high quality practices
had been now the established norm, and a microservices model structure enabled common and impartial deployment
of containerised providers onto a cloud based mostly platform.

The groups on the brand new programme, working with new stakeholders, wanted to take this different a part of the enterprise
on the identical “agile and CD” journey, and early danger managed releases enabled belief to be earned. Over time it
was attainable to reveal how new engineering and high quality practices together with CD had been mitigating the identical
dangers that had traditionally resulted in larger ranges of paperwork and governance. So much less frequent,
bigger scope releases had been additionally displaced by smaller, extra frequent, larger confidence deployments, and
toggled releases to the enterprise once they had been able to tackle the modifications.

Closing ideas

In fact there was considerably extra complexity and
integration necessities than implied by the simplified story above. An instance
of the necessity for Archeology launched itself shortly after testing the
new implementation in manufacturing. Quite a few enterprise crucial administration
data stories didn’t tally – merchandise had been “getting misplaced”.

After a lot digging the crew discovered that the database utilized by the
Integration Middleware (for storing the state of lengthy working enterprise
transactions) was replicated to the organisation’s knowledge warehouse. By way of a quantity
batch jobs, saved procedures and views this knowledge was made accessible to be used
throughout the enterprise crucial KPI stories.


Further Legacy mimics had been required to make sure that these stories
didn’t break. The crew used a
Wire Faucet on
gross sales messages coming from the Retailer Entrance and utilizing JDBC injected the information into
applicable tables throughout the knowledge warehouse. These further mimics
additionally turned a part of the transitional structure, and can be eliminated when

The method of department by abstraction, and use of patterns and practices
described above was one meant to decrease danger.

Utilizing Occasion Interception (technical seam), Legacy Mimics and Transitional Structure
enabled the consumer to interrupt the issue up. Then segmenting by product (enterprise seam),
on this case product sort, enabled advantageous management of the broader rollout and additional administration of danger.
Total the method allowed the enterprise to proceed with the system alternative on the tempo that was
snug to them.

The method allowed danger to be managed, however got here at a price. A query to contemplate is subsequently
“What worth does the enterprise place on this danger mitigation?” Being express and quantifying it, will enable
a crew to trace investments towards it.
The occasion router and legacy mimics had been a part of an funding in a transitional structure meant to handle
danger. Their roles had been to create choices enabling danger to be managed. It may be very straightforward for such work to be
seen as “throw away” – and as such a price to be prevented wherever attainable. Be express and clear on this
“worth of danger mitigation” vs “value of transitional structure” trade-off.


Leave a Reply

Your email address will not be published. Required fields are marked *