IT strategy and master planning

IT Strategy and Master Planning (ITSMP) is a key concept of enterprise architecture management. It consists of defining the strategic target architecture and developing a master plan—that is, a road map to get from the current situation to the desired target landscape. ITSMP is typically part of other overarching processes. For example, target architectures are derived from the business strategy process. Meanwhile, master plan development interacts strongly with project portfolio management and demand management. There are also strong relationships with application portfolio planning and technology road mapping.

But ITSMP is not just another IT management approach. While most other approaches are IT-driven, ITSMP is business-driven. The core idea is to ensure business-aligned IT. Defining an organization’s strategic target architecture has an important prerequisite: a business strategy. Indeed, ITSMP is a method that enables business to achieve its strategic goals. IT and business management recognize the benefits of business-aligned IT and they want to realize those benefits. Nevertheless, only a few enterprises have managed to establish a sustainable ITSMP practice. Why? Because establishing a successful ITSMP practice is challenging. Process interfaces and the interlinked and interdependent nature of data make it hard to know where to start and what it takes to be successful with ITSMP.

This white paper aims to help. By reading it, you’ll learn about different IT management and planning approaches to put ITSMP into context. You’ll gain a greater understanding of ITSMP and definitions of business-IT alignment. You’ll also learn about best-practice models and recommendations, including prerequisites for the ITSMP process, ideal organizational structures and how to ensure the “right” level of business-IT alignment.

Planning the future IT landscape of an organization can be done from very different perspectives and using different approaches. Three typical examples are: ITSMP, Application Portfolio Management (APM) and Technology Portfolio Management (TPM). Let’s look at the differences between these approaches, starting with the main problem they try to address. The typical IT landscape of a multinational company is scattered and disordered. This is often a result of federated organizational structures—that is, independent organizations solving similar challenges in an individual, unsynchronized manner. It is also a result of post-merger situations, as each new acquisition comes with its own IT baggage. Changes of business models and re-organizations have contributed to the disordering of IT as well. A scattered, disordered landscape generally reflects weak governance in the past, which led to chaotic, unstructured growth of IT instead of a planned, orderly one. There are numerous other reasons, but the result is the same: the larger and the more federated an enterprise is, the more scattered the IT landscape tends to be. “De-scattering”— or consolidating—the IT landscape is at the core of problems that ITSMP, APM and TPM aim to resolve.

So, how do you consolidate a scattered IT landscape? Scattered in this context really means an accumulation of similarities and redundancies. At most large enterprises, there are many applications with similar functionality in use. Purchased commercial-off-the-shelf applications are mixed in with highly customized or home-made applications. There are multiple similar technologies in place that require different skills to operate them. There are generally simply too many things around, leading to increased complexity when trying to understand and manage the landscape. IT is also simply too expensive. Consolidation starts with reducing the complexity. Standardization is a key way to consolidate. Standardization can be achieved in various ways: APM, TPM and ITSMP are three of the most important ones, each one addressing a different scope.

TPM defines the future IT landscape based on an evaluation of which technologies can be regarded as fit for future use—i.e., fit for purpose and budget constraints. Here the desired result is a landscape based on as few different technologies as possible—for example, databases or operating systems—for a dedicated purpose.

APM defines the future IT landscape based on an evaluation of applications across the enterprise. It looks at the applications from different perspectives—for example, costs, technological platform and risk profile—and then aims to optimize the landscape along these multiple dimensions. The planning perspective within APM is focused on the structured evolution of the current portfolio and it is, in this sense, a bottom-up planning approach. Important in this context is the establishment of governance of decisions on changes to the application landscape, ensuring that landscape performance is not impacted by change. The expected result of APM is potentially, but not always, a landscape with a reduced number of applications; it is always an optimized landscape managed within a clearly defined portfolio governance process.

ITSMP has another focus: Like APM, it has an application landscape planning focus only it is topdown. The focus is on application usage by the business. Defining the future IT landscape in this context means defining the intended application usage—which applications should be used where and for what purpose. In other words, which parts of the business execute which processes and what IT do they use for this? Master planning defines which application should be introduced (where and for what purpose) and which application should be phased out and when. Accordingly, the desired consolidation outcome is standardized usage. Depending on the specific organization’s approach, this could mean re-using applications across different organizations or within the same organization for multiple tasks.

