Business Architecture as the top of Enterprise Architecture

 The Business Architecture is the most dominant architecture; all other architectures can be derived out of the business architecture and should be traceable back to the business architecture.

Although any model is an abstraction of some reality, the Business Architecture should be the most tangible representation of reality in business terms. It provides the business rules and requirements for building all other architectures. This architecture layer maintains the links back to the corporate strategy and keeps the whole enterprise focused; in this way it provides an excellent feedback mechanism for additional business improvements and opportunities for building a competitive advantage.

Business architecture defines the enterprise value chain (or process streams) and their relationships to all enterprise and external business entities. It is a definition of what the enterprise must produce and how it produces to satisfy its customers, compete in a market, deal with its suppliers, sustain operations and care for its employees.

This business architecture can be described in terms of three key models; these three models are often used interchangeably to describe a Business Architecture but are actually quite different. They provide different perspective on the business and sometimes are overlapping each other:

  • a Business Model describes how the enterprise business works; it is more focused on the external relationships and interaction between the company, partners and customers
  • a Business Operating Model describes the necessary level of business process integration and data standardization in the business and among all internal and components of the company; it is more focused on the internal relationships and interaction between the companies departments and how they cooperate together to operate the business
  • a Capability Model describes the capabilities required to implement the Business and Operating Model

The business model of a company is a simplified representation of its business logic meaning that it describes the rationale of how an organization creates, delivers, and captures value; It defines the manner by which the business enterprise delivers value to customers, attracts customers to pay for value, and converts those payments to profit.


Even if this term is used for a broad range of descriptions to represent core aspects of a business (including purpose, offering, market, customers,…) the essence of a business model is that it describes what a company offers its customers, how it reaches them and interacts with them, through which resources, activities and partners it achieves this and finally, how it earns money.

In the early history of business models it was very typical to define business model types, however, these types usually describe only one aspect of the business, most often only the revenue model. Therefore, more recent literature on business models concentrates on describing business model as a whole instead of one only elements. Inspired by the “Business Model Canvas” framework, a business model design should include the description of the following key elements:

  • “Target Customer Segments” element defines the different groups of people or organizations an enterprise aims to reach and serve
  • “Value Proposition” element describes the bundle of products and services that create value for a specific Customer Segment
  • “Distribution Channels” element describes how a company communicates with and reaches its Customer Segments to deliver a Value Proposition
  • “Customer Relationships” element describes the types of relationships a company establishes with specific Customer Segments value configurations
  • “Key Resources” element describes the most important assets required to make a business model work
  • “Key Activities” element describes the most important things a company must do to make its business model work
  • “Key Partners” element describes the network of suppliers and partners that make the business model work
  • “Revenue Stream” element represents the cash a company generates from each Customer Segment
  • “Cost Structure” element describes all costs incurred to operate a business model


All these elements of the Business Model should be mixed together in a value stream or value chain which describe the sequences of steps in the organization which allow to create the value and this part will be described in the Operating model.


An Operating Model describes how internally you want your business to run; it defines the major operational elements required to implement your business model; and how each of them is linked and further designed in terms of sub components. In this sense an Operating Model is usually informed and derived by the Business Model; however in some cases, an Operating Model can become the source of competitive advantage and can inform the Business Model.

An Operating Model breaks the company organization down into its logical components and describe how the organization does business, it illustrates the key areas of the organizational structure, the relationships among the operating units and trading partners and provides a set of guidelines for both the business architecture and technology infrastructure that enable a company to grow its business.

An operating model should answer at some operational questions about the company internally runs, such as “What is the organization structure?”, or “What processes does the organization use?” and “What are the roles and responsibilities?” trying to highlight main components and relationships of an Operating Model framework which are:

  • People components which include structure, organization, skills, knowledge culture, governance, rewards, sourcing and locations
  • Supporting Infrastructure and Facilities components which include physical assets, facilities and locations, information and data assets, technological infrastructures and application (that partially have been described in more detail in the IT Architecture)
  • Processes components include the overall process flows, inputs, outputs, accountability (who does what), where, how, what metrics and what levels of consistency

Capability modeling is a technique for the representation of the internal side of an organization’s business, independent of the organization’s structure, processes, people or domains; it describes the complete set of capabilities an organization requires to execute its business model or fulfill its mission.

A Capability is a particular ability or capacity that a company have to achieve a specific purpose or outcome. In this sense a capability abstracts and encapsulates the organization with the people and their roles, processes, procedures, and technology associated with a given business function into a simple block.

