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.

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.

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.

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.

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.

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.

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.

IT Strategy Made Easy: a framework is urgently needed!!

What are the key challenges that nowadays every CIO or IT leadership team face for succeeding in their own organization into their organization in order to bring value and effectively support the corporate strategy and needs?

Challenge #1: Business Strategy is fast changing and IT must understand what the Business Strategy is and how to support it in timely fashion.

A number of key business drivers have shifted the emphasis in business terms and therefore in the way that IT must respond, such as:

• mergers and acquisitions which require a growing challenge of integrating disparate businesses
• e-business which has introduce new ways of working
• outsourcing and the new complexities and issues that this brings forward
• users that are becoming increasingly informed, demanding and selective
• parties involved which have been extended from internal users to external partners and suppliers
• deregulation of the new economies

However, even if business is the key driver for IT; it is astonishing to notice how many IT department employees do not know what their company business strategy is, beyond few high level statements. They have no idea of context they move in and no sense of how the strategy has been shaped by the competitive landscape.

This is very similar to what Richard Feynman faces when took over leadership of a team of mathematicians working on critical research for “the bomb”. He founds that the team, due strict to confidentiality policies, had no knowledge of what it was working on as a whole; each member of the team was given a problem, and each took some three months to solve it. Feynman insisted he get permission to tell his team what it was working on and after the team members were aware of this, their productivity increased to three problems a month!

Knowing the context provides motivation as well as a mechanism to make more informed choices. This business context and directions must be understood quickly, indeed the great challenge for IT managers today is to move around in the globalized world of the economy in which the rules and dynamics are in perpetual and quick evolution.

Challenge #2: Information technology is becoming more and more a source of competitive advantage and an enabler for innovation and new business models.

As Nicholas Carr states in his famous article “IT Doesn’t Matter”, what makes a resource truly strategic (meaning to be the basis for a sustained competitive advantage) is not ubiquity but scarcity; you only gain an edge over rivals by doing something that they can’t do. The core functions of IT (data storage, data processing, and data transport) have become available and affordable to all; they have begun to transform them from potentially strategic resources into commodities; they are becoming costs of doing business that must be paid by all but provide distinction to none. This means that while the world becomes more digitally transformed and connected, companies need to reduce the percentage of budget spent on keeping the lights-on and shift spending to the top business priorities; it’s no longer sufficient to simply keep the company up and running.

In order to remain relevant in this new environment, organizations must be able to implement the latest technologies quickly, and ensure that what they implement is engineered to work with the entire technology stack.

Consequently IT Departments need to evolve from an organization structure which supports the business units in automating their processes and channels into an innovation task force which can propose systems and technologies which should enable new business models or products/services. Although CIOs were traditionally hired to focus on operations and cost reduction, the need for an organization to drive innovation has created a critical new role for CIOs which is more focused on innovation and growth. CIOs are uniquely positioned to develop and drive innovation, influence cultural change, and deliver the innovation strategy.

In a nutshell the role of the CIO must evolve from being the Chief Information Officer to being the Chief Innovation Officer. In doing this IT Strategy play a key role in properly planning the systems evolution in order to keep into consideration emerging trends and technologies and also manage strategic principles (like flexibility, manageability….) which ensure for unplanned model to be accommodated in the future.

Reducing IT complexity to free-up time and budget for proposing innovation is only part of the solution; indeed many IT organizations have been culturally attuned to resist to new ideas rather than to embrace innovation. True innovation requires the opposite mind-set and a cultural step-change which is able to shape a new organizational and operation model.

Challenge #3: Compared to other company organization departments, IT department has more challenges because it have to interface with each of those different business functions providing solution which harmonize different, and sometimes competing objectives and needs

Let us consider a business comprising of a number of distinct organization units: Product Development, Manufacturing & Logistics, Sales & Marketing, Customer Services, Finance, Human Resources, and Information Technology. Of these, the first four have business-specific goals as their objectives and so different needs which usually require different or contradicting solutions. The remaining three departments offer services to the business as a whole, however although every other function is dependent on them, the Finance and HR services are consistent across the organization and they can therefore organize themselves to best suit delivery of that services.