ITSMP, APM and TPM are not conflicting approaches; a well-run enterprise architecture management practice includes all three. The decision on which applications should be run within an organization needs to be based on alignment to the technology road map and also on an understanding of where an application can be used efficiently and effectively. Nevertheless, this does not mean that the three approaches have to be introduced at the same time with the same priority. Indeed each individual organization will have needs and pain points that will govern the priority given to APM, TPM and ITSMP.

Looking at these three complementary approaches, we see that the focus, and differentiator, of ITSMP is business-IT alignment. But what does business-IT alignment really mean?

Firstly, for some IT organizations business-IT alignment means changing their perception of themselves and of their business partners. Sometimes IT comes across as a topic that is complex, difficult, and hard for anyone outside of the IT organization to understand. There is a truth in this. IT is an expert issue, and this perception alienates business partners who need to be engaged. The IT organization becomes the department the business turns to only when there is a problem or urgent demand so IT is perceived as a “necessary evil.” Business-IT alignment is about makingIT transparent and understandable, and enabling the business to make the right decisions about IT. It is about turning the IT organization from being a cost factor into being a trusted partner.

Business-IT alignment is a concept that increases transparency. The core vehicle for this is a description of application usage in business terms. The ITSMP terminology for this is a business support. Business supports describe which applications are used by which parts of the business to perform which activities; which organizational unit uses which applications to perform which processes. Labeling this a “business support” indicates the understanding of the IT-business relationship: IT doesn’t exist for the sake of IT; it exists to support the business, to enable the business to perform. ¹

The most important benefit of documenting business supports is increased transparency, which also simplifies business-IT communication. It makes it easier to understand the impacts of planned business changes. For example:

• What applications would be affected if the business model changes for a part of the business?
• Where else are those applications used?
• How complicated is the change?
• How long will it take?
• How much will it cost?

Documenting business supports also helps explain IT strategies. For example:

• Where are we changing the applications in use?
• What is the rationale behind the plan?
• What are the costs and benefits?

All of these questions can’t be answered without understanding the overall application usage.

For ease of communication, business supports are typically depicted as a matrix in which organizations and processes are the axes and the business supports are represented as elements within the matrix cells. This matrix is often referred to as a business support map.

Business support is the most important mosaic stone that makes up business-IT alignment, but there are more mosaic stones that help give a full picture. Adding life-cycle information turns the static picture into a dynamic one. No IT system is made for eternity. Gathering and maintaining life-cycle information is crucial to getting control of ongoing changes in the IT landscape, thus turning evolutional change into planned change.

Another advantage of the business support map is its ability to support the communication of issues. For example, if IT health indicators, such as cost or numbers of incidents, are mapped on the business support map using colors or other indicators, it quickly becomes clear where the problems lie. The business understands which process supports are expensive, and this can be the basis of an alignment discussion. The map also shows which organizations are impacted the most by incidents for a process and helps with budget discussions concerning technology overhauls. Business continuity management also heavily depends on this kind of information. This is an area in which interfaces to disciplines such as APM and operations are needed as they usually have the information to be mapped on the support map. Adding the mosaic piece of mapped data increases the value of ITSMP.

Another important piece of the mosaic is the distinction between existing, planned and intended business support. These are typically referred to as operational, tactical and strategic business support. The core idea of business-IT alignment is to tailor IT to business needs. Capturing strategic business needs is the first step and translates into guidelines for IT. From this, a corresponding target IT landscape needs to be developed. This target landscape will be influenced by the existing one, as blank-slate approaches are simply too expensive and not feasible. However, it is an absolute core principle of ITSMP that the target landscape is not only the result of a SWOT analysis of the current landscape. It is the result of an understanding of strategic business needs. The result of this process is the strategic business support map.

Moving from the current IT landscape to the target state—the strategic business support map—is not usually done in one step. It usually involves various phases over several years. These phases or stages have to be planned at a high level using tactical plans. This is the master planning part of ITSMP, and the result is expressed as tactical business supports that are shown in tactical support maps or master plans.

