Chris Conway
Chief Architect, Quantiv
You’ll have heard the term “road map” a lot last year. After all, the Government’s strategy to relax England’s Covid-19 restrictions was known as the “road map out of lockdown”.
But is it the “road” or the “map” that is the key to finding a solution to a problem?
How do you solve a problem?
To resolve an issue, you’ll need to decide on specific steps (i.e. your route), so you can plot your course of action.
However, you must also have access to information about possible options and what to do if, or when, circumstances change. What happens if you stray, or get blown, off course?
In any journey, you’ll typically:
- Know the start and end points
- Look at a map to get possible routes
- Identify milestones along the way
- Use a map to consider alternative routes if conditions change
So, the “map” is more important than the “road”.
And the same can be said for IT projects.
Why IT teams need maps
In IT, the immediate priority is often to decide what to do, i.e. decide on a “road”.
But to do that – and decide what to do later – it’s important to understand what could be done.
In other words, a map is needed.
IT system designers and architects must interpret the interactions between the operational and IT functions of your organisation, and then manage those interactions.
To do this, an understanding of the technical capabilities (and constraints) of IT is needed. And it’s also essential to understand how your business runs.
Understanding your business processes
Often, the IT capability is the easiest issue to understand (at least for anyone “techy”).
The “what is possible” aspect is usually clearly defined, and changes follow a linear path. Meanwhile, capabilities increase over time as new technologies replace earlier methods of working.
But your operational processes are much less clear. And if they are defined, this will often be through ad hoc descriptions that vary from process to process.
At worst, definitions are simply suggested for current practices. Equally, processes vary almost randomly, following business opportunities as they arise.
What is your business model?
But even within apparently chaotic operational processes, there’s always an underlying theme. This fundamental thread is your business model, i.e. the characteristics of your organisation that persist over time.
Defining your business model in a simple, consistent way is essential for guiding early and future developments.
Here, the purpose of this model isn’t to support a single decision. Instead, it’s to give your organisation a tool to consistently answer the IT team’s questions, and those of other teams. Without this tool, answers are usually ad hoc and only relevant for the short and medium term. But with it, answers are both consistent and reflect the continuing theme of your business.
To sum up, the model aids understanding and provides a critical link in a system development process.
How NumberWorks can help
You can use our NumberWorks method to help create a definition of the major activities within your organisation and the changes they bring about.
This useful tool is your “road map” for identifying your critical data and turning it into meaningful information.
To find out more, call the Quantiv team on 0161 927 4000 or email: info@quantiv.com