Capabilities in a Capability model are distinct from Processes in the Operating model; Capabilities are “WHAT” a business does to reach the desired outcomes, whereas processes describe “HOW” it is being done. The benefit is that a Capability model is much more stable over time and also much more static across businesses within the same sector, and thus a much more suitable business design components on which to pin the IT Architecture.

The key characteristics of a business capability, that distinguish the Capability Model from an Operating model, are the following:

  • Each capability is unique and reusable. It is a fundamental element of the organization and as such is clearly different from other capabilities. A capability might be applied throughout the organization and may be applied in different ways to affect different outcomes but it is still a single capability.
  • Capabilities are stable. Well-defined capabilities rarely change; they provide a much more stable view of organizations than do projects, processes, applications, or even strategies. Capabilities only change when there is a significant shift in the underlying business model or mission which might occur through a business transformation initiative or in conjunction with a merger or acquisition.
  • Capabilities are abstracted from the organizational model. Capability models are not just a simple restatement of the enterprise’s organizational model. They are organizationally neutral which means that changes in the organizational structure don’t require a change in the capability model. In simple organizations, the capability model may look similar to the corporate organizational structure because organizations are typically built around common skills, but more complex organizations have same capabilities that appear in multiple functional groups.
  • A business capability does not impose any constraints on how it has to be realized through IT systems or human actions.

Capability models are multilevel but the number of levels varies greatly from organization to organization depending on how the model is applied. Almost all have at least two levels with very few having more than five, containing a number of capabilities , at the lower level, ranging from 10-50.


Exhibit 19 – Business Capability model

At the high level (from level 1 and 2) the Capability model represent the 5-10 main generic capabilities of the organization, they are usually overlapping with the high-level process model or overlapping with the high-level product groups. Capabilities below level 3 of the hierarchy are primarily used to connect the model to processes and technologies.

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | Leave a comment

Enterprise Architectural model

Today IT is becoming more complex in every company and globalization requires handling bigger business context (such as joint-venture between companies, multiple lines of business, fast changing landscapes…); in this case a structured approach to dominate complexity, analyze nearly chaotic business and IT current landscape and take the right decisions is mandatory; Enterprise Architecture enable this kind of approach.

Enterprise Architecture (shortly named EA) is a holistic representation of all the components of the enterprise structure and its technology, which comprises enterprise reusable components, and the externally visible properties of those reusable technology components. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment. In addition, nowadays business developments, such as outsourcing, partnerships, alliances, and electronic data interchange, extend the need for architecture also across company boundaries. this means that EA is not limited to the internal organization, but includes customers, business partners, and external systems

EA contains many type of different information which can be grouped in three main contexts:

  • Business context: business model, organization structure and business process dealing with intra-organizational processes, inter-organizational cooperation and coordination
  • Information context: business information entities (e.g., customer and products) and how they correlate each other (e.g., customers’ orders and products) to support the business context
  • Technology context: applications, platforms, infrastructure, interfaces, software and all other IT-related assets which together run information systems supporting business context and managing information needs.
EA describes the terminology and composition of enterprise components, and their relationships with the external environment for the purpose of assessment, analysis, design of evolution of an enterprise. It is comprehensive, including not only software applications and systems but also business process, roles, organizational structures, and business information.

This EA approach can show big advantages at least in three following areas.

EA enable a common language to communicate and create a shared understanding across and throughout the enterprise, providing a very formal structure and a standard terminology for all business and technical components. For instance, the definition of the term ”sales” may have vastly different meanings for those who work in Selling and Finance.

Secondly EA show its full potential when you need to dominate complexity; this means that if you need to take decision for a specific application EA does not provide a real advantage but in more complex scenarios involving many application and application domains EA can play a relevant role and can provide concrete support for decision making. EA provide a way to understand enterprise complexity through decomposition and evolution of the enterprise away from organizational functions and towards a component based structure. This is achieved through the creation of a number of interconnected architectural views, with the various reference models breaking Enterprise Architecture down into manageable areas, and different levels of abstraction, usually including strategic, operational, and technical perspectives.

Finally it is also critical for communicating easily and effectively because technology and business departments must work together in order to remain in line with the strategic objectives of the company, but also because it is critical to sell IT strategic concepts to senior executives and business managers. This should be a continual practice of education, and the setting of both financial and business expectations to ensure that any concerns about loss of control, or other political considerations is addressed. Communication lines should remain open all the time to make certain that there are no surprises for the organization’s management.