What are the typical pain points that lead an enterprise to initiate an ITSMP?

One main reason is standardization to address scattered application landscapes that lack re-use. There is high potential for re-use within enterprises that have duplicate large organizations with similar business models—for example, manufacturers with multiple production plants. Regardless of where they are located, a car assembly plant always assembles cars and a refinery always turns crude oil into refined petrochemicals. So all plants could have the same IT landscape to achieve benefits of scale.

ITSMP helps expose differences in the landscape between different organizations of the same type and provides blueprints if new organizations of the same type are to be created. This is relevant for global retailers, financial services providers, logistics companies and any other large enterprise.

A similar pain point is media discontinuity within a process, i.e., different IT systems are used for many activities within one process chain. While using specialized IT systems for dedicated activities within a process chain may have functional advantages, there are also significant risks. For example, seamless IT support for a process using diverse systems increases the complexity and inherent risk of integration. Other problems are data ownership, the number of dependencies to be considered when implementing change and, last but not least, the increased cost of IT support for the process.

A third driver for starting ITSMP is business model change. Changing the business model means, for example, providing new products, entering new markets and delivering new services. To make this change, new capabilities have to be established and existing ones, which are no longer required, may need to be retired. Change to the business capabilities today almost automatically means a significant investment in the IT landscape. ITSMP supports designing and planning this change.

A further important driver is re-organization on a massive scale—for example, in a postmerger or carve-out situation. The most important and challenging task in any post-merger situation is integrating the merged organizations. Indeed, many mergers fail, sometimes very dramatically leading to billion-dollar losses due to problems in the integration project. Integrating the IT landscapes is crucial and can be even more complex than integrating the business side. The IT landscapes of the independent organizations can be highly incompatible and—if the business models are similar—they can overlap and be redundant. ITSMP gives companies the mechanism to analyze the two IT landscapes, to deduce a strategy for integration, and to create a plan for execution.

Usually, change starts with planning but not in this case. ITSMP is about controlled, planned changes of the IT landscape. However, to be able to plan the IT landscape in a controlled manner, the way in which IT planning and management is done has to change first. Running ITSMP successfully requires well-defined processes with clear roles, responsibilities and rules of engagement. It needs to follow a clear methodology using a common terminology. Success also requires a senior management commitment to turning ITSMP into a sustainable, business-as-usual process. Here are general recommendations and best practices on how to establish ITSMP in the enterprise. These recommendations are based on Software AG’s successful ITSMP projects in a large range of industries.

Prerequisites

No matter how they get started, all ITSMP projects share a common prerequisite: They need transparency. In order to develop a target architecture and plan change, you need to know your starting position. For successful ITSMP, you need transparency into:

• The current application landscape. At a minimum, all applications and their life cycles must be documented. A functional description of the applications is very useful.
• The business reference model. To plan application usage, you need to know where an application is used to do what. The “where” typically refers to organizations whereas the “what” typically refers either to a capability model or a process model.
• The current application usage. This is basically interlinking the application landscape with the business reference model using the concept of a business support.

Understand the current application landscape

To be able to plan your future landscape, you need to know the current landscape. Best practice models on how to structure and understand your landscape are not part of this document, so just a few general remarks:

The core prerequisite of landscape analysis is an agreed-upon terminology and methodology. Questions like “What is an application?” “What is the difference to an infrastructure component?” “What is an application version?” “Who owns which applications?” and so forth may sound simple at first—but they are not. Ask ten enterprise architects what an application is and you will get ten fairly similar but, in detail, different answers. And details definitely matter in this case. To be able to plan the application landscape—to define the landscape—all definitions of what the landscape really is must be clear and agreed-upon. And last but not least, the relevant data must be gathered. Accordingly, the ITSMP process requires an agreed-upon and sustainable process in order to capture at least the core application data. This really means that ITSMP cannot be done without having at least a basic APM process in place.

Understand your business reference model

