Developing an IT Strategy: Aligning IT Capabilities with Business Requirements

By Serge Thorn, Enterprise Architecture Consultant

I have observed many situations where a C-level person was supposed to document an IT Strategy in a short period of time, in order to prepare the following year’s annual budget. Very often, they lack much supporting documented business information in order to achieve this task. The result is a weak strategy, sometimes ignored by the user’s community, the key stakeholders.

A weak IT strategy can be costly and wasteful, especially for resource-constrained organizations that operate with minimal budget, tools, knowledge and people.  It also implies that organizations cannot respond to changing business requirements rapidly enough. The absence of strategic anticipation causes organizations to be inefficiently reactive, forcing them to work in a constant state of catch-up.

An IT Strategy should answer the following questions:

  • Are we doing the right things with technology to address the organization’s most important business priorities and continuously deliver value to the clients?
  • Are we making the right technology investments?
  • Do we measure what is the real value to the organization derived from that technology?
  • Is our current Information Technology agile enough and flexible to continuously support a successful organization?
  • Is our Information Technology environment properly managed, maintained, secured, able to support the clients, and is it cost effective?
  • Can our strategy support current and future business needs?

Quite often the first thing we should consider when writing such a document is the targeted audience and its content. Different people with varying roles and responsibilites may read an IT Strategy within a company, so the document may need to serve several different purposes.  It is not easy to pitch a strategy to different levels in the hierarchy within an organization, and at the appropriate level of detail. Sometimes it is too detailed and does not always match the stakeholder’s needs.

An IT Strategy is an iterative process to align IT capabilities with the business strategy and requirements:

  • IT Strategy is a documented and approved process (part of the organization’s governance framework)
  • IT Strategy is iterative (it needs to be frequently be revisited). Traditionally, IT strategies are updated and communicated on an annual basis, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business as soon as possible. A one-year cycle may  be too late.
  • IT Strategy is a strong alignment of business and IT capabilities rather than designing IT solutions to support business requirements
    • Assuming  that both business and IT capabilities drive each other
    • Assuming that business drives IT and not the other way around
  • IT Strategy sets future direction for IT function in the organization
    • Ensuring that the IT budget is spent on value creation activities for the business
    • Creating shareholder value
    • Helping to maximize the return on IT investments
  • IT Strategy may include sub-elements such as:
    • Infrastructure strategy
    • Application strategy
    • Integration strategy
    • Service strategy
    • Sourcing strategy
    • Innovation strategy

This pyramid diagram can be used to illustrate the IT strategy and vision, and how the technology and business strategies are totally aligned. At the top of the pyramid is the enterprise overarching vision. Aligned below is how IT supports the vision by becoming a premier IT organization in creating competitive advantage for the clients. The IT vision is in turn supported by three pillars: integration, improvement, and innovation.

IT strategy and vision - how the technology and business strategies are totally aligned
IT strategy and vision – how the technology and business strategies are totally aligned

To deliver this, the business strategy should clearly be articulated and documented taking into account some IT aspects. There are different ways of gathering these business inputs.

The first approach is a very classical one where you develop a questionnaire in business terms which asks each business unit to identify their future requirements for infrastructure growth, taking into account capacity and availability requirements. This extracts the data you need for business driven strategy.

This questionnaire may include some of the following examples of questions:

  1. What are your top 5 business “pain” points? These are things that you wish you had a solution for
  2. What are your top 5 business objectives? These can be short term or long term, can be driven by revenue, cost, time, time to market, competitive advantage, risk or various other reasons
  3. How do you plan to achieve these objectives?
  4. What will we gain by leveraging IT Capabilities across the business?
  5. What is in the way of achieving your business imperatives?
  6. Can IT help achieve your business imperatives?
  7. How much do you spend on IT capabilities?
  8. What is your technology ROI?
  9. Does your company have a plan for technology?
  10. Does your business plan include a technology plan?
  11. Where is IT being used across your business unit?

With this input you may now start to consider the structure of your document. It may look similar to this example below:

An Executive Summary includes:

  • Introduction
    • Purpose
    • Background
    • Business drivers
    • Organizational drivers
    • IT drivers
  • Business and IT aspects
    • Business Goals and Objectives
    • IT approaches and principles
  • IT components
    • Business application systems
    • IT infrastructure
    • Security and IT Service continuity
  • Structure, organization and management
    • IT Governance
    • Skills, knowledge and education
    • IT Financial management
    • KPIs, measurement and metrics, balance scorecards
  • Technology opportunities
  • Key issues