As said before Enterprise Architecture is a model, meaning that it is a snapshot of how the technical and business works in a certain point in time which usually is set to the current one (AS IS situation) and the target one (expected TO BE situation in 2-3 years from now).

AS IS snapshot is used in a documentation fashion; defining exactly how it is that the current enterprise functions and interrelates each other. The AS IS provides current standards and definitions; these are helpful for interoperability, interchange of information, and integration of the business processes. In this way Enterprise Architecture provides the essential blueprints for the communication, interpretation, and implementation of value drivers throughout the organization. Indeed EA models enable the definition and documentation of the Enterprise, overcoming the main issue of poor communication by documenting the architecture to convey the descriptions to different stakeholders in the organization such as Business Management, CxO, CIO, PMOs, Governance team leaders, Chief Architect or Enterprise/Technical Architect.

TO BE is used as a target definition for a future state. In this role, EA application is a framework which can be used to assess new projects and investments providing insights into what projects should be done, by doing gap analysis between the AS IS and TO BE architectures.

As a first cut three types of architectures can be identified which are Business, IT Conceptual and Executive one; each realm requires a different level of involvement from the architects.

In the Business Architecture the IT Architect mainly serves as a translator from the business leadership to provide the direction and sets the boundaries needed to evolve the system landscape; in this case the word IT becomes “the Technologies of the Enterprise” and the first question becomes “What should the technologies of the enterprise do?”.

In the IT Conceptual Architecture the IT Architect acts as the creator; in this realm the word IT turns into “the Systems” or “the System Landscape”. The IT Conceptual Architecture is the fundamental communication vehicle for the architect towards all the stakeholders. Once the IT Conceptual Architecture has been completed, the architects can more effectively influence the outcome of system implementation and help in the prioritization of the technology projects presented.

Finally, in the IT Executive Architecture, the IT Architect play the role of mentor for the people (system designer, developer, …) implementing the changes to the enterprise; in this case the word IT become “the Project” or “the System”. IT Executive Architecture focuses on a specific application/system and primarily set the guidelines for implementation activities. It can be consider the most detailed of the architectural processes and has a domain or application specific focus.


Exhibit 14 – Enterprise Architecture Framework

In this layered view of architectures, the Capabilities are the components that constitute the glue that link the Business world (Business Model and Business Operating Model) with the IT world (IT Architectural model and the IT Operating Model). The capability view of the business provides an abstraction of the business assets and needs which provides the high-level foundation for alignment between Business and IT.

In the following paragraphs we will analyze in more detail the Strategic (or Business) and then Conceptual (or Functional, Information, Application and Technological) architectures. Due to its detailed focus on just only a single system, the Executive Architecture is not relevant for the IT Strategy definition, this is the reason why we will not cover this part in our book.

In next post we will briefly describe the Architecture Model components (Business, IT Concepual and IT Executive Architectures).

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | 1 Comment

MappIT Framework key concepts

In previous posts we have introduced MappIT methodology and related to this some terms, such as business strategy, operating model, enterprise architecture, which require a brief definition and some example to be clearly understood in practice.

The top section of the framework is the Business Architecture concept, a set of business components (processes, organization, people, channels, products, etc.) that are required to run your current corporate business.

Business Strategy define how to properly shape, change and mix these components together to reach the target company vision, mission, goals and objectives considering in the meanwhile the external and internal constraints (business drivers). This part of the framework is not the target of this book but is mainly the input of all other following parts.


To implement the business strategy, or in other terms reaching the desired business architecture, a set of Capabilities are required which represent the link between the business and IT world.

These capabilities are enabled first of all by the IT Architecture model, meaning all systems and technologies which are delivered by IT to the business in order to support the Business Architecture. This architectural model should serve as a starting point for IT strategic planning.

However a proper IT strategy should also envision other area of IT, such as staff and resources allocation, sourcing options and strategies, vendor management plans, organizational and skill management, etc. In other words this architectural model is transformed, operated and managed over the years through what is called the IT Operating Model which can be split into two main areas:

  • IT Operating Spending model which describes spending and investments allocated by IT department to manage the IT architecture and to run the IT activities
  • IT Operating Sourcing model which describes the organization structure of internal and external staff, roles and skills used to run assigned activities