Alignment to business, the core ITSMP paradigm, means having to understand the business. How is it structured? Who does what and where? For this a business reference model is required, which typically consists of an organizational model and a business process or business capability model. Other aspects may be needed such as a model of the market products delivered or of the sales channels used. For the core models—organization and process or capability—conventions are needed to guide creation of the model. Conventions to help decide what should be included in the model and what level of detail are required, e.g., should process and organizational models be detailed down to the third level or further? There is no one-size-fits-all answer to this, but there are some guidelines that help derive the models.

Be as high level as possible and as granular as necessary

The more granular you define the model, the more objects you will need to maintain and the more likely it is that the model will change. For example, you could split the information that the organization “Sales UK” runs the process “Close customer contract” into “Sales Scotland, Sales Wales, Sales Northern Ireland, Sales Northern England, Sales Southern England, Sales London” run the process “Close customer contract.” The effort involved in documenting this information (and maintaining it) is six times higher. This is justified if the involved sub-organizations really plan and use different IT. It is basically a question of finding the proper planning level for thebusiness activities, i.e., the lowest level where the organizational entities are supposed to operate differently. Increasing granularity increases data maintenance efforts. It is also not very useful for top-down planning and ITSMP is a top-down process. ITSMP is about defining application usage patterns and standardization— and a standard is most useful if applied as broadly as possible.

Keep the reference models stable

Change may be the only constant in this world; however, stability of parameters is extremely important for planning purposes. Organizations keep on changing, so process or capability models need to be continuously adjusted. To master this challenge, it has to be understood what “change” really means. It does not matter how human resources or development are currently labeled, it is more important to know that there is an HR or development organization. For IT planning purposes, it is also not necessary to mimic the complete organizational chart with its reporting hierarchies. It is necessary to have a recognizable structure allowing you to map your stable planning entities to the volatile reality of the actual organization. For the process and capability models, stability is given to a certain extent by the granularity chosen: the higher the level, the lower the probability of change. More important here is to establish a proper change management process so that changes are channeled into manageable slots.

Roll-out recommendation

Analysis of customer ITSMP projects has shown that there is a relationship between the time and effort put into defining the business reference model and the success achieved with ITSMP. This is especially true for the definition of organizations that are to be planning entities. The resulting choice of organizational model was more than just an agreed-to organizational chart: It changed the planning processes radically.

It was observed that those enterprises that have their own “virtual” organization structure for IT planning purposes also had better planning accuracy—even when faced with massive enterprise restructuring (e.g., the divestment of a major acquisition or organizational restructuring in the face of the 2008/2009 financial crisis). Due to this, it is strongly recommended that you take time to choose the right business reference models. It is better to get this right before rolling out the planning process than to start with a preliminary idea and then have to adjust it afterwards. This is one of the few areas where we do not recommend a “start simple, adjust the detail level afterwards as needed” approach. Adjustments in this area are extremely hard to do. Adjusting the planning levels of your strategy and road-map management basically means revisiting all plans that have already been created. Accordingly this tends to happen only if the initial planning level was an extremely bad choice. Any time spent on a well-defined structure upfront is time saved many times down the line.

Capturing the current application usage is an essential prerequisite to planning future usage and the future target architecture. To be able to do this, all prerequisites must be in place (agreed-to modeling conventions and business reference models). When looking at the issue of current application usage with respect to planning, there are two things that should be considered:

• Current application usage must always be up-to-date in order to be able to plan reliably. For this, processes need to be established which ensure data is current. This is not a oneoff activity.
• To plan the future, you need to know the current state of the IT landscape and the current state of any plans to change the landscape. For this purpose, a life-cycle and status concept is required to enable planning, and it has to be documented as part of the application data maintenance and planning processes.

Roll-out recommendation

Accurate and up-to-date data is crucial, but establishing the related processes to achieve this is often more difficult than you would expect. One of the main reasons is simple: The people contributing the information are not often the people who benefit from it. Whereas landscape planners typically benefit from the information provided by application managers, the individual application managers often see little benefit, but they do see the workload of provisioning the information. One approach to this is selling the advantage to the stakeholders involved—particularly to the application manager—that their contribution brings to the IT organization as a whole. While being the right message, this usually does not alone achieve the desired result. The following methods have however proven to be successful motivators:

