April 23, 2024

In a current challenge, we have been tasked with designing how we might exchange a
Mainframe system with a cloud native software, constructing a roadmap and a
enterprise case to safe funding for the multi-year modernisation effort
required. We have been cautious of the dangers and potential pitfalls of a Massive Design
Up Entrance, so we suggested our consumer to work on a ‘simply sufficient, and simply in
time’ upfront design, with engineering throughout the first part. Our consumer
preferred our method and chosen us as their accomplice.

The system was constructed for a UK-based consumer’s Information Platform and
customer-facing merchandise. This was a really advanced and difficult process given
the dimensions of the Mainframe, which had been constructed over 40 years, with a
number of applied sciences which have considerably modified since they have been
first launched.

Our method is predicated on incrementally shifting capabilities from the
mainframe to the cloud, permitting a gradual legacy displacement relatively than a
“Massive Bang” cutover. With a purpose to do that we wanted to determine locations within the
mainframe design the place we might create seams: locations the place we will insert new
conduct with the smallest potential adjustments to the mainframe’s code. We will
then use these seams to create duplicate capabilities on the cloud, twin run
them with the mainframe to confirm their conduct, after which retire the
mainframe functionality.

Thoughtworks have been concerned for the primary yr of the programme, after which we handed over our work to our consumer
to take it ahead. In that timeframe, we didn’t put our work into manufacturing, however, we trialled a number of
approaches that may assist you get began extra shortly and ease your individual Mainframe modernisation journeys. This
article gives an summary of the context through which we labored, and descriptions the method we adopted for
incrementally shifting capabilities off the Mainframe.

Contextual Background

The Mainframe hosted a various vary of
companies essential to the consumer’s enterprise operations. Our programme
particularly targeted on the information platform designed for insights on Shoppers
in UK&I (United Kingdom & Eire). This explicit subsystem on the
Mainframe comprised roughly 7 million traces of code, developed over a
span of 40 years. It offered roughly ~50% of the capabilities of the UK&I
property, however accounted for ~80% of MIPS (Million directions per second)
from a runtime perspective. The system was considerably advanced, the
complexity was additional exacerbated by area duties and considerations
unfold throughout a number of layers of the legacy surroundings.

A number of causes drove the consumer’s determination to transition away from the
Mainframe surroundings, these are the next:

  1. Modifications to the system have been gradual and costly. The enterprise subsequently had
    challenges retaining tempo with the quickly evolving market, stopping
  2. Operational prices related to working the Mainframe system have been excessive;
    the consumer confronted a business danger with an imminent value improve from a core
    software program vendor.
  3. While our consumer had the required talent units for working the Mainframe,
    it had confirmed to be laborious to seek out new professionals with experience on this tech
    stack, because the pool of expert engineers on this area is restricted. Moreover,
    the job market doesn’t supply as many alternatives for Mainframes, thus individuals
    should not incentivised to learn to develop and function them.

Excessive-level view of Shopper Subsystem

The next diagram reveals, from a high-level perspective, the assorted
parts and actors within the Shopper subsystem.

The Mainframe supported two distinct varieties of workloads: batch
processing and, for the product API layers, on-line transactions. The batch
workloads resembled what is usually known as a knowledge pipeline. They
concerned the ingestion of semi-structured information from exterior
suppliers/sources, or different inner Mainframe techniques, adopted by information
cleaning and modelling to align with the necessities of the Shopper
Subsystem. These pipelines included varied complexities, together with
the implementation of the Id looking out logic: in the UK,
not like the US with its social safety quantity, there is no such thing as a
universally distinctive identifier for residents. Consequently, corporations
working within the UK&I need to make use of customised algorithms to precisely
decide the person identities related to that information.

The net workload additionally introduced vital complexities. The
orchestration of API requests was managed by a number of internally developed
frameworks, which decided this system execution circulate by lookups in
datastores, alongside dealing with conditional branches by analysing the
output of the code. We should always not overlook the extent of customisation this
framework utilized for every buyer. For instance, some flows have been
orchestrated with ad-hoc configuration, catering for implementation
particulars or particular wants of the techniques interacting with our consumer’s
on-line merchandise. These configurations have been distinctive at first, however they
doubtless turned the norm over time, as our consumer augmented their on-line

This was applied by way of an Entitlements engine which operated
throughout layers to make sure that prospects accessing merchandise and underlying
information have been authenticated and authorised to retrieve both uncooked or
aggregated information, which might then be uncovered to them by way of an API

Incremental Legacy Displacement: Rules, Advantages, and