The second approach is where Enterprise Architecture will play an important and even crucial role. Some companies I have encountered have an Enterprise Architecture team, and in parallel, somebody called an IT Strategist. Frequently the connection is non-existent or quite weak.  Other organizations may also have a Strategic Planning unit, again without any connection with the Enterprise Architecture team.

An Enterprise Architecture must play the important role of assessing existing IT assets, architecture standards and the desired business strategy to create a unified enterprise-wide environment – where the core hardware and software systems are standardized and integrated across the entire organization’s business processes, to greatly enhance competitive advantage and innovation. The IT Strategy details the technologies, application and the data foundation needed to deliver the goals of the corporate strategy, while Enterprise Architecture is the bridge between strategy and execution by providing the organizing logic to ensure the integration and standardization of key processes that drive greater agility, higher profitability, faster time to market, lower IT costs, improved access to shared customer data and lower risk of mission-critical systems failures.

As a real example, TOGAF® 9 is perfect way to produce the IT Strategy document during the Phase F: Migration Planning.

In table below, you will find the relationship between some phases of the TOGAF® Architecture Development Method (ADM) and the structure of the Executive Summary document (see above).  A strategic architecture level should be used to deliver a first version of the document, which then could be reviewed with Segment or Capability architectures.

Relationship between some phases of the TOGAF® Architecture Development Method (ADM) and the structure of the Executive Summary document.

Content Examples Enterprise Architecture and TOGAF® ADM
Executive summary
Introduction (this document must be business oriented)
Content Examples Enterprise Architecture and TOGAF
Purpose Key elements of the scope, audience, time horizon Preliminary phase is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done and will provide all information. It also creates the conditions and context for an Architecture Capability
Background Phase A: Architecture Vision. An Architecture Vision sets stage for each iteration of ADM cycle.

-Provides high-level, aspirational view of target the sponsor uses to describe how business goals are met and stakeholder concerns are addressed
-Provides an executive summary version of full Architecture
-Drives consensus on desired outcomeThe Business Scenarios is used to discover and document business requirements, identify constraints, etc.

Business drivers Market conditions, competition, consumer trends, new customers, products sales, costs savings, incremental services revenues, drivers related to the IT function Phase A: Architecture Vision:

-Identify business goals and strategic drivers-Ensure that descriptions used are current

-Clarify any areas of ambiguityDefine constraints-Enterprise-wide constraints

-Architecture project-specific constraints

Organizational drivers Profitability, financial performance, change in strategic objectives, end of the product development life cycle, mergers and acquisitions, staffs, risks
IT drivers New or obsolete technologies, updates Considering that IT is part of the Business, these drivers should also be considered in that phase
Business and IT aspects
Business Goals and Objectives Market growth, entering new markets, addressing manufacturing capacities Phase A: Architecture Vision:

-Identify business goals and strategic drivers
-Ensure that descriptions used are current
-Clarify any areas of ambiguity
-Define constraints
-Enterprise-wide constraints
-Architecture project-specific constraints

IT approaches and principles IT standards, development, implementation, delivery, testing, consolidation, maturity, best practices Standards should be documented in the SIB (Standard Information Base)

When Architecture Governance Framework is defined during the Preliminary Phase, we identify the various touch points with other existing frameworks in the organization.
IT principles should have already have been defined by the IT department

IT components
Business application systems Baseline (main applications: ERP, CRM, customers facing systems). Future plans, concerns, time period, priorities) Phase C: Information Systems based on the Statement of Architecture Work, output from the Phase A
IT infrastructure Baseline (servers, network , middleware, technical services) Phase D: Technology Architecture based on the Statement of Architecture Work, output from the Phase A
Security and IT Service continuity Issues, challenges, opportunities related to security, security principles, controls Security concerns are addressed during all phases of the ADM
Structure, organization and management
IT Governance Best practices, frameworks, management and monitoring, resource management, portfolio management, vendors management, IT service management, project management, etc. IT Governance will be considered when the Architecture Governance Framework is defined. There will obviously be touch points between the ADM and some other best practices used by the organization.

