Moving Information Technology (IT) into the sphere of “the business” is still a challenge in a lot of organisations. How to move up requires that the IT/ICT teams demonstrate value (showing how you can support the business achieve its goals) to more senior executives within the business, where to start is always a hard question. Whilst there are many ways to approach this, the roadmap is one of the simplest ways of getting started.
Over the years I’ve noticed that there is little consistency in the generation and development of roadmaps; Infrastructure, Application or even Business structure. This can be for various reasons including:
- There isn’t visibility of the full picture, but you have to show some degree of thought
- Enterprise Architects are now really Technology Architects so the views are skewed towards a technology, conversely there are consultants posing as Enterprise Architects who have nothing more than an MBA and no experience or exposure
- Businesses don’t truly understand what they are doing with ICT or why they need to be planned and not reactive
- It’s a contract deliverable and come hell or high-water you’ll deliver something.
- Newly minted TOGAF, SABSA or other practitioners attack this discipline with too much vigour that they get quickly shutdown by the business.
Regardless of the reason, it is important to be able to show those needing to invest in ICT services, what they are going to invest in and why they are going to invest. I’ve found that providing clear traceability between business objectives, ICT strategies (where available) and the roadmap help you as the architect understand WHY better which helps when presenting up higher the the organisation; communicating in the business’ terms and not techno-speak.
It can also help the CIO/Director of ICT/etc. understand how their organisation is supporting the wider business and its initiatives.
Remember a roadmap is generally for inside an ICT organisation. it requires distilling into bite-sized chunks for management to absorb
So let’s get to it. Building a roadmap can be broken into 7 stages
- Confirm the business’ priorities
- Current State
- Define End state
- Identify the measures
- Gap analysis!
- Sequence the events
- Publish the end goal
1. Confirm the business’ priorities
For some reason I see this being left out of a lot of roadmaps. The business objectives, strategic plans and other key initiatives need to be captured and distilled (they should be available in an ICT strategic plan) into something that identifies what the business wants to achieve and how Technology and Processes can assist reaching those goals. As an example I’ve extracted this from a business’ published Business Strategy document (in this case it is a Government department).
A lot of the time there isn’t a published divisional or even corporate plan, certainly not available to the masses. In this case making an assumption based on what you do know is a good start. It won’t be right, but it’ll be a lot more than what you started with. I’ve seen in some organisations, simply putting an assumed set of business objectives forwards, produces the formal ones for the next iteration.
Whilst having a clear view of the business objectives or the Business Architecture is useful, it isn’t critical for initially getting a roadmap created. Remember this is to start the conversations and lift the profile of ICT in the business.
For this example the below are the four high level points that were generated:
These are extremely generic, however, will ring true for a lot of organisations.
2. Current State
Map out the current state of services, interdependencies and how they relate to the business’s priorities. This doesn’t require a detailed Enterprise Architecture application interdependency map, just basic grouping of services into sensible “chunks” that the organisation will understand (sometimes Application/Data/Technology isn’t granular enough). In the below is a mapping of the four high-level objectives for ICT to the services delivered to the business.
This will help when extrapolating out against other areas of plans and strategies (should you be able to). Other areas to consider documenting or mapping out are:
- Current constraints or issues within the environment; and
- Current business initiatives if they are documented
These can also be used to cross-reference with the roadmap to show how the changes that you are proposing align with these business concerns (even if you don’t have complete visibility). Below is a list of current areas of investment (right) , aligned to initiatives and cross-referenced to the ICT services areas identified above.
This will help you define the end state.
3. Define End state
No doubt you’ve got a good idea of what you want to do, especially if you have the list of current ICT and Business initiatives. What is required next is creating the end state view, where you want to take the ICT services for the Business in order to meet medium and long-term objectives. Going back to our list of high level objectives:
- Responsive IT;
- Collaboration; and
- Business Enablement
This will help fill in any blanks you might have in the where to take the future for those areas defined in the current state. This may be simply projecting out revision upgrades that need to be budgeted for, but now you should be able to tie together the new features and capabilities to the objectives, to completely new capabilities that will enable the business to reach their goals..
4. Identify the measures
Now that we know what it is we want to do and how they relate to achieving the business and ICT objectives, how will the new services be monitored and measured?
This is important when trying to align back to the business’ priorities. One of the best references I’ve found to help make sense of things is the SABSA Business Attributes framework. This provides some guidance on what sort of metric can be used (hard or soft) and how you can measure it. For more complex items, it will allow you to identify additional pieces of work that may be required. e.g. Responsive IT may be related to response times to deploy or access the services or Monitored to deliver “security” that may require independent audit. These need to form part of the roadmap and further cost development down the track.
5. Identify the delta
Now that you have the current state and end state with measures, what do you need to do to get you from where you are to where you need to be. This is done through a Gap Analysis.
A gap analysis can take a number of forms including SWOT analysis, process analysis, financial analysis and functional analysis.
6. Sequence the events
To make sense of the capabilities that you’ve identified above that need to be addressed they need to be prioritised both from a business initiative perspective and from a dependancy one (what needs to be in place to support the end state (this also determines the interim architectures).
The sequencing can be against the business initiatives as described above, taking into account other factors as needed.
Now you have a basic visual representation of the roadmap.
7. Release the hounds… I mean, Roadmap
Take all this work, put it into one place and publish it! This way your roadmap is available for review and critique. You will likely have to extract key pieces of the technology roadmap and put into a medium that those who need to see it can understand it.
Don’t expect to get it right the first time you create it. Remember this is an iterative process and that the goal of this is to put your plans in one place and show how ICT services can support the business achieve it’s goals, and these goals will always shift and move.
Future iterations can get slicker and more complex, taking into account additional factors like insourcing, outsourcing and multi-sourcing and market trends in these areas building up to corporate strategy development with business-mapping.