The document discusses the challenges of systems decoupling after years of consolidation. It emphasizes the importance of understanding the strategic drivers for change, mapping business processes and transaction flows between existing and new systems, and identifying impacts and changes needed. Opportunities also exist to improve transactions and architectures during decoupling projects. Careful planning is required to navigate the complex changes while maintaining operations.

1. Systems decoupling:
a perfect storm
Systems decoupling: a perfect storm
For many years now, a driving philosophy for IT departments has been consolidation. Disparate systems have been
merged together, architectures have gone SOA, enterprise resource planning software has been implemented and
management reporting has been streamlined.
But what happens when systems decoupling needs to take place? What happens when, after years of
consolidation, your business and systems processes need to be separated? Perhaps the market has turned and a
business unit needs to be sold, or a change in systems vendor requires replacing a legacy system, or new legislation
requires a different way of working. These are all real possibilities that need careful consideration.
As the skies turn to grey, are you stumbling in the dark? Understanding why and where
Firstly, it is essential to understand the strategic drivers for the decoupling – the benefits case. What has created
the need for the change? This may appear obvious, but it’s worth spending some time ensuring everyone’s
objectives are aligned. All too often a team thinks that they are on the same page only to spend a bit of time
collectively talking about the problem and realise that their understanding differs.
Secondly, it is essential to thoroughly understand what happens where. There are different lenses that can be
applied: business process, services catalogue, systems architecture, transaction flows, etc. The selection of the
appropriate lens to use will depend on the benefits defined in the business case, type of organisation, nature of
transaction flow, systems architecture, etc.
Information to support the understanding of what happens where can be collated from many sources: observation
at the coalface, reviewing the services catalogue, initiating and following test transactions, scouring system
manuals, conducting workshops, viewing database schemas, interviewing stakeholders, etc. It’s a laborious task,
often complicated by the very real gap that tends to exist between how the organisation mandates processes to
work, how people think the processes work and how operational realities mean the processes actually work.
Mapping a course through the clouds - understand specifically what requires changing
Armed with knowledge of the process and systems architecture contextualised by a benefits case, it is time to
begin redrawing the line around what continues to be in, and out, of the future state architecture. Depending on
the lens deployed, this could be by service, business process, functional system, logical transaction or any
combination of these variables.
For each item “outside the line” it becomes necessary to understand what happens to the transaction / data
affected by that item. If a business unit is being sold, it might be as simple as handing the transaction over to the
purchasing company. If an existing system is being replaced, the transactions may need to be replicated either in a
new system or elsewhere in the architecture.
For more information about our www.bsgdelivers.com // @bsguk
service offering, please visit our +44 20 7390 8674
website or contact us info@bsguk.co.uk
Business Systems Group (UK), Registered in England No. 6150570, 230 City Road, London, EC1V2TT
www.bsgdelivers.com // @bsguk

2. Additionally, thought should be given to the unintended consequences of changing the transaction. Good
questions to ask include:
• Is the transaction used as a service by another system or function?
• Is data created by the transaction used elsewhere? How will those transactions function in the new world?
• What data integrity issues could be created by removing or editing this information?
• Are there any legislative considerations around moving or removing this data?
Understanding the answers to these questions is essential in the design of the future state architecture. It also
starts to answer questions around who to engage with and inform about the change.
Every cloud has a silver lining
It is important not to be blind to the opportunities presented within the project. For every transaction where
there is system change, there is an opportunity to effect an improvement. Additionally, the introduction of new
technology may create opportunities to improve transactions not directly affected by the decoupling. At a macro
level, there may also be an opportunity to reshape your architecture; perhaps moving from a very silo-oriented
approach to a service-oriented one.
It is far more common for projects to introduce new features and functions than introducing wholesale
improvements to existing ones. The opportunity to sweat existing infrastructure should be considered and, where
it makes economic sense, seized.
Hardtack to starboard – getting on with it
These projects will likely involve both commissioning new systems (or components) and decommissioning existing
ones, all while maintaining on-going operational integrity. Time will be demanded of a large stakeholder
community and a need to make some really tough decisions.
Decoupling systems is not easy. Difficult projects – in any context – need to be driven by a clear benefits case
which is used to ensure ongoing stakeholder commitment. Additionally, this type of project needs to be informed
by a deep understanding of how transactions flow within your architecture. These two aspects point towards
needing to ensure that the journey is only commenced once the route has been clearly outlined.
BSG (UK)
BSG is passionate about being a proactive force for positive change. Our clients have a deep understanding of
their organisations’ strategic intentions – their “why”. We have observed that many of these organisations
struggle in the gap between intentions and delivery – the how, what, when and who of delivering against strategic
ambitions.
Addressing this is all about designing practical programmes and projects which will deliver the “why”.
Programmes and projects need to have a clear, strategy aligned, benefits case. Executing change is about working
in the detail of these projects to reliably deliver the business needs. It is about acting as the bridge between the
business stakeholders and the technology implementation.
BSG’s consultants are able to play a transformative role at all stages of the project lifecycle. This has resulted in a
significant track record of ensuring that a business is supported in delivering their “why” across many hundreds of
programmes and projects.
A collection BSG (UK) BA www.bsgdelivers.com // @bsguk
practitioner insight can be found +44 20 7390 8674
at http://bit.ly/bsgukinsight info@bsguk.co.uk
Business Systems Group (UK), Registered in England No. 6150570, 230 City Road, London, EC1V2TT
www.bsgdelivers.com // @bsguk