IT Governance Blog

CobiTdefinition:

Create and maintain a technology infrastructure plan that is in accordance with the IT strategic and tactical plans. The plan should be based on the technological direction and include contingency arrangements and direction for acquisition of technology resources. It should consider changes in the competitive environment, economies of scale for information systems staffing and investments, and improved interoperability of platforms and applications.

Bill says,

It is in the Technology Infrastructure Plan where the strategy and the tactical meet. This is where you define things such as the role virtualization will play in addressing your technology strategy, who your primary technology sourcing vendors will be, and how geographical issues will impact your data center and staffing plan.

For example, let’s say that in your Technological Direction Planning you have identified that virtualization provides not only business opportunities for your company but opportunities for server consolidation and improved support within your IT organization. As that as the backdrop for the direction you want to go, it is in the TIP where you will outline how you will accomplish that. It is appropriate that in the TIP you will also outline how such a move will save on staffing expenses should that be an expected outcome.

By now you have seen enough of CobiT to know that much of this really isn’t complicated and it really is kind of obvious. You might be saying, why do I have to be told to create a direction plan and that a plan for how to implement that direction, as that seems so obvious. The problem is as obvious as it may seem it simply doesn’t get done to the degree you would expect. By following a framework like CobiT you can ensure that you are following best practices for running an IT organization. A governance framework is not designed to produce any real “aha” moments - it is simply to ensure that you have control over the basics. It is control of the basics where many companies fall down.

One thing you will note is the CobiT doesn’t give you guidance on much beyond what the basics are. So for example, what is the audience of the Technology Infrastructure Plan? Do you share it with your managers? All IT staff? Everyone in the company? CobiT isn’t going to give you guidance there, that is up to you and your knowledge of the culture of your company.

For me, I actually create two versions of the plan. One for Senior Management and one for general consumption. I believe that it is important to have corporate visibility to these plans.

The second step in Determining the Technological Direction is building the Technology Infrastructure Plan.

CobiTdefinition:

Analyse existing and emerging technologies, and plan which technological direction is appropriate to realise the IT strategy and the business systems architecture. Also identify in the plan which technologies have the potential to create business opportunities. The plan should address systems architecture, technological direction, migration strategies and contingency aspects of infrastructure components.

Bill says,

You have to give your team some context for your technical leadership direction. Are you the kind of leader, and hence your IT organization, who is a risk taker willing to implement the latest and greatest technology? Or are you more pragmatic, waiting for the other guys to take the risks on new technology first?

It is in the Technical Direction Planning CobiT control objective where you define this direction, and hence lay out the future for the direction your team will take from a technical standpoint.

Does Software as a Service make sense for your organization? What about mobile technologies? VOIP? Are there productivity improvements to be made there or are the risks too great? You need to map out these existing and emerging technologies and make clear what you as a leader are willing to accept.

From then on the details can be worked out.

The first step in Determining the Technological Direction is doing the necessary technological direction planning.

CobiT definition:

The information services function determines the technology direction to support the business. This requires the creation of a technological infrastructure plan and an architecture board that sets and manages clear and realistic expectations of what technology can offer in terms of products, services and delivery mechanisms. The plan is regularly updated and encompasses aspects such as systems architecture, technological direction, acquisition plans, standards, migration strategies and contingency. This enables timely responses to changes in the competitive environment, economies of scale for information systems staffing and investments, as well as improved interoperability of platforms and applications.

Control over the IT process of
Determine technological direction

that satisfies the business requirement for IT of
having stable, cost-effective, integrated and standard application systems, resources and capabilities
that meet current and future business requirements

by focusing on
defining and implementing a technology infrastructure plan, architecture and standards that
recognise and leverage technology opportunities

is achieved by
• Establishing a forum to guide architecture and verify compliance
• Establishing the technology infrastructure plan balanced against cost, risk and
requirements
• Defining the technology infrastructure standards based on information
architecture requirements

and is measured by
• Number and type of deviations from the technology
infrastructure plan
• Frequency of the technology infrastructure plan review/update
• Number of technology platforms by function across the enterprise

Control objectives:

PO3 Determine Technological Direction

PO3.1 Technological Direction Planning
PO3.2 Technology Infrastructure Plan
PO3.3 Monitor Future Trends and Regulations
PO3.4 Technology Standards
PO3.5 IT Architecture Board

Check out the links for details on the control objectives.

CobiT definition:

Define and implement procedures to ensure the integrity and consistency of all data stored in electronic form, such as databases, data warehouses and data archives.

Bill says,

“All data stored in electronic form” is one hell of a big task, but if you are to implement the proper level of controls that is truly what you are on the hook for. Once you have classified your data you will have a list of what is important to your business and what you need to control. Now you have to design and implement the procedures that ensure that data is what you think it is and it has the visibility that you think it should have.

Integrity of the data is fairly simple for static data, you really just need to be able to maintain an archived version that you can compare it to proving it’s integrity, assuming of course that you have the security of that data established properly.

The biggest challenge to integrity management is in your transactional database where your staff, and perhaps even your customers, are responsible for maintain some aspect of that data. This is where you need to automate as much as possible so that you are not relying on human nature, but no matter how much of that you do you will still be on the heck for documenting those processes and controls.

Integrity management is difficult but important. If you have followed the steps within this control objective you should be well on your way to achieving a good level control.

The fourth step in Defining the Information Architecture is integrity management.

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.