The mix of target IT architecture, IT spending and IT sourcing capabilities and how they are delivered through IT Initiatives define your IT Strategy.


To complete our framework we have also included the IT Governance concept in order to position them respect to the IT strategy.

As a matter of facts once the IT strategy has been defined and communicate to all stakeholders, a second level of details will come in place to support and monitor the implementation of this IT strategy; this level is named IT governance.


In this sense IT strategy is mainly focused on defining, from an higher, concise and long term perspective how resources and assets should be used, while IT governance is more focused on:

  • detailed definition and specification of the spending/sourcing model (e.g. Supplier SLA Management, Supplier Consolidation…) and the organization model (detailed role profiles, skill definition, career path, incentives,…)
  • detailed IT Service model which defines the IT Services exposed to the business and their attributes (accounting and charge back models, SLA…)
  • detailed IT Process model and procedures linking together all above models and defining how the IT department run in order to manage and evolve the architectural model.

In next post we will briefly traverse the framework to describe some key definitions related to these key concepts; we will start from the static concepts (Architecture and Operating Models) and then moving to the dynamic ones (Business Strategy, IT Strategy and Governance).

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | Leave a comment

The Approach for properly using the IT Strategy Framework and Information Model

The framework seen before and the data model structure identify the key concepts and typical related entities and attributes which should be considered when an IT strategy should be developed.

The collection and usage of these information can be greatly simplified using, as a facilitator, a well-defined way of proceeding that has been formalize along years of experience in a proven approach composed by a clear set of phases, activities, deliverables, templates and techniques.

This approach is structured in five working phases; the first four (Assess, Envision, Design and Plan) allow to build an initial IT strategic plan baseline and the last one ensure a continuous improvement and agile re-planning due to changing context and results achieved.


Exhibit 8 – MappIT IT Strategy Approach

For each of these phases some main steps and their dependencies, output deliverables and areas of our framework and data model involved can be identified.

Main final deliverables of this approach are the following:

  • Current Business and IT Architecture and IT Operating Model: the business context description and related portfolios of applications, infrastructures, services and IT organization and resource to support this current business context
  • Business Strategy: it defines the company mission and company’s strategic intentions and, for each, goals, metrics, and weights
  • Business Capability model: it defines what the business expects to do with IT to meet its strategic intentions. The strategic IT agenda is used to drive strategic IT capabilities and requirements ; the content is business management’s strategic intentions for the use of IT, strategic objectives for the use of IT
  • Strategic IT Capabilities Model: this is a prioritized statement of capabilities and requirements that IT will deliver, over the life of the strategic plan, to satisfy the Business Capability model and the business strategic intentions
  • Strategic IT Blueprint both for IT Architecture and Operating Model
  • Strategic IT Plan. This plan is the outcome of strategic IT planning; it defines what the IT organization must do to meet the demands of the strategic IT agenda. It is used as the strategic framework for the IT budget and the projects needed to support the business projects. The content is the portfolio of potential strategic initiatives, on a 3 to 5 year horizon, to meet the business requirements defined above, prioritized according to business strategic intentions

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | Leave a comment

IT Strategy Information Model…data for the framework

Our Framework is based on a predefined and proven information model which includes all key information that should be collected, including entities, attributes and relationships.

It is a suggested guideline of all typical information that should be collected and analyzed during the analysis; it acts as an accelerator for further steps, even if it can be adapted to match other specific contexts.

This model can be used either for mapping current situation (AS IS way of working) and for future evolution (TO BE target model) and is composed by five main areas.


Exhibit 7 – MappIT IT Strategy Data Model

First area focuses on Business Operating Model which describes how the company is organized and operates; it includes the following main entities:

  • “Product Types”, “Customer Segments”, “Interaction Channels” which describe the company business model in terms of which product it sell, to which customer segments and through which channels
  • “Business Organization” composed by Business Departments organized in a hierarchical view
  • “Business Processes” which defines the sequence of manual and IT-supported activities required to perform a business task (e.g. Order Acquisition process and related steps, actors, systems involved) by the Business Organization
  • “Customer Journey” which describes the business lifecycle from customer perspective in terms of sequence of Customer Journey steps