IT Governance is defined outside the Enterprise Architecture program

Skills, knowledge and education Skills, knowledge and education Enterprise Architecture skills will have to be addressed by the Architecture Capability Framework. Other skills may also be identified independently of the Enterprise Architecture program
IT Financial management IT budget, costs structures, measurement and metrics, targets, areas needing investments, etc. Finance is addressed outside the Enterprise Architecture program
KPIs, measurement and metrics, balance scorecards IT performance measurements on SMART objectives (Specific, Measurable, Achievable, Realistic, & Time bound) Every governance frameworks may have its own KPIs. Enterprise Architecture KPIs may be added to that list.
Technology opportunities Emerging technologies, business related benefits This can be done in parallel with the Enterprise Architecture program
Key issues and initiatives Summary or link to the IT Project portfolio This can be done in parallel with the Enterprise Architecture program
Color legend
Direct relationship with Enterprise Architecture
Indirect relationship with Enterprise Architecture
Produced somewhere else

The next step would be the review of the IT Strategy document by the main stakeholders who would accept or reject technology opportunities. This could also be used as an important source of information for the Strategic Planning exercise (please refer to another article for additional information:  “How Strategic Planning relates to Enterprise Architecture?“).

Once the IT Strategy has been reviewed, amended and authorized (which should in reality already be approved, as it is the result of various ADM cycles and the output of Phase F: Migration planning), the multi-disciplinary program team for the implementation during Phase G: Implementation Governance, will deliver the solutions to the business.

As already mentioned previously, the outline strategies will be refined and expanded with a low level of detail when addressing Segment and Capability architectures. This is the part that meets the first challenge described above, where we need different levels of detail for different stakeholders. The documents should be hierarchical, with the ability to drill down to lower levels as more detail is required.

One of the main reasons for developing an Enterprise Architecture with TOGAF® 9 is to support the business by providing the fundamental technology and process structure for an IT Strategy.  Enterprise Architecture is the superset that represents both Business and IT Strategy; this is reflected in Enterprise Architecture’s basic structure of strategy, business architecture and technology/information architecture. One can certainly do an IT Strategy without Enterprise Architecture, but Enterprise Architecture cannot be done without an IT Strategy; the same would apply to business strategy/business architecture.

Serge Thorn,  Enterprise Architecture consultant  

Serge Thorn is an experienced and passionate Enterprise Architecture/Business Transformation professional, consultant, and trainer with many years’ of experience using the TOGAF® ADM and ArchiMate®, an open modeling language for EA.

Serge does coaching, mentoring and implementing worldwide in major Business and Technology transformation initiatives at blue chip companies. Serge has been involved in several Business Transformation/Change Management and Digitalization programs managing stakeholders and architecture teams

Serge has been in charge of International Governance and Control implementing different best practices around IT Finance/Procurement, Audit/Risk management, Vendors Management (with Service Level Management) in a Bank.

In a Pharmaceutical (Chemical) company, Serge was in charge of the worldwide Enterprise Architecture program and Governance, the IT Research & Innovation, following the reorganization of the IT Department, implementing Service Management based on ITIL Best Practices and deploying new processes: Change, Configuration, Release, and Capacity/Availability Management, responsible for the Disaster Recovery Plan and for the System Management team.

Several times responsible for the Enterprise Architecture team in an international bank, Serge has wide experience in the deployment and management of information systems in Private Banking and Wealth Management environments, and also in the IT architectures domains, Internet, dealing rooms, inter-banking networks, Middle and Back-office. Serge has also been into ERP and CRM domains.

Serge’s competency covers the understanding of banking activities, and industries such as Pharma/Biotech, the design of new systems, IT Strategies, IT Governance, Innovation, new technologies, Enterprise Architecture (including Business Architecture, BPM, Business Process Analysis, Six Sigma-Lean, TOGAF® 9.1, ArchiMate®), Cloud, Digitization, Strategic Planning, Service Management (ITIL V 3), Quality Management, team management, project and portfolio management (PMI/SDLC), IT Finance, organization.

3 comments

  1. Strategy must address the IT Trinity – People, Process Technology. You focused almost entirely on technology (right technology, right way, right return) with no regard for the services and people. Human capital management and strategic workforce planning are absolute essentials for IT strategic planning as are service strategies.

Comments are closed.