IT GOVERNANCE COURSES FOR CIO

ESA and IT Governance

In order to assert better control over IT, align it with business objectives, and keep its potential benefits and risks in balance, corporations in recent years have paid considerable attention to the issue of IT governance. Also spurring this renewed attention are financial regulations, such as Sarbanes-Oxley, which call for improved documentation of IT systems and tighter controls over who uses them and to what end. The result is that enterprises have sought to bring to IT the kind of streamlined and rigorously defined business processes and reporting structures that IT has helped to make possible just about everywhere else in the enterprise.

If a formal definition of IT governance is required, it’s hard to top the one provided by Jeanne W. Ross and Peter Weil in their book, IT Governance (Harvard Business School Press): "specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT."

IT governance, they elaborate, provides a framework in which the decisions made about IT issues are aligned with the overall business strategy and culture of the enterprise. Governance is concerned, therefore, with setting directions, establishing standards and principles, and prioritizing investments.

Throughout this book, we have talked about how ESA ushers in fundamental changes in every area. It changes the relationship between business and IT, a relationship that is at the heart of most governance issues. In this chapter, we will see that ESA greatly simplifies governance. How so? ESA changes how the enterprise perceives, organizes, and manages many aspects of IT, divvying up financial and managerial responsibilities in radically new ways.

In the past, when business asked IT for changes to an application or system, that system was monolithic, and consequently the implications of the changes required a great deal of study and consideration. Enterprise services are granular. Corporations will have many, many enterprise services running. But because the function of each is discrete and the relationships among them are well understood, the process of approving a new service is far easier than that of approving a change to an new application. Needless to say, the budgetary requirements of such changes are far less as well.

ESA doesn’t change the questions that IT governance attempts to answer, but it does change the answersin important ways. The questions that are asked are fairly straightforward, even if different companies have answered them in different waysthrough tight central control and mandates, perhaps, or in a decentralized approach that gives business units a good deal of autonomy. Among these questions: what standards is the enterprise adopting and enforcing in IT? Who in the organization is responsible for defining and building which pieces of IT? Who pays for this or that application or service? When are specific functions to be centralized or decentralized? What is the relationship of any one part of the company to the other parts? What does each department owe the other?

 

What are typical models for IT governance?

Traditionally, there have been two approaches to IT governance: centralized and decentralized. As its name implies, the centralized model calls for a central authoritythe IT department, that isto retain control over development budgets and the adoption of technical standards. To get new apps built, have old apps extended or modified, and procure new equipment and software, other business units within the organization must go to this central authority for approval and help.

The decentralized approach, which many corporations adopted as mainframe-based data processing gave way to client/server computing in the 1980s and 1990s, has shifted a certain amount of power over budgets and technical matters to business units and even to individual departments within those units. With less central oversight, these disparate groups of users can easily end up creating systems that over the long term do not work together particularly well. Semantic problems, such as differing definitions of "customer," for instance, can make it difficult for independently run systems to communicate and share information. In response to this, a small industry of application integration techniques, products, and companies has arisen.

What are the challenges and problems with existing models?

ESA simplifies the relationship between IT and business, yet standards remain as important as ever, if not even more important, to a successful deployment of ESA within any particular user organization. ESA calls for strict adherence to certain technical standards when creating enterprise services. Without standardized networking interfaces and semantic definitions, for instance, any enterprise services that an organization builds for itself will be unlikely to integrate properly with any other enterprise services, whether homegrown or acquired from SAP or its partners. Fluid integration, of course, is the primary goal of ESA. So, without the right policies and incentives in place to make sure that ESA-related standards are employed, ESA’s essential value will be lost.

Standards policies are hardly a new, ESA-specific issue for IT. Enterprises have been grappling for years with how best to select, support, and enforce IT standards within their own ranks and across boundaries when dealing with suppliers, customers, and other business partners. When a corporation is powerful enough in its own industry, it can pretty much dictate the use of certain standards to any other firms with which it does business. Just look at the clout that Wal-Mart wields in retailing, as seen most recently in its mandate that suppliers must start adding a certain type of radio frequency identification (RFID) tag to the pallets they send its way. At the other end of the spectrum is Yahoo!, the web portal, which has forfeited the benefits of blanket IT standardization and permitted its disparate business units to develop and operate their IT systems pretty much as they see fit. In fact, Yahoo! may have little choice in the matter. Evidently, it has decided that this approach is the best one, financially and technically, in the kinds of volatile, high-growth, technology-driven markets where it does business. What’s more, the web giant has acquired many of its business units as independent, self-sustaining startup companies which, by the time they join the Yahoo! fold, are well along in developing their own systems.