Second area is related to the Business Strategy domain which describe the company vision and what the company want to achieve in the medium and long term; it include Business Architecture, Business Drivers, Objectives, and Capabilities. It includes the following main entities:

  • “Business Drivers” which are the company-wide vision and related guidelines on business evolution (e.g. Company Xyz wants to deliver low-cost Cloud Services)
  • “Business Objectives” which represents the specific target (sometimes including quantifiable KPOs) that each Business Unit defined, aligned with the Drivers (e.g. BU Abc wants to increase sales revenues of Cloud Product WY by 20% in 3 years)
  • “Capabilities” which defines the macro-functionalities delivered by IT Architecture which can support Business Process in reaching the business objectives (e.g. a product configurator to support pre-sale process for improving Sales revenues). Business Capabilities include also all other IT elements (not pertaining to the IT Architecture) that IT provides to the Business to deliver and maintain the IT Architecture (Supplier and Organization capabilities …). Each of these Capabilities is detailed in a set of Business Requirements.

Third area models the existing and future IT architecture which support the Business Operational Model in terms of IT principles and logical components (modules, data, interfaces) and physical ones (sites, server…); it includes the following main entities:

  • “IT Principles” which are the IT-wide guidelines and standards which drive the overall IT architecture and Operational Model (e.g. collapse all product information in a single Catalogue)
  • “IT Modules” which defines the application modules (e.g. Order Capturing application) that are used by business users and customer to perform some activities of the business processes and/or deliver the business capabilities/requirements; each of the IT Module provides this support through one or many IT Services.
  • “Interfaces” which defines which connection and data flows are available across the IT Modules in order to transfer data between them; these data are described in terms of key information, known as Data Entity (e.g. Customer Profile, Orders, Invoices…), relevant to handle one or more business process
  • “Infrastructure” which defines the infrastructural elements (e.g. front-end web server running the Order Capturing application, equipment…) required to run one or many IT Modules; these infrastructure elements are grouped together in Sites the physical location where the elements are hosted
  • “Issues” which describes the open problems and pains on each IT module (e.g. performance issues, technical issues, functional issues…)

Fourth area describes the IT Operational model required to run the business as usual in terms of maintenance and operations of running applications/infrastructure and follow IT Initiatives required to implement new modules/infrastructure; it includes the following entities:

  • “IT Organization” which is composed by IT Departments organized in a hierarchical view
  • “IT Activities” which describes the usual activities performed inside the IT department in order to run the current systems (e.g. Monitoring Order Mgmt. app) and proceed with planned initiatives (e.g. Functional Analysis for Project A). For each of these activities related Internal FTEs and external Budget allocation (and related Suppliers) are defined
  • “IT Persons” which are the IT department people required to run application and initiatives; they are linked to a specific Role and has a set of Skills

Finally the IT Strategist have to describe the running or future IT Initiatives (Projects or Programs) which aims to deliver new or modified Business Capabilities through changes or new IT Modules or Infrastructure (e.g. Order Improvement project); it includes the following entities:

  • “Impacts” which defines which IT and Business actions (and related effort) are required for the introduction of new capabilities (e.g. Review a GUI of an application or add a new interface) or a subset of their requirements. For each of the business Impact and estimation of costs is defined in order to estimate the overall effect of all impacts related to a common initiative
  • “Initiatives” which describes the project required to deliver new or improve existing capabilities in IT modules. These initiatives are described in terms of Impacts on IT and Business side (see later) and in terms project features like Phases, Risks, Key Decisions, Issues and Actions require to overcome Risks and Issues

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | Leave a comment

An IT Strategy Framework

MappIT framework identifies and positions all key concepts which can support the IT strategists in defining the IT Strategy.

These concepts include on one side Enterprise Business and IT Architecture, Spending and Sourcing Operating Model; on the other side Business Strategy, IT Strategy and finally the Capabilities and Initiatives.

For completeness reasons the framework include also IT governance concepts like Service Model and IT Processes and Procedures.

The framework identifies all concepts required to respond to four key questions, which are:

  • WHY? – What business and IT reasons drive our strategy?
  • WHAT? – What target capabilities the IT Strategist needs to implement in order to achieve the strategy compared to the current ones?
  • HOW? – How the IT Strategist needs to change our current IT architecture and IT operating model in order to support these capabilities?
  • WHEN? – What are the plans related to the implementation of these capabilities?

The framework can be split in two main domains which are the Business one (the upper side of the framework) and IT one (the lower side).


The status, at a certain point in time, is the Architecture or Operating Model, which describe how the domain (Business or IT) work in this point in time.