IT department faces the most difficult challenge because it have to manage heterogeneous needs and expectations, but also harmonize them in a common and effective picture (which is the IT architecture) guaranteeing synergies, reuse and cost optimization while satisfying different business unit objectives. While it might be relatively straightforward to articulate elements of vision in each of these business units the issue of cross-alignment complicates the picture for IT. In fact each of these departments not only works in their own particular way (process and governance) but also has some systems requirements which should uniquely organized to best meet their local challenges.

Challenge #4: As the internal and external business environment evolves a certain amount of shift is experienced in the system landscape that must be managed by IT department in order to avoid building an unmanageable architecture and wasting of resources.

Obviously continuous and fast pacing support to business evolution, research for innovation and business units contradictions and competition imply building an IT architecture where the intentional or unintentional duplication of functions and information across multiple systems occurs. Apart functional overlapping and waste of resources this situation can lead also to a lack of information timeliness, data inconsistencies, and possible data corruptions.

There are a number of reasons why this shift can occur:

• legacy applications are replaced by package solutions whose function overlaps existing systems
• niches of the whole organization (for instance international offices) may have alternate methods of operation (due to internal or external political forces or judicial or geographic reasons)
• determining and strictly apply how function and information should be split between systems can be difficult in the real world
• the greater the degree of technological difference the more likely that duplication will occur

The shift not only reflects in the technical architecture landscape but also in the correct usage of IT resources to follow these changes. As multiple IT projects compete for limited resources, whether financial, human, or physical, a lack of visibility into the status of both projects and resources can result in delays and poor overall utilization. This situation is frequently exacerbated when resource conflicts involve multiple departments, or when there are cross-project dependencies in complex business programs.

Challenge #5: The role of IT Organization is changing from being a Provider of ICT solutions to be a Broker and Orchestrator between the customer and Cloud services.

On top of the previous “traditional” challenge, an additional one is emerging in the latest years which is changing the way how IT departments works and this reflect not only on IT architecture but also on the delivery paradigms and operating model. Outsourcing, SOA and Cloud Computing together are enabling the proliferation of services which can be produced and consumed everywhere. Successfully using such services created by others and ensuring that they work in real life (meaning that they work not only separately, but also integrated together) are complicated tasks which require IT departments to manage data integration issues, integrity problems and the need for strong relationship management external parties. Service Oriented Architecture has modified IT architecture and governance approaches and now Cloud Computing is changing consolidated patterns of sourcing and in general the role of IT in the organization. This trend will continue also in the future when IT organizations will transform their role from being a “Service Provider” to be a “Broker and Orchestrator” between the service consumers (internal end-users or customers) and service providers (outsourcers, cloud-based vendors,….), adding value to services and delivering new services built and delivered on top of other ones.

Even if the previous list of IT challenges is not exhaustive; they highlight some basic points that has driven me in structuring a consistent methodology with the aim of transforming the perception of IT strategy from a luxury (or worst a waste of time and resources) to a common practice useful to face these challenges either in big but even in small and medium enterprises.

Indeed today defining an IT strategy seems to be a complicated and unrepeatable effort, leaving the final result of this “strategic thinking” to the expertise of the professionals without a straightforward and structured approach, tools and techniques that can be easily and recurrently applied to the changing context.

On the other side many frameworks, approaches and models have been proposed so far by many companies, organizations and associations, in many cases they resemble each other and in many cases they are too generic, they do not provide enough operational details on how to proceed and they lack tangible tools and techniques.

For this purpose we need to address some key principles:

• to make IT strategy concrete, taking the best from existing frameworks (like TOGAF, Zachman,..) and translate them in terms of actionable tools, techniques, templates approach and methodologies
• to make IT strategy agile, in order to consider this as a really useful effort for iterative planning and fine tuning, avoiding wasting of plenty of initial assessment and analysis without any later follow-up
• to make IT strategy comprehensive defining an overall framework which include not just only IT architecture but also IT spending and sourcing as an integral part of plans and investment that a CIO has to look at, in particular in these days were external providers (such outsourcers and cloud service providers) are becoming more and more important
• to make IT strategy affordable also for small and midsize IT organizations, providing a lightweight and incremental framework and approach
• to transform IT strategy as an engine of proactive proposal of innovation from IT department to the business departments

