IT Governance Blog

CobiT definition:

Establish a classification scheme that applies throughout the enterprise, based on the criticality and sensitivity (e.g., public,
confidential, top secret) of enterprise data. This scheme should include details about data ownership; definition of appropriate
security levels and protection controls; and a brief description of data retention and destruction requirements, criticality and
sensitivity. It should be used as the basis for applying controls such as access controls, archiving or encryption.

Bill says,

What I really like about CobiT is it forces you to look at things in a comprehensive way. For data classification you really need to analyze every bit of data you collect, categorize it, and decide who will have access, how you will control it, etc - but those are future controls. For this one it is all about defining the classification of data.

Let’s look at some non-traditional data that really does need to be captured in your classification scheme. For example, you probably use WebEx for data conferencing. And I am sure you realize that there is a lot of data archives pertaining to the meetings held through WebEx - many of which can have very telling titles.

As an aside, if you are using WebEx make sure you do not have your site open to the public - or you have strict rules and controls in place regarding what people can use as the subject line in meetings. Prior to us turning this off I saw some pretty awkward meeting titles that were open for all to see - employees, customers and competitors.

So you probably have never thought about that data but you need to. What parts are important? I know for me we record the monthly usage locally because after three months we lose access to it through WebEx. Who has access to that? How can we be sure we know who is responsible for archiving it? These are all important questions that you need to go through as part of the classification exercise.

Don’t be scared off by how much data you have, this is work that needs to be done!

The third step in Defining the Information Architecture is defining the data classification sceme.

CobiT definition:

Maintain an enterprise data dictionary that incorporates the organisation’s data syntax rules. This dictionary should enable the
sharing of data elements amongst applications and systems, promote a common understanding of data amongst IT and business
users, and prevent incompatible data elements from being created.

Bill says,

Establishing and maintaining a data dictionary for a complex application is difficult but not impossible, particulary if the application and the underlying data structure and processes don’t change much. But when you start defining an overall data dictionary for your enterprise it becomes a much more difficult challenge. When building a data dictionary, however, don’t feel as though it needs to be perfect - better than to have a mess documented than not at all.

In today’s corporate IT applications space integration between applications is critical. The ability to integrate between applications effectively is contingent on a good enterprise data dictionary. If you have not done this then you are not doing the corporate governance that you should be doing.

An important component of this is to understand what the data means and ensuring that both the business and IT are in alignment. For example, we have a phone system that records ACD transaction and one of the pieces of data that comes out of this application is abandoned calls. What does that mean to you? Does it mean something different to sales? In our case IT thought they knew what abandoned calls meant and sales thought it meant something else. When in fact the vendor defined it to mean even something else! SLAs had been established around this key piece of data and nobody in the business truly understand what it actually meant.

The second step in Defining the Information Architecture is establishing an enterprise data dictionary along with corresponding data syntax rules.

CobiTdefinition:

Establish and maintain an enterprise information model to enable applications development and decision-supporting activities,
consistent with IT plans as described in PO1. The model should facilitate the optimal creation, use and sharing of information by the
business in a way that maintains integrity and is flexible, functional, cost-effective, timely, secure and resilient to failure.

Bill says,

I haven’t seen a company yet that has done this one even close to complete. What it’s talking about is defining data models for customers, vendors, employees, etc - across all applications define a consistent data model as an aid to integration and reporting. With a new company starting up I think this is something that could be done, but most of us have legacy data and applications that make a consistent data model very difficult.

Still, it is worth the effort to get it done. With a consistent and holistic enterprise information architecture model the quality of your analytics, the simplicity of your integrations and the power of your business are all magnified.

Take something as simple as the employee data model. Should be a no-brainer right? Well, it isn’t. Your HR program came stock with certain fields, your CRM with others and you probably have built a myriad of other functional applications leveraging employee data. Taking the time to make the data models consistent across all employee applications is a hard project to fund. More likely you will define your employee data model at the data warehouse level, and map your integrations with each application such that it feeds the necessary data. Once you have a data model defined in the warehouse you are about as close to having a solid data model as you could expect.

Still, even though it is hard it needs to be done the best you can.

The first step in Defining the Information Architecture is defining the enterprise information architecture model.

CobiT definition:

The information systems function creates and regularly updates a business information model and defines the appropriate systems
to optimise the use of this information. This encompasses the development of a corporate data dictionary with the organisation’s
data syntax rules, data classification scheme and security levels. This process improves the quality of management decision making
by making sure that reliable and secure information is provided, and it enables rationalising information systems resources to
appropriately match business strategies. This IT process is also needed to increase accountability for the integrity and security of
data and to enhance the effectiveness and control of sharing information across applications and entities.