Contemplating the scope, dangers, and complexity of the Shopper Subsystem,
we believed the next rules can be tightly linked with us
succeeding with the programme:

  • Early Threat Discount: With engineering ranging from the
    starting, the implementation of a “Fail-Quick” method would assist us
    determine potential pitfalls and uncertainties early, thus stopping
    delays from a programme supply standpoint. These have been:
    • Final result Parity: The consumer emphasised the significance of
      upholding end result parity between the prevailing legacy system and the
      new system (You will need to notice that this idea differs from
      Function Parity). Within the consumer’s Legacy system, varied
      attributes have been generated for every shopper, and given the strict
      trade rules, sustaining continuity was important to make sure
      contractual compliance. We would have liked to proactively determine
      discrepancies in information early on, promptly handle or clarify them, and
      set up belief and confidence with each our consumer and their
      respective prospects at an early stage.
    • Cross-functional necessities: The Mainframe is a extremely
      performant machine, and there have been uncertainties {that a} answer on
      the Cloud would fulfill the Cross-functional necessities.
  • Ship Worth Early: Collaboration with the consumer would
    guarantee we might determine a subset of essentially the most vital Enterprise
    Capabilities we might ship early, guaranteeing we might break the system
    aside into smaller increments. These represented thin-slices of the
    total system. Our purpose was to construct upon these slices iteratively and
    incessantly, serving to us speed up our total studying within the area.
    Moreover, working by way of a thin-slice helps cut back the cognitive
    load required from the group, thus stopping evaluation paralysis and
    guaranteeing worth can be constantly delivered. To attain this, a
    platform constructed across the Mainframe that gives higher management over
    shoppers’ migration methods performs a significant function. Utilizing patterns reminiscent of
    Darkish Launching and Canary
    Launch would place us within the driver’s seat for a clean
    transition to the Cloud. Our purpose was to realize a silent migration
    course of, the place prospects would seamlessly transition between techniques
    with none noticeable impression. This might solely be potential by way of
    complete comparability testing and steady monitoring of outputs
    from each techniques.

With the above rules and necessities in thoughts, we opted for an
Incremental Legacy Displacement method together with Twin
Run. Successfully, for every slice of the system we have been rebuilding on the
Cloud, we have been planning to feed each the brand new and as-is system with the
identical inputs and run them in parallel. This enables us to extract each
techniques’ outputs and verify if they’re the identical, or at the least inside an
acceptable tolerance. On this context, we outlined Incremental Twin
as: utilizing a Transitional
Structure to help slice-by-slice displacement of functionality
away from a legacy surroundings, thereby enabling goal and as-is techniques
to run quickly in parallel and ship worth.

We determined to undertake this architectural sample to strike a stability
between delivering worth, discovering and managing dangers early on,
guaranteeing end result parity, and sustaining a clean transition for our
consumer all through the length of the programme.

Incremental Legacy Displacement method

To perform the offloading of capabilities to our goal
structure, the group labored carefully with Mainframe SMEs (Topic Matter
Specialists) and our consumer’s engineers. This collaboration facilitated a
simply sufficient understanding of the present as-is panorama, when it comes to each
technical and enterprise capabilities; it helped us design a Transitional
Structure to attach the prevailing Mainframe to the Cloud-based system,
the latter being developed by different supply workstreams within the

Our method started with the decomposition of the
Shopper subsystem into particular enterprise and technical domains, together with
information load, information retrieval & aggregation, and the product layer
accessible by way of external-facing APIs.

Due to our consumer’s enterprise
goal, we recognised early that we might exploit a significant technical boundary to organise our programme. The
consumer’s workload was largely analytical, processing principally exterior information
to provide perception which was offered on to shoppers. We subsequently noticed an
alternative to separate our transformation programme in two components, one round
information curation, the opposite round information serving and product use circumstances utilizing
data interactions as a seam. This was the primary excessive degree seam recognized.

Following that, we then wanted to additional break down the programme into
smaller increments.

On the information curation aspect, we recognized that the information units have been
managed largely independently of one another; that’s, whereas there have been
upstream and downstream dependencies, there was no entanglement of the datasets throughout curation, i.e.
ingested information units had a one to at least one mapping to their enter information.

We then collaborated carefully with SMEs to determine the seams
throughout the technical implementation (laid out beneath) to plan how we might
ship a cloud migration for any given information set, finally to the extent
the place they might be delivered in any order (Database Writers Processing Pipeline Seam, Coarse Seam: Batch Pipeline Step Handoff as Seam,
and Most Granular: Data Characteristic
). So long as up- and downstream dependencies might alternate information
from the brand new cloud system, these workloads might be modernised
independently of one another.

On the serving and product aspect, we discovered that any given product used
80% of the capabilities and information units that our consumer had created. We
wanted to discover a completely different method. After investigation of the way in which entry
was offered to prospects, we discovered that we might take a “buyer phase”
method to ship the work incrementally. This entailed discovering an
preliminary subset of consumers who had bought a smaller proportion of the
capabilities and information, lowering the scope and time wanted to ship the
first increment. Subsequent increments would construct on high of prior work,
enabling additional buyer segments to be minimize over from the as-is to the
goal structure. This required utilizing a unique set of seams and
transitional structure, which we focus on in Database Readers and Downstream processing as a Seam.

