StringOps: Visualising & Validating Dependency Maps

The Problem

Vibrato was recently engaged by a large retailer to work with their IT teams to migrate their on-premises workloads to a cloud environment. We faced a few challenges along the way...

The environment was large, complex, and tightly integrated, with over 200 applications

The responsibility and ownership of applications and systems were split across multiple business units, with varying degrees of knowledge residing with key people

Variable quality and availability of application, systems and architecture documentation

Even with all of these challenges, the biggest issue we faced was validating the information we had collected.

Understanding the Domain

The first phase was all about understanding the environment. We first needed to work out what the systems were, and how they interacted. Creating an application dependency map was the logical first step.

Dependency Mapping is a process used to discover and track the relationships and dependencies between components such as applications, servers, networks and storage. "StringOps" was a tool we'd successfully utilised in the past to visualise a dependency mapping for complex systems.

StringOps came originally came about when faced with multiple versions of systems documentation, all of which were out of date, and none that could be verified as truly correct.

Creating a visual dependency map in a central location provided a means to create a living document which was constantly being updated. It quickly became the 'go-to' source of truth.

The process we used to create the visual dependency mapping was straight-forward.

Document the current known state of the environment

Run workshops with business and technical stakeholders to collect in-depth application, systems and integration details.

Find a huge wall

Represent applications and other components as cards on a wall. We used regular index/story cards, capturing the component name and a category (such as business unit/function).

Link cards together with strings to represent dependencies between systems. Two different string colours can be used to represent inputs and outputs, respectively.

Finally, bring all the business and technical stakeholders together around the wall to validate what we'd found. This was a key part of completing the mapping process

It ended up looking like the photo below and spanning more than 6 metres of wall.

What StringOps Achieved

Working together to create the dependency mapping worked well in many areas, and also had some unexpected benefits.

The mapping provided vital information that enabled us to work out how to migrate the workload.

'Hot-spots' with multiple inputs and outputs showed us which systems were business critical.

Conversely, we were able to identify a large number of applications and services that did not need to be migrated at all.

It brought together people to collaborate on a shared business outcome.

Visual aids, such as a StringOps wall, are great for understanding the problem domain. Many people are visual thinkers; rather than presenting a spreadsheet with multiple rows/sheets, the StringOps wall enabled people to quickly process and digest information.

A current, up-to-date map of the environment was created. Great source of information for the business going forward.

The validation stage generated healthy discussion and interactions between stakeholders. Whilst around the wall, they were actively updating and correcting information.

A common challenge we face is getting business teams and IT teams working together, using a common language. The StringOps wall provided that common language.

The large scale of the dependency mapping drew several comments and was a talking point for other areas of the business, with many other business groups showing interest in the wall and providing further feedback.

Last but not least, the whole exercise was a lot of fun for all involved! Check out our FREE consultation if you'd like to be involved too!