Control over the IT process of
Define the information architecture

that satisfies the business requirement for IT of
being agile in responding to requirements, to provide reliable and consistent information and to
seamlessly integrate applications into business processes

by focusing on
the establishment of an enterprise data model that incorporates a data classification scheme
to ensure the integrity and consistency of all data

is achieved by
• Assuring the accuracy of the information architecture and data model
• Assigning data ownership
• Classifying information using an agreed-upon classification scheme

and is measured by
• Percent of redundant/duplicate data elements
• Percent of applications not complying with the information
architecture methodology used by the enterprise
• Frequency of data validation activities

Control objectives:

PO2 Define the Information Architecture

PO2.1 Enterprise Information Architecture Model
PO2.2 Enterprise Data Dictionary and Data Syntax Rules
PO2.3 Data Classification Scheme
PO2.4 Integrity Management

Check out the links for details on the control objectives.

CobiT definition:

Actively manage with the business the portfolio of IT-enabled investment programmes required to achieve specific strategic business
objectives by identifying, defining, evaluating, prioritising, selecting, initiating, managing and controlling programmes. This should
include clarifying desired business outcomes, ensuring that programme objectives support achievement of the outcomes,
understanding the full scope of effort required to achieve the outcomes, assigning clear accountability with supporting measures,
defining projects within the programme, allocating resources and funding, delegating authority, and commissioning required
projects at programme launch.

Bill says,

This is a fancy way of saying, “plan the work and work the plan.” You’ve engaged with the business in defining a strategic plan and project portfolio, but that isn’t a static event. You need to continually monitor performance, adapt, and if necessary move into new areas. If you did your planning right all of that is done jointly with the business so that at all times you are in agreement what IT is doing and how that is helping the business. You can’t just build your project portfolio and dive head-first into the work. This is a living, breathing thing.

Actively manage is the key phrase.

So the sixth and final step in building the Strategic IT Plan is to actively manage the IT Portfolio, working closely with the business to ensure transparency into what IT had planned to do and what IT is actually doing.

CobiT definition:

Create a portfolio of tactical IT plans that are derived from the IT strategic plan. The tactical plans should address IT-enabled
programme investments, IT services and IT assets. The tactical plans should describe required IT initiatives, resource requirements,
and how the use of resources and achievement of benefits will be monitored and managed. The tactical plans should be sufficiently
detailed to allow the definition of project plans. Actively manage the set of tactical IT plans and initiatives through analysis of
project and service portfolios.

Bill says,

The differences between Strategic Plans, Tactical Plans, and Project Plans can sometimes be difficult to draft, particularly given CobiT’s mandate of ensuring these plans are “sufficiently detailed” to drive the plans that arise from it. It is very easy to draft a strategic plan at a level of detail that would actually preclude needing a tactical plan - if you find yourself in those shoes it means your strategic plan is too detailed.

So let’s look at a hypothetical example.

Let’s say that one of our company’s objectives is to improve customer satisfaction by 10%, as measured by our quarterly customer satisfaction survey. Good, we have a pretty S.M.A.R.T objective here, and we can immediately think of a number of IT initiatives that could positively impact this goal. As I draft my strategic plan I need to consider, at a high level, what we within IT can do to help the company meet this goal. My strategy will be broken out by the various touch points we have with our customers. From Technical Support, where they interact with us through email and the telephone. From Finance, where we send them easy to understand invoices. From Development, where we make software that is easier to use.

As I put the strategic plan together I meet with the VPs of each of these areas, and get agreement on how improvements in these areas would positively impact our goal. We define some objectives and measurements for each area, and I allocate a percentage of my budget to each.

For the tactical plans I then take each of these strategic areas and break them out into how we will actually address them. Let’s look at Technical Support. Suppose we have agreed that there are a few things we can do to help Technical Support better serve it’s customers. We can streamline the IVR menus so a customer gets to an agent quicker. We can enable a searchable knowledge base for our customers. And we can introduce an email response program that let’s customers know we have received their email and have created an incident for them.

For each of these tactical responses meant to address the overall strategic objective, we need to similarly define resources and budget. These tactical plans would then easily lend themselves to having specific project plans built. And best of all, project team members have an immediate and clear understanding of how their project ties to corporate objectives - it’s a very clear path from project, to tactical plans, to IT strategic plans, to corporate objective. It ties together very nicely.

So the fifth step in building the Strategic IT Plan is to create the IT Tactical Plans, which addresses how we are going to address our strategic goals at a sufficient level so that project plans can be drafted and that there is a clear tie back to the corporate objectives driving our strategic plans.