• Data re-usage. People will be more likely to provide data if you re-use it in reports. That data could include overviews of KPI performance or landscape plans.

• Peer pressure. Implementing more use cases based on ITSMP planning data will lead naturally to more stakeholders being involved. This will increase the pressure to deliver accurate and up-to-date data. Also it is more likely to lead to contributors benefiting from information that they provide.

• Making data maintenance part of the process. Making data provisioning a part of a quality gate in approval processes helps ensure that it gets done. It is quite reasonable to demand, e.g., that project deliverables—including application usage—be documented before budget is assigned.

• Implementing data reviews. Periodical review processes are useful in focusing attention on the topic. In these the contributor has to state explicitly that the data still is up-to-date. This is often introduced under the cloak of IT compliance controls.

• Senior management attention. In the very end, all enterprises are hierarchical organizations and if senior management requires information, it is up to the lower levels in the hierarchy to deliver it. So far so good. However, the real challenge is that information providers often do not report to the information consumers directly—even if the latter are on a higher level (e.g., IT strategists and enterprise architects are not the typical line managers of application managers). Accordingly, it is crucial to engage and involve the respective direct senior managers—supporting this with targets and management reporting.

Make sure roles are clear

ITSMP involves or impacts different phases of IT planning and management. Behind each of these phases there are clear tasks and specific roles that are responsible for these tasks. The peoplewho take on these roles need to understand their role and their expected contribution. They also need to understand the processes that they are part of. They need role clarity.

The core activities involved in ITSMP are:

• Defining a strategy, i.e., the target state
• Defining a road map from the current state to the target state
• Monitoring implementation of the road map

Each of these activities in a large enterprise may be owned by a different team or responsible group. This helps deliver role clarity and avoid conflicts inherent to the roles. However, when this is not the case and the roles are taken on by a single team, it is important to ensure that there is a clear understanding of the responsibility and governance behind each activity. Let us now take a look at each activity in detail.

Defining the IT strategy, the target architecture, is a top-level architect activity that is typically owned by an architecture team (or architecture board) reporting directly to the CIO or CTO. Within federated enterprises with strong, relatively independent organizations, such teams are typically found in each organization with a coordinating counterpart at group level, typically reporting to a group CIO.

Strategy boards need to have a respected position in the enterprise with a high level of seniority. There are various reasons for this. Firstly, the overarching IT strategies for which they are responsible, e.g., standardization or technology renewal, impact large parts of the enterprise. Therefore, the range of influence of the strategy board needs to be wide. Secondly, to be successful they have to engage senior business management to ensure alignment to strategy and also to get the necessary buy-in for the significant levels of investment of financial and human resources required for strategy execution. This type of engagement with senior business managers can only be done if the architecture board itself has seniority. Thirdly, to be able to do their job, strategy boards require a broad scope of information on the operative performance of business and of IT. Only by having a respected position in the enterprise, by having seniority, canthe architecture board ensure that the necessary KPIs are monitored and that they are available to them.

Equally important as seniority of the architecture team is expertise. Combining expertise and seniority is a difficult balance as the former requires detail and the latter an ability to step back from the detail and see the big picture. To attain this balance, the recommendation is to have specialization in the architecture board for business capabilities (or business processes) at a high level—typically at the second level in the business capability hierarchy. This high-level specialization along business themes ensures that the best practices across different organizations are identified and synergies gained. Organization-centric specialization, e.g., for a business unit, should be avoided as this usually ends up mirroring the organizational politics and not delivering the synergies that are possible.

Compared to the strategy definition, defining a road map is done at a lower level in the company—closer to the business units and their needs. Nevertheless, it is still a planning activity and as such should be separate from operational implementation. It is typically an activity for an enterprise architect. The main challenge of a road map definition is that the strategic target set up by the architecture board is often not achievable in a single step. Take a typical example: The IT strategy board decides to replace the numerous CRM systems within a multinational with a common solution. The current systems cannot be simply turned off and replaced overnight: Data has to be migrated, interfaces re-coded, new contracts entered into and others cancelled, SLAs adjusted, training prepared and so on.