A “Model” (Architecture, Spending, Sourcing, Service, etc.) is a static concept providing a snapshot of Business or IT as a whole (or a portion of it) ad a certain time (typically an AS IS or current one and a TO BE or target one).

For each of the previous domains we can define dynamic elements (described as horizontal chevrons) which are the Strategy and Governance arrows which describe the needs and rational of the domain (Business or IT) to move from its current status to the target status.


A “Strategy” (Business and IT) is dynamic concepts, which describe the sequence of steps to move from the current model state to the target one.

The framework can be used as a whole to address all key dimensions of the overall IT domains and models, or can sliced vertically, moving across various models on a specific IT subdomain (e.g. Customer Management or Digital Channels) or in alternative it can be sliced horizontally, taking into consideration the evolution of a specific model (such as Architecture, Spending, Organization…) for all IT domains.


Depending on the navigation path you choose as more suitable for your needs, the framework allows proceeding in different types of analysis such as, for example:

  • Business Assessment: assess and track your current business context
  • Application Assessment: assess and track your current technical landscape (both application and infrastructure)
  • Infrastructure Assessment: assess and track your current technical landscape (both application and infrastructure)
  • IT Organization and Sourcing Analysis: map and analyze you IT organization and resource skills
  • Spending Analysis: reclassify and analyze your current IT expenses or future budget
  • Portfolio analysis: analyze the project or application estate using a portfolio approach similarly to the ones used for investment analysis
  • Business Alignment analysis: define and map your future vision, objectives and requirements
  • IT Architecture Design: evaluate different scenarios and design the target architecture
  • IT Operating Model Design: design the target IT organization, sourcing and skills

The emphasis on a type of analysis obviously is driven by the business scenarios that the IT strategist need to face, so for example:

  • in post-M&A Integration programs the IT strategist want to more deeply analyze your system landscape in order to drive a simplification, integration and rationalization process, so in this case Assessment analysis is the central one
  • in scoping big-size projects, such as an ERP Implementation, you are probably more interested in the business driver/objective and system functional/process capabilities aligned with those business needs, so in this case Business & Application assessment and Alignment Analysis are the most important
  • In restructuring or reorganization of an IT department you are probably more interested in spending and organizational aspects, so in this case Organization and Sourcing analysis is more relevant
  • In defining you annual budget or your IT system plan you are probably more focused on spending items, so in this case Spending and Portfolio Analysis are the main analysis to perform
  • In datacenter consolidation/virtualization you are probably interested in mapping your infrastructure assets so Infrastructure Assessment and Portfolio Analysis are the main analysis to perform.

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | Leave a comment

A methodology for IT Strategy

Broadly speaking, IT strategy can be defined as a mix of implicit and explicit guidelines and plans regarding the supply and demand of information within an organization and the alignment with the internal and external environment aimed at the realization of the visions and objectives of the company.

In the real world however many organizations operate without such a clear strategy and development of IT is rarely driven by strategic objectives, but rather it has grown-up in a piecemeal fashion due to many reasons. In most cases IT is used to create tactical solutions for specific business challenges leading to successive overlapping generations of technology. Big corporation and multinational companies’ carry-out planning, prioritization and resource allocation decisions in silos or stovepipes and the various IT strategy governance activities do not embrace an enterprise perspective nor do they coordinate across these barriers. Finally the whole governance processes (business planning, IT planning, prioritization, budgets, and performance measurement) are poorly connected each other; for example, a company may have strategies, but its management performance measurement is not consistent with those strategies or similarly, business and IT planning may not be coordinated.

The final result is that IT management focus on immediate problems as they arise; but without a plan, an understanding of where their organization wants to be, and how the planned direction is to be achieved; the more likely it is that tactical solutions and related problems will occur. The absence of an IT Strategy means that investment decisions have to be made on their own merits and usually in relation to just one part of the organization. Inconsistency leads to inefficiency and frustration and IT becomes an obstacle to achieving the aims of the organization rather than one of the most powerful resources at its disposal.

Despite this typical scenario there is a general understanding that if IT is required to deliver value, then it must be subject to a set of management disciplines that are called IT Strategy which should enables an organization to make appropriate, cost-effective decisions about enabling technologies for business purpose.

However having clear in mind the need to define an IT Strategy is just only the starting point; after this awareness has been achieved the IT Strategist needs to check if the IT Organization is able to define and then execute this IT Strategy. To better understand where your IT department position respect to these abilities a simple matrix can be introduced to help IT functions analyze where they are located prior to defining their strategic approach; this matrix shows both the importance of defining the IT strategy (understanding business objectives and defining a target architecture and IT resources allocation) and its implementation (plan and team performance for programs execution).

