By donflinn | February 13, 2010
Sorry about the hiatus between blogs. While I was busy, the primary reason was a trip up the Amazon River and hiking and camping in the Amazon jungle arraigned by MIT Alumni Travel. It was a great adventure with many thanks to our guides, Eric and Jorge and our lecturer Dr. Rafael Bass.
Now to this blog: We will be covering the governance of IT Infrastructure, which is even more dependant on the technical content and support than the IT Architecture covered in the previous blog. As with architecture we will approach this subject from a business point of view.
Infrastructure is that portion of IT that supports delivering IT services. This includes security, performance and company wide processes. Conversely, business applications, which will be covered in our next blog, are under the purview of a specific business unit and are aimed at solving a particular business problem. To put it another way, IT infrastructure is applicable to company-wide scope while business applications are applicable to a single task or scope. This distinction is important and has an influence on your corporate governance as you will soon see.
Because there is confusion between what comprises IT infrastructure and what comprises business applications, it will help to describe this distinction, which, in turn, will help clarify the definition of infrastructure. Since analogies are useful in describing complex subjects, we’ll compare a city’s infrastructure to an IT’s infrastructure as well as use the relationship between individual home owners and the city to help explain a business application’s relationship to the IT infrastructure.
Among the reasons that a city builds an infrastructure is that comprehensive, centrally planned and built systems are more efficient, less costly and beneficial to all its citizens. Similarly, in IT certain services are more efficient and less costly if they are developed company-wide rather than each business unit building its own private version. Building on our analogy, image what would result if each homeowner built the portion of the road in front of their house. One home owner might want more front yard and build their portion of the road very narrow, impeding most traffic or the road might have a dirt road portion next to a neighbor’s asphalt section.
Digging deeper into the details of an IT infrastructure, we see it consists of those functions that are used by many of the business units, just as a road is used by many home owners, or the infrastructure may support new company initiatives, just as the city’s water system can be used for new initiatives such as conservation. As a corporate example, companies such as State Street Bank described in an earlier blog, who have a prime goal of customer satisfaction throughout its different business units, would use a customer database as an important part of the corporate infrastructure.
Another example would be companies who have decided on a large middle-ware system such as SOA (Service Oriented Architecture), where the SOA software implementation would be an infrastructure element and support many diverse services. A third, more obvious example might be the corporate financial software system, which serves corporate goals as well as individual business units.
For the reasons of continuity, cost and efficiency, cities have concluded that certain functionality should be designed and constructed by the city, while certain activities are best left to the individual home owner. Contrast this with companies where many still have not learned these elementary lessons – each section or division insists that they alone design, control and direct all the IT functionality that they use. Not only does this result in poor interconnectivity and smooth flow of data and processes but it also results in redundancy, excess cost and many times, conflicting and mutually destructive IT sub-systems.
Why is this self defeating practice permitted take place in technology when other entities have corrected this type of problem years ago? There are two major reasons:
To correct the first problem, a comprehensible corporate IT architecture must be developed with strong business rational. With a well thought out and documented architecture it becomes more obvious what functionality should be corporate wide and what can be specific. A dense, technically laden document will not bring clarity. High level summaries and diagrams of the important operational aspects go a long way clarifying the critical interconnectivity and optimum distribution of IT assets.
Management, up and down the line, must be required to be aware of and understand the architecture. Understanding implies that management must insist that the architecture documents be written to be understood by non-technicians, i.e. from a business perspective and not be technical mumble-jumble. Using the latter is simply laziness on the part of the writers or an admission that they really don’t comprehend the business rational for what they are doing.
Having information available, complete and comprehensible to the decision makers is no less than a prerequisite for good corporate governance.
Turning to the second problem, taking responsibility is a good trait for every manager, but extending this to mean controlling that which is beyond what is good for the company is not. It is not a trait of good governance to abdicate all control and direction to individual business unit or else there is no raison d’etre for the overarching company. Balancing that which should be controlled from a corporate level and that which should be controlled at lower levels is involve particularly hard decisions, especially when it comes to technical infrastructure. Major reasons are the abstract nature of much of computing infrastructure and its highly specialized nature.
How can management make far reaching technical decisions, if they don’t have a full understanding of the technology? That is not the right question. What management requires is an understanding of the business effect of technical decisions and as we said above, this comes from insisting that the necessary technical information be delivered in a business oriented manner. This is hard, since no manager likes to admit that they do not fully understand something and technical people find it easier to use technical language. I had a tremendous manager at Hewlett Packard who, when and engineer would come to her with a long spiel of techneese, would say, “Tell me in baby words.” It was effective and she made strong technical decisions as a result of clear descriptions. While different managers will find different ways to express and enforce this point, no manager should accept anything less than a clear, business oriented description.
Let’s now return to the difference between technical infrastructure and business applications. First, IT infrastructure is a core capability upon which more directed technical capabilities, e.g. business applications can be constructed. Infrastructure benefits multiple business units, whereas business applications chiefly benefit a business unit or single process. Be careful about some slippery slope logic here. A business manager might say, in all sincerity, that a particular system, if built and controlled by their business unit will be more suited to that unit’s work and thus make the unit more profitable, which, in turn, would be good for the company as a whole. Management must examine this assertion carefully and balance the value of each proposal as to its particular value to the company as a whole; not its value to one business unit.
Recalling State Street’s “One State Street” implementation of customer data, it would have been more advantageous from the viewpoint of each business unit to have customer data specialized to that BU, but that would not support the corporate goal of having each portion of the business support each other to the combined benefit of the customer. One could quibble and rationalize, but at the end of the day it comes down to aggrandizing individual managers verses meeting corporate goals.
Another aspect of IT infrastructure is its use of standardization. Whether we are talking about data or processes, a critical choice is whether to use a standard method of presentation, storage and usage across the organization. A further refinement on standardization is to use formal standards supported by international standards bodies. Using recognized standards insures interoperability both within the company and between companies in those occasions when interacting with external entities. In taking the standardization approach, sectors of the company conform to the infrastructure rather than sectors making the capabilities conform to their specific needs. There are numerous examples of successful companies that chose wisely about which functionality should be company wide and which functionality should be specific to a given business unit. Make your company one of the former rather than one of the later.
Modern systems are developing more interaction with suppliers, customers, partners and government entities. In many cases the infrastructure handles these interfaces. Most of these interfaces may be accessed in a standard manner, with exceptions for special cases. In addition, there are numerous connection mechanisms beyond the standard computer to computer interface, such as cell phones and PDAs. The infrastructure should handle these while the business applications interface with the infrastructure in only one way, thus removing redundant connections for each different part of the company. Security becomes especially important in these external connections. (We’ll have a blog dedicated to the many aspects of security later on.)
There is a need to manage the various aspects of communications and security, i.e. the who, what, when and how. The infrastructure is the proper place to handle the management of the disparate IT resources.
Infrastructure requires close cooperation between business management and technical management: Technical management because of the many technical subtleties of IT infrastructure and business management because of infrastructure’s far reaching effect and high cost. Top management interaction is necessary because of the temptation of individual business unit managers desire to suppress the infrastructure within their BU’s.
Who should take the lead? In this case the phrase, “Render unto Caesar that which is Caesar’s” is most appropriate. Technical aspects should be lead by the CIOs and their team and the business aspects of cost and value for advancing corporate goals should rest with top management. As we pointed out earlier, it is critical that the technical people explain the infrastructure in business terms and that business management insist on this and help with the translation of the technical aspects to business value. While all aspects of IT Governance demand this interaction, in IT infrastructure governance, it becomes especially important because infrastructure’s high cost, which can be major portion of the IT budget, as well as infrastructure’s long range impact on corporate success.
Determining who pays for infrastructure is a difficult subject. If the infrastructure is not built to each BU’s specifications, you will get push back on how much they should pay, if anything. Trying to determine the value to a particular business unit verses the value to other units verse the value to the company as a whole is especially difficult.
Below are a few broad approaches to this problem, none of them entirely satisfactory. In some case combinations of the suggestions below work better.
As you can see, determining the charge offs range from arbitrary decisions to attempting to determine hard-to-pin-down value. Top management must be up-front with their managers, admitting that there will be some arbitrariness in any approach, but that for the company’s success in the battle field of the marketplace, this particular functionality is needed and the burden must be shared.
A simple solution is to have corporate pay for all infrastructure. However, this penalizes those units which receive no value contrasted with those that realize big gains. It could also encourage wasteful use of the resource. On the other hand, heavy charge backs based on some measure of value could result in under use of the resource, to the detriment of the unit and the company.
We’ll leave you with the knowledge that this is hard nut to crack, but that’s why they pay you the big bucks ?. Let us know of approaches or combination of approaches that have worked for you. I’m sure your fellow CIOs will appreciate it.
Our next blog will discuss governance of IT business applications.
Topics: IT Governance | No Comments »
Leave a Reply
« Do CIOs Still Matter? | Home | Complex Times Demand Simpler Solutions »
RSS Feeds