In a nutshell we want to make IT Strategy an easy practice.

This methodology is composed by four main components:

• a Framework which define how the different concepts correlate each other
• a Data Model which identify key information to collect and their relationships
• an Approach which will guide through all steps and tips required to perform analysis and support decisions
• an optional Companion Software Tool (that you can download from our website https://frankitecture.wordpress.com) that factorize all this best practices and can be used as a supportive tool for building your own IT strategy

Using these four components you will be able to autonomously develop an executable IT strategy which allows to articulate business strategy defining context specific and measurable objectives, define a clear target IT architecture and IT Operating model, plan actions and initiatives with clear due dates and adjust them continuously to environmental changes.

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

TUTORIAL: How to use the other tools in MappIT

There are some other tools available in MappIT.

The first tool is the “Export Dataset” on the “Tools” tab:

In this case MappIT will ask for the specific Data Set you want to export and then generate a grid view containing the extracted data.

You can the copy and paste this data in Excel

The second tool is the “Display Model” on the “Tools” tab:

This will generate a report of all entities contained in your MappIT model.

From here you can then export it in PDF format.

The third tool is the “Delete Data Set” on the “Tools” tab:

From here you can select which Data Set you want to delete and then MappIT will clean up all the data contained in this dataset.

TUTORIAL: How to export a skill map survey template and import skill survey results in MappIT

In this section I would like to explain how to effectively run a skill survey in order to quickly collect skill level of all people in your IT organization. This information are quite interesting for many purposes:

• You can perform a skill assessment and analyse your current skill health
• You can later perform a skill gap analysis (meaning that you can verify what is the skill discrepancies between your IT Organization current skill sets and the required one in order to run the proper Operating Model

   

1. First of all you have to check the default MappIT definition of skill map (the list of skill categories and items) and in case adapt to you specific needs and context. For doing this you have to select the Skill item under the Governance section of the menu tree:

1. A grid view Tab named “Skills” will appear, from here you can add or delete skill from the skill map or update some existing skill.

    

 

1. For each skill you can define different attributes:
   1. Name
   2. Description
   3. Type of skill (the category to which the skill belong, for grouping reasons)
   4. Relative weight (it is used to weight in different way the skills when you evaluate the skill gap index during gap analysis)
   5. Notes

   You can also specialized some generic skills (like for example Functional Analysis) for specific Business Process Areas of for Specific Application Domains

2. When you have finished you can start the Skill survey. The first step is to export a skill survey template. Got to Tools and clock on “Export Template”

1. Then you have to select a folder where the Excel template will be created:

1. Clicking OK on the form MappIT will generate a single XLS template file; you can customize this template based on your needs (for example changing colors, formatting the header, locking some cells…). When your template has been revised and you are ready to continue you can click ” ” on the following Msgbox.

    

 

1. At this point, based on your template MappIT will generate in your folder a set of Excel file containing the skill map for each member of you organization.

    

 

NOTE: The name of the file contains the ID and the Name/Surname of your employee. The name of the file, the name of the contained sheet and the columns/row structure and names of the sheet should be kept unchanged otherwise during next Skill import MappIT will not be able to import the skill map.

 

 

1. Now you can distribute the excel template to each person and ask for a self assessment. For this purpose each person must score their skill using the columns “Person_Score”.

 

1. When all self assessment (or some of them, it is not required to do all at the same time) are completed you can start the import, going to the “Import Results” of the “Tools” tab:

    

 

1. Then you have to select the folder where your excel results are stored:

 

1. Clicking “OK” the import will be performed and the skill will be updated accordingly.

    

2. Now you can go to see the skills set of your IT Organization selecting the “IT Organization” area in the Home:

    

 

1. From here you can see the association of skills to the different persones and their related score clickin on the “Skills to Persons coverage map” tab:

    

 

1. A matrix will be displayed containing the persons score for each skill of the different persons in your organization:

 

You can perform again the Import operation when new excel file will be ready.