Also there are often local requirements—for example, country-specific legal regulations — that need consideration. The road-mapping task is to understand the local business and IT environment and create a set of digestible phases that will move the organization from the current state to the strategic target.

As the starting positions are very different (dependent on the local environment of each organizational entity) a road-map definition should be organized in an organization-centric manner. This is not necessarily at the operative organization level, but should be at a level low enough to cover shared needs (i.e., legal requirements). A typical intermediate roadmapping level is a geographical cut: There is a common road map at country level, whereas final implementation details are then planned for the single locations within the countries. As discussed, the overarching responsibility for road mapping should be organization-centric. However—depending on the team size—the road-mapping responsibility within an organization would be further divided along business capability (or business process) lines in order to promote expertise and best practice.

Defining a suitable road map involves a lot of communication and coordination. The planners require input from the operational organizations to be able to design reasonable implementation phases and a high level of interaction with other planners to synchronize their plans. Also, during the development of their road maps, planners often discover (or believe) that the general strategy is not fully feasible with a justifiable effort for their organization. Accordingly, there is a need for discussions with the strategy board on approval for local exceptions. A formal conflict and exception process can make this process more transparent and less political. As planning requires a high level of coordination, it is important to give the task to people with good communication skills.

Operative road-map implementation with all its multifaceted disciplines—for example, project management, software configuration, testing approaches and release management—is not part of ITSMP and as such not the focus of this white paper. However, it is essential from an ITSMP perspective to monitor implementation. This helps ensure that strategies and road maps end up as on-the-ground implementations and that the current status and problems of strategy implementation are known.

Monitoring offers an important feedback loop. No strategy is an island. The strategies and road maps are interdependent and rely on interdependent IT projects for implementation. Knowing problems with one road map helps to identify at an early stage the full impacts on the implementation of other road maps and strategies— potentially giving the strategists and planners the chance to avoid substantial business impacts, such as delayed product launches. It gives them the chance to re-plan and re-scope early, before too much damage is incurred and in a manner aligned to business strategy.

As monitoring implementation effectively means monitoring the deliverables and timelines of major projects and programs, it is important that there is a close relationship between the ITSMP responsible roles and the project office. Their processes need to be integrated with clear touch points and escalation procedures defined. The road-mapping teams should receive monthly reports on project deliverables, timelines and milestones in order to react in a timely fashion to any risks or problems. Technical integration of their respective tools is recommended.

Each pattern of activity in the IT strategy and master planning process involves a special skill set, level of seniority and organization. It’s strongly recommended to be as explicit as possible in describing those roles and assigning them to staff. Also formalize the processes and the touch points between ITSMP tasks and the rest of the organization. Stakeholders need transparency over the whole process—from creation of the top-level strategy down to the status of individual projects and its deliverables. They need to understand the stage of the process, the status of strategies, road maps and delivery, and their next task. Escalation procedures and review cycles are an important part of this definition.

A special need for close business interaction

A key challenge for IT planning and management is communication of its benefit and purpose to stakeholders outside of IT—the advantages of business alignment and IT effectiveness. The “enterprise” in enterprise architecture focuses on this—it is about the business, the enterprise in total, not just IT. This is widely understood on a theoretical level, but in real life IT is often seen as a “black box,” a sphere of its own and a cost factor with an unclear cost-benefit equation. Not being bothered by the business may have advantages in everyday activities, but is of course a very dangerous situation. If business—the ultimate sponsor of the IT—cannot recognize the value and benefit of IT, the willingness to sponsor anything beyond operational activities is very limited.

Involve the business in strategy deduction

The IT strategy should be derived from the business strategy, so a crucial point of engagement with the business is gaining an understanding of business strategy. If there is no explicit, documented strategy then take whatever is closest and structure it for a further iteration with business. The heads of the IT strategy must be in a close communication with their peers in business. Be sure you know:

• What are the current business drivers?
• What are the current aims of the board?
• Is the enterprise supposed to grow, enter new markets, and create new products, or is it in a consolidation situation?
• What is more important: flexibility or costs?