Successfully, we ran a radical evaluation of the parts that, from a
enterprise perspective, functioned as a cohesive complete however have been constructed as
distinct components that might be migrated independently to the Cloud and
laid this out as a programme of sequenced increments.


Our transitional structure was principally influenced by the Legacy seams we might uncover throughout the Mainframe. You
can consider them because the junction factors the place code, applications, or modules
meet. In a legacy system, they might have been deliberately designed at
strategic locations for higher modularity, extensibility, and
maintainability. If that is so, they may doubtless stand out
all through the code, though when a system has been below growth for
plenty of a long time, these seams have a tendency to cover themselves amongst the
complexity of the code. Seams are significantly worthwhile as a result of they will
be employed strategically to change the behaviour of purposes, for
instance to intercept information flows throughout the Mainframe permitting for
capabilities to be offloaded to a brand new system.

Figuring out technical seams and worthwhile supply increments was a
symbiotic course of; potentialities within the technical space fed the choices
that we might use to plan increments, which in flip drove the transitional
structure wanted to help the programme. Right here, we step a degree decrease
in technical element to debate options we deliberate and designed to allow
Incremental Legacy Displacement for our consumer. You will need to notice that these have been repeatedly refined
all through our engagement as we acquired extra information; some went so far as being deployed to check
environments, while others have been spikes. As we undertake this method on different large-scale Mainframe modernisation
programmes, these approaches might be additional refined with our freshest hands-on expertise.

Exterior interfaces

We examined the exterior interfaces uncovered by the Mainframe to information
Suppliers and our consumer’s Prospects. We might apply Occasion Interception on these integration factors
to permit the transition of external-facing workload to the cloud, so the
migration can be silent from their perspective. There have been two varieties
of interfaces into the Mainframe: a file-based switch for Suppliers to
provide information to our consumer, and a web-based set of APIs for Prospects to
work together with the product layer.

Batch enter as seam

The primary exterior seam that we discovered was the file-transfer

Suppliers might switch information containing information in a semi-structured
format through two routes: a web-based GUI (Graphical Person Interface) for
file uploads interacting with the underlying file switch service, or
an FTP-based file switch to the service instantly for programmatic

The file switch service decided, on a per supplier and file
foundation, what datasets on the Mainframe needs to be up to date. These would
in flip execute the related pipelines by way of dataset triggers, which
have been configured on the batch job scheduler.

Assuming we might rebuild every pipeline as an entire on the Cloud
(notice that later we’ll dive deeper into breaking down bigger
pipelines into workable chunks), our method was to construct an
particular person pipeline on the cloud, and twin run it with the mainframe
to confirm they have been producing the identical outputs. In our case, this was
potential by way of making use of extra configurations on the File
switch service, which forked uploads to each Mainframe and Cloud. We
have been in a position to check this method utilizing a production-like File switch
service, however with dummy information, working on check environments.

This could permit us to Twin Run every pipeline each on Cloud and
Mainframe, for so long as required, to achieve confidence that there have been
no discrepancies. Finally, our method would have been to use an
extra configuration to the File switch service, stopping
additional updates to the Mainframe datasets, subsequently leaving as-is
pipelines deprecated. We didn’t get to check this final step ourselves
as we didn’t full the rebuild of a pipeline finish to finish, however our
technical SMEs have been accustomed to the configurations required on the
File switch service to successfully deprecate a Mainframe

API Entry as Seam

Moreover, we adopted the same technique for the exterior dealing with
APIs, figuring out a seam across the pre-existing API Gateway uncovered
to Prospects, representing their entrypoint to the Shopper

Drawing from Twin Run, the method we designed can be to place a
proxy excessive up the chain of HTTPS calls, as near customers as potential.
We have been on the lookout for one thing that might parallel run each streams of
calls (the As-Is mainframe and newly constructed APIs on Cloud), and report
again on their outcomes.

Successfully, we have been planning to make use of Darkish
Launching for the brand new Product layer, to achieve early confidence
within the artefact by way of intensive and steady monitoring of their
outputs. We didn’t prioritise constructing this proxy within the first yr;
to use its worth, we wanted to have nearly all of performance
rebuilt on the product degree. Nonetheless, our intentions have been to construct it
as quickly as any significant comparability checks might be run on the API
layer, as this element would play a key function for orchestrating darkish
launch comparability checks. Moreover, our evaluation highlighted we
wanted to be careful for any side-effects generated by the Merchandise
layer. In our case, the Mainframe produced uncomfortable side effects, reminiscent of
billing occasions. Consequently, we might have wanted to make intrusive
Mainframe code adjustments to stop duplication and be certain that
prospects wouldn’t get billed twice.

