Mapping your organisation and applications is crucial because it enables you to decide which application to prioritise and which transformation strategy to adopt.
The specific steps you should take, particularly in mapping your applications, are detailed in our book, ‘Modernising legacy applications in the public sector’. However, it’s worth exploring the key differences between mapping organisations and applications here, so that digital, data and technology leaders can get an idea of what’s required.
The key difference between these two approaches is the level of detail you must go into. For your organisation, you can use broad brush strokes to sketch a landscape of how things work and interoperate. It’s also really important to do this organisational mapping first, so that your transformation is centred on user and organisational needs from the start.
When it comes to mapping your applications, you need to be more analytical, data-driven and detailed, so you can develop a single-source of truth about all the applications in your organisation. Once you’ve completed both steps, you’ll have all the information you need to start modernising legacy applications.
Mapping your organisation
When you map your organisation, you do not need to identify and interconnect every service, system, touchpoint and individual within your organisation. Some lightweight mapping of what people’s daily routines are, how they use systems to complete tasks and why they do what they do is all that’s required.
The most important thing to understand is how legacy applications affect the people that use them. This work will give you vital context when you dive deeper into specific applications, by allowing your team to see the real needs and frustrations of users that work with them everyday.
Empathise with the user
It’s important to take a design thinking approach to mapping by focusing in the first place on building empathy for users across your organisation. One of the best ways of doing this is by ‘walking the gemba’, which is a key part of the lean management philosophy.
Walking the gemba involves immersing yourself in the places where the activity occurs in your organisation. For many organisations, it will mean engaging with everything from call centres to accounts departments to help desks, in order to observe, ask questions and record what happens.
Ask the sort of questions that will uncover what really goes on. Try to keep your questions as open as possible and don’t be afraid to ask why something is done in a certain way. This approach might reveal something unexpected but vitally important about real user behaviour.
Sketch the landscape
You are just trying to get a broad understanding of how things work and interoperate, which you can use as a jumping off point for further technical analysis and a reference resource for your team.
This information can then be organised relatively quickly in a half day mapping workshop with your whole team. If possible, you should aim to do this as part of setting up a ‘war room’ for your transformation project. This is where your team will work from and the information gathered during your organisational mapping can be laid out on the walls of the room to serve as a constant visual reminder for the team.
The aim here is to review your research together and to gain a shared understanding as a team. The walls should serve as an opportunity to spark conversation and be kept up to date throughout your transformation, as the team learns more.
Mapping the applications
When you start mapping the applications in your organisation, you’re aiming for an up-to-date and comprehensive list of every application that can serve as a single source-of-truth for your ongoing transformation.
Rather than just compiling a list of applications without much thought, you need to define a clear structure and outline the key attributes that you can compare and contrast in order to accurately account for user needs during prioritisation.
You will start this journey with very little visibility. It’s an iterative process and, with each iteration, more of the landscape becomes visible. Along the way, you’ll find out about other people or teams that have knowledge to help direct you on your journey.
What should be recorded?
It’s essential to make a record of each application and its associated attributes, and also the relationships (or dependencies) that they have with one another.
With attributes, there are two groupings to be considered; technical and organisational. In some situations, the technical attributes are easy to identify, such as the language and version that has been used to develop an application. Other examples of technical attributes might be whether it is off-the-shelf, SaaS or bespoke.
Organisational attributes often need a little more investigation and require you to find the right people to talk to. It might involve interviewing teams to answer questions like which team is responsible for supporting this application? What are the boundaries and journeys that are used? Which applications interact with it?
Every attribute will not necessarily be relevant for you, so pick and choose as you see fit. The full list of organisational and technical attributes we suggest are available in ‘Modernising legacy applications in the public sector’.
Finding and recording information
You will already have a high-level overview of the organisational landscape from the mapping you’ve done. The objective here is to investigate and dig deeper into the various applications.
Invite teams or individuals to workshops if you believe they may have knowledge of specific applications. A good idea would be to run a whiteboard workshop where everyone can see the same mapping and point things out as a group. Also, if it’s possible to view the source code of applications, that’s always an option too. Roll up your sleeves and dive in.
You should treat this whole exercise as a data-driven analysis and therefore record this information in a way that lets you easily extract, query and calculate various factors from it. This will allow you to score different applications and prioritise transformation.
Ensure that when you record the information about an application, its attributes and its dependencies, these are stored individually, so they can be moved around on lists. The data should also be visible to all who need it. A central spreadsheet can work well or even a non-technical solution, such as a whiteboard or post-it notes with strings that show dependencies.
Building a single source of truth
As mentioned, this will be an iterative process and you may use multiple methods to collect this data. Act like an investigative journalist and keep seeking out answers by following up with questions to build an understanding of your application ecosystem that complements your organisational mapping.
Remember that, with application mapping, you are aiming for a single source of truth, visible to everyone in your transformation team and anyone else in the wider organisation that needs to see it. It will be essential for the next stage of prioritisation but can also serve as a living record that helps to reduce technical debt and your reliance on legacy technology for years to come.
This blog post is part of a series that covers modernising legacy applications. This blog post has been co-authored by our CTO Luke Morton, Senior Technical Advisor David Winter, Technical Consultant Ben Pirt, and Content Consultant Joe Carstairs. Keep an eye on the blog for my next post discussing prioritising your application transformation. We are always trying to improve our blog and we’d appreciate any feedback you could share in this short feedback survey.
If you are interested in learning more about this topic, our team has released our ‘Modernising Legacy Applications In The Public Sector’ e-book which will empower you to define and implement the right approach for your organisation to make legacy applications a thing of the past. Download a free copy here.