The outcome of this interaction must be made transparent to the IT, at best turned into a reference model, such as a business process or capability model. This enables the linkage of specific strategic outcomes (strategic business supports, major road-map programs and projects) to their strategic drivers. This gets especially important if plans need to be adjusted over time, i.e., to react on changing regulations or technology trends. If some of the milestones of your road map need adjustment, it is important to understand the overall goal that you try to achieve, and that is to support the strategic vision of the business.

Involve the business bottom-up

Involving the business should not stop with defining and agreeing on the cornerstones of an IT strategy. IT strategies and especially road-map definitions are not only a result out of top-down requirements but also from bottom-up demands. These are driven by changes like new legal regulations and also by everyday issues with the involved IT. Nowadays, large enterprises typically have issue and demand management processes to cover those topics and typically regard them as purely operational tasks. Although purely operational at first sight, they have nevertheless an impact on ITSMP. Each operational change automatically affects the foundation that the road map was built on. Each change must be documented and made visible to the planners to enable them to recognize changes in the architectural baseline. In addition to that, each change should also be cross-checked regarding its strategic compliance and alignment. It is quite pointless to agree on IT strategy cornerstones with the business if the implementation of operational business demands runs contrary to that strategy. Accordingly, it is crucial to implement approval stage gates in operational demand processes with the appropriate communication channels. If operational demands are denied due to a lack of strategic alignment, it is important to communicate the strategic reasons that are the rationale behind the decision.

Involve the business in setting up heat maps

Defining a suitable IT strategy for a large enterprise with its complex structures is a challenging task; the same is true for defining the road map. It is time- and resource-consuming. Therefore, it is meaningful to focus on areas of the business that need the most attention. Heat maps are very useful for spotting such areas and should be set up together with the business to support communication and decision-making. The communication can be in both directions; top-down, communicating business priorities to IT or bottom-up, communicating IT issues to business.

Top-down heat maps aim to communicate business issues by getting the business managers to assess processes for their organization. This assessment should be high level and simple—for example, rate the criticality or importance of a process. Assess if you will be executing this process in the mid-term. Another example could be assessing satisfaction with the current IT support for this process. These are simple assessments that give insight into business priorities and can expose issues such as processes no longer being required in the future. This is important input for planning.

Bottom-up heat maps show the current state of support by aggregating indicators on the IT health to the business support level. Common examples include cost, risk exposure, incident rate and technology health. These have the aim of highlighting areas that need attention based on the current state and support explaining the need for certain investments or cutbacks to business.

 

ITSMP has been defined as planning the application usage landscape as well as the route from the current landscape to the defined target. There are some prerequisites: agreed-upon conventions, definitions, and processes in order to gain and maintain the application inventory information. Indeed, proper definition of modeling conventions of the roles involved in the process (supporting processes and the ITSMP process itself) is a key issue for the success of ITSMP. It must be run as part of an integrated process. And it must be run as an enterprise process for the business and IT—not as a plain IT process in order to deliver IT benefits.

And what are the benefits of ITSMP? It is turning “organic” self-driven evolution of the application landscape into a controlled and planned one. And it is turning the IT consumer—the business—into the core stakeholder, driving how IT should be structured.

The scope of an IT strategy is defining the best-usage landscape, while leaving the business in the role to define what “best” means in each area. It is standardization, re-use and avoidance of redundancies to address efficiency and cost concerns. It is providing flexibility where the business needs it. It is tailor-fit IT instead of one-size-fits-all.

Master planning is the logical next step. It ensures that well-defined strategies do not rot in a drawer. It ensures planning and implementation follow business strategy and environmental circumstances. It is delivery without diversions. Master planning is setting up a road map and also monitoring it and checking that changes during delivery are quickly assessed for their impact and road maps aligned accordingly.

1. Depicting a business support as IT used to run a process within an organization is not the only possible method. For example, the business activities can be structured by capabilities instead of processes, or within very volatile organizations the focus on the provided market products is more suitable as an organization focus. Nevertheless the concept stays the same: Some parts of the business use specific IT to perform their tasks. For the reason of simplification, this paper focuses on organizations and processes as “parts of the business” and “tasks/ activities.”