Certain segments of the computer press write endlessly about governance. Research groups produce reams of white papers about it. CIOs with a certain type of background talk on and on about it. So, what is governance exactly?
There are as many definitions and interpretations of governance as there are IT consultants and pundits. That means we are going to be stuck with my interpretation of governance as it applies to the real world. Governance is all about rules and guidelines that allow you to manage performance and risk for IT systems. Governance is used to operate, manage, and maintain IT systems within the organization. That is the core of governance: rules to live by. What interests me more specifically is governance as it applies to certain systems within IT. Corporate governance is all about running the organization; IT governance is about running IT; and system or application governance is about running a particular system or set of applications.
Geeks and More Geeks
In the world of information technology, there are two broad categories of people. You have your network and infrastructure geeks, and you have your software and developer geeks. The network and infrastructure people like rules. They like the fact they have access to everything on the network and nobody else does. They like the fact they have secret MP3 and Warez servers no one else can access. They carefully control your desktop and your information rights. Governance is cool to these guys–more rules they can create and enforce. Developers, on the other hand, generally hate rules. They think rules restrict the creative process. Corporate rules and dress codes are anathema to them. These are the guys who play foosball or Warcraft all day (or all night) long and then code all night (or all day) long. These guys hate the whole idea of governance.
Governance Is Good
My background is in software development. I generally have been opposed to the whole idea of governance. So, you may ask, why am I now proposing governance is a good and necessary part of an effective IT organization? In fact, that raises the larger question: Why do we need governance? I propose there are two very simple and very real reasons we need it:
oWithout governance, you will not have control over your systems. You will fail.
oWith governance, you will be prepared for (almost) any situation that may arise.
The Real World
Let me give you an example. A few years ago, a very large multinational organization was using Microsoft SharePoint Services v. 2.0 as a platform for a corporate intranet handling collaboration and knowledge sharing. There were more than 10,000 users spread across the globe and across different time zones. They were using that intranet for mission-critical information. Over the course of a weekend, the infrastructure team ran a series of updates and patches on all Wintel servers. On Monday morning, the collaboration intranet was down, and it was down hard. It took the better part of a day to bring that application back online.
Who do you think got the black eye on that one? It wasn't the infrastructure guys. The SharePoint team took the blame. That seemed pretty unfair to me at the time. Then I started to think about governance. If a proper SharePoint governance plan had been in place and had been enforced, the mindless application of patches and updates would not have been permitted. A governance plan would have dictated all patches and updates be tested in a development or staging environment.
That particular debacle didn't end with the update problem. After the intranet went down, it became apparent there was no plan for disaster recovery (DR), which would have been a part of an application-specific governance plan. The IT organization as a whole had a DR plan, but that plan entailed server and database backups to tape and other media. Theoretically, backing up "everything" to tape should provide a method for data and application recovery, but in the real world, those backups are only a beginning. Complex applications require complex configurations and cannot always be restored by running a restore to server. In this case, the intranet was restored from database backups, but there existed no road map for accomplishing that restoration. Quite a bit of blood, sweat, and tears went into a restore that should have been already scripted and tested. That is, if a proper governance plan had been in place.
More Harsh Reality
Let's look at one other real-world scenario. This time, a much smaller organization rolled out Microsoft Office SharePoint Server 2007 (MOSS 2007) as the foundation for its corporate intranet. Things were going great–users and managers were excited about the new platform and the opportunities it provided.
The SharePoint administrator was handling a level-three support call, which he didn't understand. He decided to try to duplicate the reported error. He did this on a production server. Thirty seconds later, the system was down. There were no current backups of the server or the database available. It took about 12 hours to get that system properly running again.
People: The Weak Link
That last tale actually brings up another reason we need governance. One would expect an IT professional, a system administrator, to know and understand it is not acceptable to try to create errors on a production server. I would like to think everyone on my staff has enough sense to "know" what is right–to know what proper procedures are. But the hard fact is you can't expect that kind of knowledge or good sense. You need to create as many safeguards as possible in order to eliminate the folly of humans, and an enforced governance plan is a major step in that direction.
Which brings me back to why I am now a believer. I have seen too many organizations fail because they did not have proper procedures and policies in place. Governance works, and I highly recommend that you implement not only IT governance plans but application-specific governance plans.
So, what constitutes an application-specific governance plan? My preference is to create governance plans that are concise and to the point. The plan needs to focus on critical items for success. It does not need to be an all-encompassing document filled with generalities and mission statements. I have seen model plans that contain 80 to 100 pages. And those are model plans that never will be read or enforced. Keep it simple–15 to 20 pages is a nice limit. That is about as large a plan you can create that people will actually read and comprehend. When possible, use bulleted lists or tables, not prose. When you create a section on monitoring server health, make it in the form of a checklist technicians actually can use. The section on service-level agreements should spell out the SLAs. Don't create a governance plan that states there will be an SLA published–publish the SLA in the plan itself.
Four major areas need to be addressed in an application-specific governance plan: management, operations, communications, and training.
Management
Management defines the process of managing the application. It defines the proper use of the application within the organization. It defines roles and responsibilities. Who does what, and who decides what? If an application is important enough to warrant its own governance plan, it also is important enough to establish a governance committee that creates and enforces that plan.
That committee should be composed of individuals from business units or divisions that use the application as well as IT folk. Members should represent different levels within the organization. You don't want all managers or all worker bees on a governance committee. There also needs to be an executive sponsor with the juice to get things done.
Operations
Operations probably is the most obviously critical part of a governance plan. Operations will define the process by which an application will be kept fully functional. It should describe in some detail the information architecture, the physical architecture, and the taxonomies of the application. It should address in detail DR and backup and recovery plans. As stated earlier, many applications require specialized methods or even specialized tools for best-practices backup and DR. Many organizations use server virtualization, which adds further complexities to DR. The additional methods of system restoration provided by virtualization should not necessarily replace "standard" methods.
Maintenance plans should be defined. Who is responsible for checking server health, for checking logs for basic monitoring? Is there a central management system such as MOM (Microsoft Operations Manager) in place? What sorts of warnings and alerts do we need to set up? Change management should be defined. We need policies for patches and updates. We need policies for promoting changes to production. We need policies for defining what an acceptable change is. We need to define clearly what is and what is not acceptable in our environment. Nothing should be left to the whim of an individual or chance.
Application support is critical. Who is going to handle level one, two, and three support? Most corporate help desks reach the limit of their abilities somewhere in the middle of level-two support. Advanced support probably is going to fall on the shoulders of the IT people who administer and manage the application.
Communications
Communication needs vary from company to company and from application to application. Any time you introduce change into an organization, that change should be communicated in such a way users are predisposed to accept the change. Corporate culture by its very nature is change resistant. A good communications plan can ameliorate the effects of that resistance.
Training
We need clearly defined training plans for a couple of reasons: The first and most obvious is workers require proper training in order to use an application effectively. The second is proper training also will serve to offset resistance to use of the application.
How many of you have made the switch to Vista or to Office 2007? The latest operating system and the latest Office suite from Microsoft introduce major changes in the user experience. Without proper training, acceptance of the new product will be limited. Why do you think major computer manufacturers had to go back in time and now offer XP as well as Vista? Training is the key to success in many areas.
The Final Word
A good application governance plan will include consistent rules and guidelines to strike a fine line between giving users enough flexibility to use the application creatively and providing enough oversight to mitigate risk and properly manage the solution. Take it from one who used to be a non-believer. Governance works. Governance is good. TD
Please address comments, complaints, and suggestions to the author at prolich@yahoo.com.
© Touchpoint Markets, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.