Based on this matrix IT departments can be classified in four major categories:

‘Beginner': this represents nearly half of organizations whose IT strategy is either poorly defined or not defined at all, or where, even if it were, the IT function would be poorly placed to execute against that strategy.

‘Visionary': this represents IT organization whose IT strategy is more or less in place, but the IT department is unable to execute it and to keep it up to date

‘Challenger': here the IT Department is well placed to execute against any given strategy; the problem is that it does not have one, or the one it have is inadequate.

‘Master': that minority of IT Department (let’s consider optimistically less than 10% of all) that not only have a strategy, but are also capable of delivering against it and update it continuously.

This categorization clearly show that IT strategy practice is rarely applied inside companies, mainly because the approach is not so clear, the steps to follow are not straightforward and is not so simple to apply them on the everyday IT lifecycle.

Four key principles must be considered when defining an IT strategy methodology: it must be business aligned, comprehensive, actionable and agile.

First principle states that all IT strategies must run throughout the entire lifecycle, managing both business and IT elements, and facilitating the alignment of these two perspectives towards a common set of objectives. An effective approach is therefore essential to ensure that the delivery of IT services meets the requirements of the business, policies and procedures must be in place to guide investment decisions. In delivering this business and IT strategy an organization must define a unique value proposition, or a set of benefits, different from what their competitors offer. Robust strategies involve also trade-offs meaning that a company should abandon some product features, services, or activities in order to be unique compared to others. Such trade-offs, in the product and the value chain, are what make a company truly distinctive.

A good example for explaining this concept is the “Henderson & Venkatraman” framework which is a great Business-IT strategic alignment tool that is quite comprehensive and very business oriented.

Exhibit 2 – Henderson & Venkatraman framework

This framework provide separate perspectives to reach Business vs. IT alignment, which are “Strategy execution”, “Technology transformation”, “Competitive potential” and “Service level” alignment perspectives.

Second principle highlights that in defining an IT strategy the effort should not be focused only on the development of an application architecture as main outcome; in other words, the completion of the IT strategy discussion is not only an inventory of systems that are needed to support overall corporate strategies. It is just one component of the larger set of IT strategy outcomes; IT Strategy is a matter of planning not only the IT architecture (including applications, infrastructures, etc.) but also other IT assets and resources (staff, suppliers, etc.) for reaching both effectiveness (meaning doing the right thing) and efficiency (meaning doing things right).

Third principle underline that an IT strategy framework need also to be really actionable; considering again the “Henderson & Venkatraman” framework, even if it is a great visionaries framework it lacks of ability to be immediately applicable for real-life needs. It provides only an high level description on how to proceed with the IT strategy definition, but do not provide a detailed framework to use and a step-by-step description of the approach to adopt; while typically who approach for the first time an IT Strategy definition a set of instruction, examples and template should be provided. In other word it should have a lightweight footprint (being easy to use, low expensive,…) on the running IT Organization, providing prebuilt patterns and practices ready to use even for small and medium IT organization.

Finally the traditional way of approaching IT Strategy is still quite static; the IT organization envisions an “end state” for IT three-five year and creates a roadmap for getting there. Then the team responsible for executing the roadmap seemingly disappears into a labyrinth of initiatives, emerging years later into a business and technology environment that’s very different from the one they left. Those days, when IT strategies could be rigid multi-year plans, now have gone definitively. A company’s goals remain reasonably steady over a two to four year period but the IT strategies employed to accomplish those goals need to be continuously adjusted. In fact many times the IT Strategist experienced the typical situation of an IT department challenged by its inability to adequately support business initiatives and their prior strategic plans or defining them and then see how rapidly they became obsolete and not applicable. Shortly, in designing and building a IT strategic plan a combination of speed and agility is required; speed is necessary to respond effectively to high change environments while agility makes adjustments possible and increases the chances of plan success.

To support IT strategists in their complicated journey we have factorized all previous principles and past experiences in a proven and lightweight IT strategy methodology that can be helpful for all CIOs and IT leadership teams. This methodology is composed by a framework, a data model, an approach and finally an optional companion software.

Read more on this topic from my eBook…or stay tuned for new posts.

Posted in IT Strategy | Leave a comment