Wal-Mart and Yahoo! have chosen the approaches that are most appropriate to their respective marketplace and strategy. A key element of Wal-Mart’s business strategy is to squeeze cost and inefficiency out of every possible business process, and that calls for a high degree of standardization in those business processes and in the IT systems that support them. Standardization of IT tends to hinder flexibility, but mass retailing is not subject to dramatic change. Success, therefore, is mainly a matter of progressively improving business processes and cost structures. To help keep IT costs down, Wal-Mart strives to standardize as much IT activity as possible, making it easier to replicate existing systems and teams wherever required and to keep training and operations costs to a minimum.

Yahoo!, in contrast, must continually scramble just to keep up with the fast-expanding, highly entrepreneurial web marketplace. There, new opportunities emerge and are jumped on virtually every day, it seems. Yahoo! can’t afford to hinder its internal developers or newly acquired businesses by imposing on them more than a minimal slate of IT standards. It does, of course, pay for granting this freedom: it has to foot the bill for an exceptionally talented IT team whose ministrations are necessary to keeping Yahoo!’s plethora of systems running and integrating them at the relatively basic level of user interface (UI) and customer billing, for instance.

Most companies do not fit either one of these extreme molds: the highly centralized Wal-Mart mold or the highly improvisational Yahoo! mold. Instead, they will find themselves somewhere in between. Their challenge, therefore, is to work out a form of IT governance that’s most appropriate to their circumstances. But they would do well to understand these extremes and glean from this picture a fundamental factnamely, that in the IT organization, governance typically comes down to control. Who, it must be decided, has how much control over IT decisions, and therefore, control over expenditures of money?

How does ESA decrease the need for IT governance?

ESA reduces the need for IT governance dramatically. The reason for this is quite simple. Governance is about getting approval for changes, about power, about who wields that decision-making powerand how long such decisions take, given the speed of business change.

One way ESA significantly helps is by greatly reducing the incidence of decision making. Here is why existing enterprise servicesand as much as 80 percent of the enterprise services you will ever need will come from SAP in the Enterprise Services Inventoryare already standardized. These services are therefore freely available to business analysts not only to consume, but also to use in composing new applications. The number of building blocks in the box, so to speak, is enormous. The only time that decisions must be made is when you need a building block that you don’t currently have. Over time, as more services are created (and approved), the number of blocks in the chest increases, and it becomes more likely that the service you need is already in that chest. In this way, the granularity of enterprise services reduces the amount of time you spend on such decision making by reducing the numberand scopeof the decisions to be made. Such decision making is incremental rather than sweeping, reducing hassles for all concerned. Meanwhile, because enterprise services are available for composing new applications and modifying existing applications without the help of IT, business gains an unprecedented level of flexibility to change business processes at a high level.

How does ESA improve the relationship between business and IT?

In the past, the relationship between business and IT has at times been tense. Business wants agility to implement new strategies quickly. Requirements are handed off to IT and not only does it seem to take a long time to implement the required functionality, but often much is lost in the translation from requirements document to executable system. ESA promises to repaint this picture by, in a way, decoupling the IT side from the business side and giving each what it has always sought. For the first time, enterprises can reap the benefits of a uniform IT architecture while also enjoying a new level of flexibility in IT that’s sufficient to truly meet business needs.

A fundamental principle of ESA is the separation of business logic from application logic. Business analysts gain the ability to define, change, and adapt business processes, supported by enterprise services. IT’s responsibility is equally clear: it must manage the stack from the application logic down to the physical infrastructure. IT is in charge of the underlying platform for ESA: the Enterprise Services Repository. IT must also deal with operational issues, run server farms, secure the infrastructure, ensure that the network is running properly, and much more. ESA in essence improves the relationship between business and IT by making it clear who owns what and giving business a degree of independence to do what it needs to do without having an impact on IT.

This does not mean that IT and business never negotiate again, but by empowering business with agility to work with critical business processes and to compose applications from existing enterprise services, the need for an interface becomes narrower and the questions become smaller. Instead of approaching IT with a major change to a monolithic application, business gains the ability to make strategic changes without endangering the application ecosystem; again, giving each side what it has always wanted.

Where standardization becomes importantand where it is in the best interest of business itselfis in the development of new enterprise services. Enterprise services creation should be subject to a governance process to ensure that the new service "plays well" with existing services, that dependencies are well understood, that data types are standardized, and that reuse is maximized. Still, the question of whether to create an enterprise service is far smaller than the question of whether to customize the Customer Relationship Management (CRM) system, and the ability to reach a decision will be easier as well. But this begs provocative questions: who makes that decision? Who owns the enterprise services? Who has the authority to make decisions about them?