This is part four of our series on road mapping in enterprise architecture, IT planning and portfolio management.
Best practice examples
Software AG works with leading IT organizations which are at the forefront of IT planning and management. To help you as you embark on your own road mapping initiative, we can share some of the best practices followed by our customers:
-
Standardize the visualizations and semantics that business and IT use for collaboration. Data and format inconsistencies can cause confusion in roadmaps, as well as create unnecessary work for staff charged with aggregating information from several “local” roadmaps into master maps. Agree with stakeholders on a few standard formats that fit the company’s information needs and stick with these. Define the “language” used in the forms. This not only means naming conventions but also the various shapes and design elements. Consider the confusion if elements such as circles, blue lines and red lines mean something different throughout a plan? Thus, if an arrow represents a business process in one form, it should mean the same in all forms. Do this for all reports you need to standardize, to ease communication and speed up decision making.
-
Use a central inventory of plans to re-use the current architecture information (applications, support, processes, etc.), reduce efforts needed to consolidate plans and see potential conflicts in planning.
A central repository serves many benefits. While it would be convenient if plans didn’t change, they generally do. By maintaining a central inventory, you’ll reduce the amount of effort required to revise the plan since it is all there and can be used to feed fresh data into plans. By the same token, a central repository makes it easy to consolidate plans. Doing so will reduce the time required to consolidate them when necessary. And finally, by having all information stored in the same place, you’ll be able to compare plans easily and identify conflicts should they arise.
Figure 1: Having a central repository of architecture artifacts and the plans for those artifacts reduces road mapping efforts considerably.
-
Train business users to create planned (desired) IT support with a desired lifecycle.
Road-mapping is so focused on IT/business alignment that it is essential to get peers from business involved. Business needs to be trained to articulate plans and desired lifecycles of IT support in terms of a roadmap. Consider developing webinars or incorporate integrated HELP capabilities into their roadmap environment to help them generate plans. In addition, designate an internal support group to assist roadmap users.
-
Use roadmaps as mandatory documents for planning meetings and input for detailed IT delivery plans.
Once you have created a set of standard roadmap reports - use them. Establish them as the central tool for planning meetings. Planning meetings are invariably characterized by either too much information, too little information, or participants working from different types of reports that are difficult to compare. Roadmap reports could be the end of endlessly endless meetings.As an example, a CIO at a major auto firm sought approval for an IT initiative at a management meeting. In the past, obtaining such approvals was time-consuming and difficult. This time he brought in a printed roadmap, complete with visual representations of the plan. Using this he was able to explain to management over the course of the next few meetings what he wanted to do. As a result, he was able to get them to understand the issues and then obtain buy-in to the plan. Everything he needed to communicate was in the roadmap, saving him and the organization the time and effort that would have been required to go back and obtain answers from his staff.
Figure 2: Roadmap reports as a basis for planning meetings. Here we see a migration planning report. The horizontal axis represents high-level processes. The vertical axis represents organizational units. The blue boxes in the middle are the currently existing applications supporting those processes and org units. The green boxes in the middle are the planned applications to which existing ones will be migrated. The yellow arrows show how and when.
-
Establish guidelines for changing roadmaps.
Especially in organizations where roadmaps are interdependent, roadmaps cannot just be changed serendipitously. It puts the rest of the organization in stress. Establish time intervals for change, who needs to be notified for each instance of change, and approval workflows for changes including approval authority based on the element to be changed and/or scope.
-
Apply rules to roadmaps for governance (e.g. govern component migration stages)
What happens when your department introduces a new application that requires Microsoft Windows 10, but your organization is running Microsoft Windows 7? Establish rules so that only changes to roadmaps that are in line with IT strategy and standards are allowed. Doing so will prevent surprises that could cripple your organization.
-
Make project approval dependent on inclusion in the master plan roadmap.
New projects shouldn’t be considered unless they have been included in the master plan roadmap. Ensure that all project deliverables are integrated into the plan, so you can see the effect of each project and know how it fits with the IT strategy and your business needs.
-
Use blueprints to create consistent and standardized guidelines across separate organizations (e.g. in setting up a new manufacturing plant or sales organization)
Roadmaps enable you to define blueprints for similar plans in other parts of your organization.
Figure 3: The blueprint for the “Trading” domain is shown with the dark blue boxes across the top. Ultimately, all processes (horizontal axis) and org units (vertical axis) should be supported by only one application: “Unified Trading Solution.” In the current roadmap for this user, however, the near-future plans foresee keeping “Genl. Manager” around as well (light blue boxes)
For example, a large utility put together a roadmap for meeting new environmental requirements for several existing plants. When it built a new plant, it searched its plans and found that it could use 80% of the roadmap blueprint. Leveraging such efforts can save you an enormous amount of time and money and ensure a successful project.
-
Keep roadmaps visible
- Once-a-year briefings: “The State of Technology”
- Publish quarterly progress reports
- Include roadmaps in EA’s standard deliverables
- Include roadmaps as part of application project deliverables
- Include roadmaps as input into the budget planning process
- Posters on current state, roadmap, future state
For Gartner clients, here is further reading on best practices for creating roadmaps: “Create Roadmaps That Support Decision Making and Communicate Strategy Effectively,” Published: 3 February 2020 ID: G00407247, Analyst: James McGovern
Stay tuned for the next chapter wrapping up this series on Getting IT Road Мapping Right.