Equally to the Batch enter seam, we might run these requests in
parallel for so long as it was required. In the end although, we might
use Canary
Launch on the
proxy layer to chop over customer-by-customer to the Cloud, therefore
lowering, incrementally, the workload executed on the Mainframe.

Inside interfaces

Following that, we carried out an evaluation of the interior parts
throughout the Mainframe to pinpoint the precise seams we might leverage to
migrate extra granular capabilities to the Cloud.

Coarse Seam: Information interactions as a Seam

One of many main areas of focus was the pervasive database
accesses throughout applications. Right here, we began our evaluation by figuring out
the applications that have been both writing, studying, or doing each with the
database. Treating the database itself as a seam allowed us to interrupt
aside flows that relied on it being the connection between

Database Readers

Relating to Database readers, to allow new Information API growth in
the Cloud surroundings, each the Mainframe and the Cloud system wanted
entry to the identical information. We analysed the database tables accessed by
the product we picked as a primary candidate for migrating the primary
buyer phase, and labored with consumer groups to ship a knowledge
replication answer. This replicated the required tables from the check database to the Cloud utilizing Change
Information Seize (CDC) methods to synchronise sources to targets. By
leveraging a CDC device, we have been in a position to replicate the required
subset of knowledge in a near-real time vogue throughout goal shops on
Cloud. Additionally, replicating information gave us alternatives to revamp its
mannequin, as our consumer would now have entry to shops that weren’t
solely relational (e.g. Doc shops, Occasions, Key-Worth and Graphs
have been thought of). Criterias reminiscent of entry patterns, question complexity,
and schema flexibility helped decide, for every subset of knowledge, what
tech stack to duplicate into. In the course of the first yr, we constructed
replication streams from DB2 to each Kafka and Postgres.

At this level, capabilities applied by way of applications
studying from the database might be rebuilt and later migrated to
the Cloud, incrementally.

Database Writers

With reference to database writers, which have been principally made up of batch
workloads working on the Mainframe, after cautious evaluation of the information
flowing by way of and out of them, we have been in a position to apply Extract Product Strains to determine
separate domains that might execute independently of one another
(working as a part of the identical circulate was simply an implementation element we
might change).

Working with such atomic models, and round their respective seams,
allowed different workstreams to begin rebuilding a few of these pipelines
on the cloud and evaluating the outputs with the Mainframe.

Along with constructing the transitional structure, our group was
chargeable for offering a variety of companies that have been utilized by different
workstreams to engineer their information pipelines and merchandise. On this
particular case, we constructed batch jobs on Mainframe, executed
programmatically by dropping a file within the file switch service, that
would extract and format the journals that these pipelines have been
producing on the Mainframe, thus permitting our colleagues to have tight
suggestions loops on their work by way of automated comparability testing.
After guaranteeing that outcomes remained the identical, our method for the
future would have been to allow different groups to cutover every
sub-pipeline one after the other.

The artefacts produced by a sub-pipeline could also be required on the
Mainframe for additional processing (e.g. On-line transactions). Thus, the
method we opted for, when these pipelines would later be full
and on the Cloud, was to make use of Legacy Mimic
and replicate information again to the Mainframe, for so long as the potential dependant on this information can be
moved to Cloud too. To attain this, we have been contemplating using the identical CDC device for replication to the
Cloud. On this situation, information processed on Cloud can be saved as occasions on a stream. Having the
Mainframe devour this stream instantly appeared advanced, each to construct and to check the system for regressions,
and it demanded a extra invasive method on the legacy code. With a purpose to mitigate this danger, we designed an
adaption layer that may remodel the information again into the format the Mainframe might work with, as if that
information had been produced by the Mainframe itself. These transformation features, if
easy, could also be supported by your chosen replication device, however
in our case we assumed we wanted customized software program to be constructed alongside
the replication device to cater for added necessities from the
Cloud. This can be a frequent situation we see through which companies take the
alternative, coming from rebuilding present processing from scratch,
to enhance them (e.g. by making them extra environment friendly).

In abstract, working carefully with SMEs from the client-side helped
us problem the prevailing implementation of Batch workloads on the
Mainframe, and work out different discrete pipelines with clearer
information boundaries. Word that the pipelines we have been coping with didn’t
overlap on the identical information, because of the boundaries we had outlined with
the SMEs. In a later part, we’ll study extra advanced circumstances that
we have now needed to take care of.

We’re releasing this text in installments. Future installments will
describe some extra inner interface seams and discover the function of knowledge

To search out out once we publish the subsequent installment subscribe to the
RSS feed, Martin’s
Mastodon feed, or
X (Twitter) stream.