EDUCAUSE Review, vol. 42, no. 6 (November/December 2007): 24-53
The Origins of the Great Centralized-Decentralized IT Debate
Information technology in higher education is currently undergoing a bit of an identity crisis. Although IT is known as the go-to group when an academic, research, or administrative problem needs a technical solution, IT teams exist in so many places on today's campus that for many in the campus community, it is no longer clear who should be contacted in order to request services: the local IT person? the unit or divisional IT group? central IT? This organizational confusion about IT delivery doesn't just affect the clients of IT. Often technology staff themselves are left wondering which clients they serve and what exactly their role should be. Who should take responsibility for developing requirements, for designing architecture, for building and operating and maintaining services? Worse, the lack of clear responsibility among different IT groups often leads to confusion, internal turf battles, and ultimately poor customer service. Although this situation may appear to be the result of a struggle for control between IT teams or an outgrowth of a technological or operational difference of opinion, I believe it is actually a symptom of the professional evolution of IT. Over the last twenty-five years, as the work of IT professionals has moved from running centralized servers to supporting local area networks and building Web applications at the departmental level, the required IT skill set has broadened beyond the technical to include both technical and functional (business process) expertise. This blending of responsibilities has had a direct bearing on the current confused state of affairs—more so than the commonly perceived conflict of "centralized versus decentralized IT."
To understand how we arrived at this conflation of roles, we need to think back to what IT was like before seemingly every member of the campus community held a computing device in his or her hand, pocket, or purse. In the beginning, way back in medieval computing times, there was the mainframe. And IT was good—if you were a technology person. The data center staff kept the arcane machines running and controlled the input and output at each step of the process. When requested, the staff would coax the system to pour forth data and, with it, the informational nourishment needed by schools and colleges. Enroll students? Add it to the mainframe. Process the payroll? Add it to the mainframe. These workhorse machines could do it all, if someone knew how to program them and if the institution had the resources to purchase and run them. However, most of the functional community on campus did not have the background or training to know what could be accomplished with this new computing power. It was often easier for IT staff to learn about the minutia of a business need than it was for the business folks to learn the capabilities of mainframe computing. As a result, central IT was established not only as the owner of the technology but also as a functional expert designing business process solutions to take advantage of the new capabilities. Yet it wasn't long before the individual units waiting in line for access to the information stored within the central systems became frustrated and at times disenfranchised by the entire process. Why, the financial aid officers wondered, should they have to depend on a central group to give them reports on their own data, especially when those reports never quite met their specific needs? What chance did the small department or school administrator needing a screen change have of that request being prioritized over the long line of central campus requests? The inherent inequities in a solution owned and controlled by a single group seemed to negatively affect most functional groups.
Today's decentralized departmental computing environment can be considered a direct outgrowth of those early days of centrally controlled computing. As hardware and software became cheaper and more powerful, the organizational pendulum swung away from a reliance on the mainframe to a model that emphasized local control and independence. The emerging technology vendors were more than interested in encouraging this shift as they looked for ways to unseat the perennial powerhouses (IBM and, later, Microsoft). The explosion of technology that followed—beginning with client/server solutions and continuing with the expansion of the Internet, open-source software, and now the Web 2.0 world of mashups—has continued to move IT further away from the original vision of a central IT group providing technology to solve campus research, administrative, and academic problems. Now departmental IT, particularly in the larger units, effectively provides the majority of services, even as smaller units—which have historically had fewer resources—still struggle, frequently without success, to match the local capability of the larger units. Meanwhile the response of central IT, as it lost customers to the large departmental IT teams, often was to gravitate toward large-scale administrative projects. Central IT also created dedicated "academic" or "research" or "administrative" computing teams to demonstrate its continued relevance and deep functional knowledge, even as the solutions being developed by central IT served an increasingly smaller set of campus needs. Departmental IT in turn reacted by adding technical competencies most often found only in large central units. The resulting stalemate has created significant overlaps in capability without offering better overall value to the institution.
Today the trends that created the conditions for these challenges are accelerating, with technology solution-building capabilities (and, in some cases, expertise) emerging beyond the realm of either the centralized or the decentralized IT arena and directly in the hands of individuals. In the coming years, faculty, staff, and students who never needed to know the inner workings of IT will be able to deliver their own unique solutions (in some cases, quite sophisticated ones) by simply dragging and dropping application widgets together. This "democratization of technology" changes the discussion from a choice between centralized and decentralized services to a consideration of an entirely new set of supply options. IT in higher education must adapt, but what approach is best when each individual will need his or her own customized IT support? Neither the centralized nor the decentralized model can cost-effectively deliver solutions using traditional legacy approaches. The era in which resources and political energy are spent trying to solve the centralized-versus-decentralized debate has passed and is being replaced by the rise in technology controlled by the individual. It is time to shift the dialogue to considerations not of which is better, centralized or decentralized, but rather of what changes need to occur to provide support for communal technologies. In the exploding landscape of supply options, which should we IT leaders be supporting, which should we be watching, and which should we be cautious of? Working together in partnership, all of us—the departmental and the central IT units—will have to reinvent ourselves in the coming years if we are to remain an effective force of enablement for our campuses.
Key Principles for IT Organization
IT resources, functions, and operations may be centralized or decentralized, depending on the circumstances. There is no correct model to fit all situations. When making this decision, IT and institutional leaders should consider several important principles.
Strategic framework: Creating an overarching framework and structure for the IT organization needs to be centralized so that there is a clear vision and strategy for the future.
Consistency: An employee or student should be able to move among many campus locations and still be able to function within the technology setting, without having to be retrained or experience a sense of haves and have-nots. Students and faculty should have access to a consistent, base level of technology that applies a standard uniformly across the college or university.
Coherence: Systems and networks need to integrate and interact with a minimum of disruption and inconvenience to the end-user. End-users should not have to understand the architecture to use a system. For example, as much as possible, one ID and password should provide access to many systems.
Consolidation and elimination of redundancy: Duplication adds costs to the environment. Where possible, lean management principles suggest the elimination of duplication and redundancy to reduce cost, unless we are trying to achieve greater resiliency and ability to recover from a disaster.
Single source of truth in systems: Duplication also adds confusion and lack of trust. Shadow systems may produce varying results. Critical decision-support systems and financial and student records must not be duplicated.
Auditing requirements and controls: Auditors require that central IT respond to audit questions. The areas subject to external audit require the strongest controls, and central IT needs to have the systems and environmental knowledge to respond to the audit. Systems that typically require external audit are the financial systems, enrollment systems (state auditors), and financial aid (external financial aid auditors).
Separation of duties: No one person should be able to accomplish a security breach or a theft of money with that action going unnoticed. Auditors ask institutions to respond to separation-of-duties requirements. Whereas central IT generally has enough staff to meet separation-of-duties requirements, the lone system administrator cannot do so. Sample separation-of-duties requirements include the following:
- IT staff should not have access to production data, unless specifically authorized by the functional data owner to repair one record.
- Applications code should not be modified by functional staff.
- Applications support staff should not access systems-level technology or database management systems.
- Systems programmers should not access applications code or database management systems.
- Database managers should not access systems-level technology or applications.
- Access to firewalls should be limited to the network security analyst and should be internally reviewed by the security management administrator.
Disaster recovery: In the event of a disaster, the college or university should have a cohesive plan to return critical operations to service as quickly as possible.
External security reporting requirements and compliance: Certain external agencies require coordinated official response. For example, IT must respond to network-abuse reports that come from organizations all over the world. IT must process and handle violations of the Digital Millennium Copyright Act. IT has to track emerging legislation and develop responses, such as for the new federal rules for e-discovery. Recent research guidelines are requesting campus/university security procedures as part of the grant application process.
Diversity and specialization: To be effective for a broad range of IT uses and clients, the IT organization must include a diversity of skills and specializations.
Depth and breadth of expertise: Information staffing may be an issue. Some rare skill sets may need to be centralized in order to maximize scarce talent.
Proximity and accessibility of expertise and responsiveness: Having access to staff with skills and the ability to respond is very helpful and effective for the institution. Local operations know and understand their data and their processes. Centralized operations may not know and understand with the same depth as local staff. Decentralized staff may be able to provide expert assistance in a timely way.
We can gain efficiencies through centralization, but the specialized effectiveness and service and shared priorities are better served with decentralization.
The Advantages of Centralization
The centralization of IT within an institution offers many advantages at both strategic and operational levels. Centralization facilitates an enterprise approach to the provision of IT infrastructure, systems, and services rather than a fragmented, localized approach. It can deliver benefits not only in terms of technology, people, and processes but also in terms of services to students and staff.
At the strategic level, one of the main advantages of centralization relates to the extent to which IT can be aligned with, and support, institutional priorities. In a centralized model where organizational responsibility for all IT rests within one area, it is easier to ensure that IT plans are tightly integrated with the institution's top-level plans and that this alignment cascades through all layers of IT planning, including roadmaps and operational plans. In an era where one of the CIO's greatest challenges is to demonstrate how IT can contribute to the achievement of the institution's strategic priorities, the more coherent and integrated the planning and resultant plans, the better.
A second major advantage of centralization is that of cost-effectiveness. The more centralized the approach, the more likely it is that technology will be standardized across the institution, with single enterprise systems for major applications, which can include not only business systems, e-mail, and the learning management system but also file and print services and specialized high-performance computing.
Economies of scale are also magnified when IT infrastructure is managed for the whole institution rather than many parts of it. Not only is it easier to avoid duplication of systems, but technologies such as server virtualization and tiered storage can be exploited to the maximum. Centralized procurement, the use of an SOE (Standard Operating Environment) for both staff and student environments, and the life-cycle management of IT equipment are all more efficient in a centralized model.
From the end-users' perspective, centralization can facilitate better service. A single service desk covering all IT support is much more likely in a centralized model and relieves the student or staff member from having to identify where to go for support for a particular system or service. There can also be particular advantages for multi-campus/multi-site institutions. For example, managing student workstations as a single "fleet" across all locations provides great flexibility and consistency for the student. From the institutional perspective, it is possible to monitor utilization levels for the whole fleet and to fine-tune the provision of this infrastructure across all locations.
Centralization also facilitates the adoption of processes such as ITIL (IT Infrastructure Library) in a consistent way across the whole institution, with positive outcomes for services and cost-effectiveness. Likewise, the marketing of services and end-user training can be done in a more coherent way.
A final set of advantages relates to the IT staff. Centralization means more critical mass and therefore greater specialization and opportunity to develop expertise. Career paths are also enhanced in a larger IT department. In fact, the larger the IT department, the more likely it is to provide comprehensive training and development programs, to have multi-skilled staff, and to provide continuity of service.
Central IT: Keeping Up with User Demand?
When the Wall Street Journal columnist Walt Mossberg called the IT departments at large organizations, including colleges and universities, "the most regressive and poisonous force in technology today" (speaking at the Chronicle of Higher Education Presidents Forum this past June), he explained that central IT is unable to meet the needs of the individual. He offered the example of "thin clients": that is, if you want to cater to a self-enabled, free-to-download, creative-minded user, then putting users on thin clients through a central IT server may not be the best solution. However, if you require a locked-down, generic, highly secure environment, then a central IT server will be exactly what you need. Mossberg's point was that most large central IT groups do not keep up with users' demand for new and innovative services.
A typical response to Mossberg's argument is the line of reasoning within many colleges and universities: that decentralized departments are needed to keep up with the unique demands in the separate departments. But I would argue that today the issue is not about centralized and decentralized IT; rather, it is about partnering with the "ultimate" decentralized IT staff member—the individual user. Students, and consumers in general, now have an expectation of unlimited choice. As Chris Anderson explains in The Long Tail, the economics of variety and niche supply are now favorable as the cost to provide searchable abundance online diminishes. The future challenge for higher education institutions will be to assemble and maintain an infrastructure in which the content suppliers and the student consumers can coexist without constantly changing the underlying systems while still delivering exactly what the student wants. Diana Oblinger's discussions on balancing agility and stability in higher education amplify Anderson's observations. She explains: "Information technology has catalyzed the creation of new forms of communication, self-expression, and collaboration. Social networking, podcasting, and videoblogging exemplify a do-it-yourself culture where peer-to-peer, multi-modal communication challenges traditional text-based, authoritative channels."1 If this is the expectation, then one might argue that this is the environment that central IT should be building.
It is not that central IT cannot supply individualized services; it is that the current IT responsibilities are broad and deep. In the face of regulation, funding, and liability, central IT must meet many other expectations. As an example, one can look at the EDUCAUSE top-ten IT issues list for 2007.2 These challenges are extremely important, but they don't exactly correlate with innovation or with individuals. In fact, one needs to read down to number six before finding the word faculty and on down to number nine before seeing learning.
At a college or university, the central administration is much less likely to ask the IT department, "Can you make a user environment that fosters personal creative exploration and innovation?" than "Can you save some money next year?" Central IT is not regressive; central IT staff are focused on what the institution has asked them to do. Thus, in the do-it-yourself world of unlimited choice, is it the IT department that is regressive, or is it the institution itself? Colleges and universities offer choice—but not unlimited choice. Consequently, this is how IT departments are set up. If the institution adapted offerings and learning styles for every academic program, not just for a few innovative professors, then central IT would revise itself to meet this challenge.
Central IT can meet the needs of the individual. After all, someone is running MySpace and Second Life. However, these are individual applications, and our challenge in higher education institutions today is to integrate the needs of the do-it-yourselfer with the mandates of stability and compliance. Creating a nurturing environment for individual personal expression along with academic choice is our next IT concern, and it might just be part of the top-ten IT issues list in the near future.
1. Diana Oblinger, "Balancing Agility and Stability in Higher Education," presentation at Connectivism Online Conference, University of Manitoba, Winnipeg, February 6, 2007.
2. John S. Camp, Peter B. DeBlois, and the 2007 EDUCAUSE Current Issues Committee, "Top-Ten IT Issues, 2007," EDUCAUSE Review, vol. 42, no. 3 (May/June 2007): 12–33, http://www.educause.edu/er/erm07/erm0730.asp.
Restraints on IT Support of Academics
Central IT, with its competing priorities, faces a number of restraints when it comes to supporting faculty and their personalized use of computing. First, IT shops have to support all faculty, not just the innovators. Many faculty know how to use the technology systems on campus and what they need for the classroom, but they don't like to spend a lot of time troubleshooting problems. And when a system doesn't work, they are in a stressful bind. The IT organization's foremost goal for faculty should be to make sure that the technology in their classrooms is working.
Another restraint is the fact that, over the past few decades, IT organizations have been spending more and more resources on the business of our campuses, often at the expense of academic technologies. We bolstered all our systems to accommodate Y2K. Many colleges and universities replaced aging legacy systems that managed admissions, registration, financial aid, billing, grading, and transcripts with new, Web-based ERP systems and added new financial and human resource systems. All of these state-of-the-art systems are necessary for conducting the business and managing the data of the institution, yet they consume IT resources. They also have to be upgraded routinely, meaning that the institution has to plan for, implement, and roll out major system upgrades, again consuming many resources.
IT organizations are also experiencing a phenomenon that is becoming more acute with each national disaster. For example, after Hurricane Katrina, we all pulled out our disaster-recovery plans and found that we needed more redundancy, more off-site processing and storage, more failover. This is especially true since our systems are now considered mission-critical. But those initiatives cost a lot of money. Likewise, after the Virginia Tech shooting incident, we are suddenly installing siren systems, redundant phones, and text alert messaging systems.
In addition, we manage our networks with more and more sophisticated tools to keep some traffic constricted (peer-to-peer file sharing) and to authenticate wireless users. Everyone wants wireless everywhere. We need to know who is connected, to what resources, and for how long. Efforts in this area—identity management—have become paramount.
We also have CSOs (chief security officers) who, often based in IT, have broad responsibilities to make sure that everyone is educated about FERPA, Gramm-Leach-Bliley, the Freedom of Information Act, and CALEA. This job didn't exist five years ago, yet now it has an essential, powerful role on campus. CSOs are necessary on several fronts, but mostly to avoid costly liability if confidential or sensitive data is leaked.
Nevertheless, most IT organizations still maintain academic technology as core to what we do. For example, we are melding IT services with libraries to build "learning commons." With needs changing around the way students and faculty use the libraries, juxtaposing library reference experts with technology support and multimedia specialists simply makes sense. If we can get past the cultural barriers, this model has significant potential to elevate our services to academics.
But there is also another, more subtle trend occurring. As new faculty arrive on campus, they are more sophisticated in their use of technologies. They don't need help navigating our systems; rather, they point and click. It used to be that we held workshops on using word processors, but no more. That is an expected skill. The same is happening now with the personal computer (and the cell phone, the digital camera, the iPod, etc.). If someone wants to use those tools, they jump in and learn how. Many assume their own responsibility for learning new technologies.
The IT shop should be working with these faculty innovators on using technology to deliver information and conduct dialogues and engage with students in new ways. We should be working to support academics in their use of personalized computing—regardless of the restraints.
Fostering Innovation in an Enterprise Environment
The balancing point of today's college and university IT leadership challenge is centered on the spectrum between facilitating personal IT innovation at one end and providing enterprise IT services at the other end, between individualism (i.e., "personal choice") and institutionalism (i.e., "public utility"). In the terms of the Gartner "Hype Cycle," students and faculty are often present at or are themselves the "technology triggers" who then fan the flames of "inflated expectations" while CIOs try to shepherd ideas from the "trough of disillusionment" to become productive and reliable systems that the entire community can depend on for services.1
In the past, colleges and universities have frequently discussed service delivery models that range from academic-centered (innovation) to administrative-centered (production), often resulting in multiple organizations and sometimes in conflicting reporting relationships. Just as technology continues to change rapidly, IT leadership titles and reporting structures are also changing.2 Nevertheless, many IT organizations have not embraced change and have been slow to transform the way they do business.
Rather than focus on centralization versus decentralization, academic versus administrative, or best organizational models, I prefer to focus on the effective delivery of IT services over a continuum of technology "innovation." On one end of the continuum are the individual initiatives that form the heart of the academic, intellectual enterprise; at the other end are the mundane, enterprise IT initiatives that are core to today's college and university business.
Individual IT initiatives are often unique and innovative. Their sponsors have a sense of personal ownership and emotional investment. The projects may have limited reliability, scalability, and security. Such projects also likely have little campus-wide impact and are seldom integrated with other campus systems. Using Gartner's Hype Cycle as a reference point, we would see applications such as e-portfolios, open-source e-learning applications, social networks and tagging, and wikis as products and tools based on individual initiative and choice and far from the institutional "plateau of productivity."
On the other hand, as the result of an institutional decision, college and university enterprise IT applications are seldom innovative, they have fragmented ownership, they must be reliable, scalable, and secure, they must be integrated with other college/university systems, and they must always have campus-wide impact. Examples of these systems are core productivity applications such as finance, human resources, student information, portal, library, and learning management.
At Drexel, we realize that there are dozens of innovative IT applications knocking at the enterprise door. The challenge is how we can facilitate letting them in. Applications such as online file-sharing, blogging, social tagging, IM and chat, wikis, social networks, and massively multiplayer online role-playing games (MMORPGs) are an integral part of the daily IT experience for many faculty and students. For example, some of the top-ten e-learning tools identified by Jane Hart are del.icio.us, Skype, Google Search, WordPress, and Gmail.3 IT leaders who fail to recognize and facilitate use of these third-party applications and who insist on being the only source of institutional technology will find themselves in an uphill battle. (Why would an institution provide student e-mail, dorm phone service, or modem pools today—or wireless service five years from now?)
Drexel has long been a provider of services—from complete ERP systems to learning management and other academic applications—to schools across the United States and the United Kingdom. At the same time, Drexel also sees itself as a consumer of hosted third-party applications. At Drexel we have been fortunate, working with our faculty Computer Advisory Committee, to recognize the desirability, easy availability, and choice of dozens of rich third-party tools that may have applicability to the learning environment (and sometimes also to the administrative environment, e.g. Expedia.com). Rather than resist the use of such applications or insist that they must be run in-house, we have embraced and will facilitate their use in what we describe as an always-beta "sandbox" environment. (Please direct your praise of and complaints about production use of pre-release software services to Google.)
Setting service-level expectations in such an environment is critical. Faculty can now take on the role of experimenters and innovators in a nonproduction environment while the IT organization assumes the additional role of working with the many third-party vendors to streamline use (i.e., eliminate the administrative burden) and improve access to the sandbox environment. Over time, some sandboxed tools will no doubt transition to the boring, enterprise-supported environment, and some will instead disappear. But we can be assured that many new ones will pop up on the horizon.
1. See "Understanding Hype Cycles," http://www.gartner.com/pages/story.php.id.8795.s.8.jsp.
2. For example, the Chief Information Officer (CIO) has emerged as a common academic job title, with 72 percent of CIOs reporting to their president, CFO, or other nonacademic position (2006 Campus Computing Survey, http://www.campuscomputing.net).
3. "Top 10 E-Learning Tools," Wired Campus, August 2, 2007, http://chronicle.com/wiredcampus/index.php?id=2274.
© 2007 John A. Bielec
The Tendency to Gradualism
Walt Mossberg's recent comments have inspired CIOs to challenge his accusations of a poisonous plot to stifle creativity and innovation. He asserted that large—and, often, complex—organizations select technology systems for the convenience of the IT organization, not necessarily to meet the changing and diverse needs of the students, faculty, and staff who embrace new technologies, many doing so with such excitement and fervor that they will endure an early-morning Menlo Park breeze while standing in line in front of an Apple store in pursuit of the most recent object of their desire, an iPhone.
We may disagree about the accusation of convenience, but Mossberg is right about our tendency toward gradualism. Many IT organizations react to change with caution, hesitation, and deference to standards or measures, resulting in the gradual or scaffolded adoption of a new technology. We often reduce decisions to vendor choices, or we use support strategies to guide decisions instead of well-articulated adoption strategies (or "business needs"). Many organizations have chosen to centralize IT operations to pursue efficiencies and outcomes that establish baseline services, and then we struggle to adopt meaningful measures of our success. In turn, many CIOs internally market the overwhelming majority of operations as "commodity" IT operations in order to secure utility-like funding or to remedy past flaws in services. Would college and university presidents advocate for and fund non-utility IT projects and services? We think about our systems in the long term so as not to completely disrupt the organization as we introduce the new and improved.
Many IT organizations—large and small—feel the pull from the center to reduce costs, manage expectations, and deliver our services as efficiently as possible. Yet while the center draws us toward common practices and single solutions, the diversity of systems is also a critical issue. The market continues to deliver increasingly complex Web services and appliances that work outside of higher education's basic technology infrastructures. The constant flow of new technology into the hands of students and employees alike can create a landscape of opportunities and failures for most CIOs. We slow down or accelerate the introduction of new solutions that are aligned to campus culture and requirements to improve and/or extend our service portfolios. After all, it's the service that students, faculty, and staff desire. "How quickly can I get help?" "I need software installed to complete a work assignment." "My grant is due tomorrow—send someone out now to update my computer." It is the service orientation of the IT organization, not the organizational structure, that can create problems with users and raise concerns for presidents.
Few institutions consider expending "base plus" or added resources to augment IT operations or services. Without clear expectations and established practices in hand to continually inform and deliver operations to an institution, the pressure for performance and accountability resides in IT. Quick responses, clear communication strategies, and established practices by IT build confidence within our community of users. Unfortunately, few systematic changes are accomplished when all resources are pulled to resolve short-term problems. In this scenario, few IT organizations can provide the strategic advice and direction needed to help the institution to compete.
The key is keeping a focus on the long term. Perhaps it is exactly our tendency to gradualism, criticized by Mossberg, that enables college and university IT organizations to provide consistent service to the institution. The tension between IT as a long-term, collaborative utility and IT as a short-term, innovative change agent provides us with the platform and momentum we need in order to contribute in an increasingly competitive higher education marketplace.
Central IT Faces Web 2.0
In a recent EDUCAUSE Review column, I asked: "How will enterprise IT folks (like me) balance the emerging demands for these tools, which fall into the broadly named realm of Web 2.0, against the need for central IT leaders to assert an appropriate amount of control, reliability, and security? It's a problem that predates Web 2.0. The community of chief information officers (CIOs) has often been seen as a barrier to the impulse for collaboration and innovation. So, how can IT now be a partner and support the innovation that these new collaborative tools enable and still fulfill its basic responsibilities?"1
I think the Web 2.0 debate on campus is where the proverbial rubber hits the road. By "Web 2.0," I mean the broad class of collaborative services whose DNA is explicitly meant to obviate the need for central decision-making and control. Web 2.0 marks an important moment in the evolution of the Internet and of the IT revolution. For those of us with gray hair, it is the software application tool version of the last "great debate"—the one over surrendering control of the mainframe computer in favor of personal computing.
The forces of consumerization associated with Web 2.0 are immutable. Central IT can brace itself for a civil war, or central IT can get out in front of the curve. In higher education, we need to demonstrate our thought leadership, our organizational agility, and our willingness to keep our customers' needs front and center in what will be a hybrid and converged set of offerings using centrally enabled platforms and tool sets, along with applications that will continuously and ineluctably move to the edge and closer to the individual customer/student/faculty/staff.
This is not a debate over dollars. It is not even an issue of efficiency. Security is a necessary but insufficient condition and needs to be contextualized to the realities of our environment. To be sure, resources, operational excellence, and economies of scale are important. But if we mistake the Web 2.0 phase of the IT revolution for the "old" debate over centralization versus decentralization, we are missing the opportunity to bring enormous value to our students, faculty, and staff colleagues.
The colleges and universities that distinguish themselves in the next twenty-five years will be those that make the shift now to enable mass collaboration and that embrace consumerization of the application- and presentation-layer environments. Twenty-five years from now, this issue will be moot. Yet today, many of the debating points that were offered during the historic shift from mainframe computing to personal computing are being resuscitated by some of us in college and university central IT organizations. We do so at our own peril.
1. Lev Gonick, "Open-Source IT Leadership for Web 2.0," EDUCAUSE Review, vol. 42, no. 5 (September/October 2007): 80, http://www.educause.edu/er/erm07/erm0758.asp.
A New IT Services Model Based on Demand and Supply
Perhaps the time is right to consider a different paradigm for the efficient delivery of campus IT services—a model based not on the question of centralized or decentralized services but rather on hybrid solutions that are framed in terms of demand and supply. For the last decade, CIOs have worked hard to rectify the costly overruns created by the client server and ERP era. Rather than focusing solely on technology, savvy CIOs have invested in program office functions to bolster project-management skills and have staffed their organizations with business-process experts to work with technologists to deliver solutions that address well-defined needs. These new functions, combined with the changes in how technology can be delivered, have presented an opportunity for reconception: rather than being viewed as a delivery silo, the central IT organization can present itself as a solutions facilitator that aggregates common demands and matches them with the most effective IT supply to deliver value to both departmental and central needs.
Understanding IT demand involves more than just gathering advanced requirements. IT demand organizations require expert business-process analysts who have proficiency in appropriate domains and who also have a deep knowledge of the key drivers that affect designs including security, policy, architecture, and regulatory compliance. With a well-designed program office serving as the steward of technology strategic (demand) planning, a demand organization then needs campus-wide IT governance to prioritize its technology investments and coordinate selected projects through appropriate incentives and oversight. The demand function focuses not on addressing specific tactical project issues but rather on establishing and maintaining the overall technology portfolio so that it can best meet the needs of the broader campus community. This approach improves forecasting and predictability in solutions delivery and minimizes the risk that multiple solutions will be developed to address the same need. At Berkeley, IT demand is represented by a cluster of central functions that report to the CIO and that coordinate campus-wide departmental constituencies with similar needs through an Associate CIO program.
The supply side of the mature IT organization is where even more dynamic change is taking place. Old models that pitted internally developed solutions against purchased products, or that positioned centrally supported efforts against departmental solutions, are quickly being replaced by a vast array of options that can be blended to meet demand. Applications development, databases, infrastructure, systems, and services are now available with a click of the mouse from across the campus or around the world. The modern IT supply organization must identify how to ensure that these services are provided as safely, effectively, and efficiently as possible—regardless of the supplier. Even though many IT professionals are anxious about these changes and in some cases perceive them as threats to be managed and controlled, others are already embracing the opportunities and flexibility that the new supply model offers.
The modern IT supply organization must evaluate the true core differentiators for the institution and must focus on how best to provide them. Today, if a solution can be provided over the Web at compellingly low cost, what role should campus IT departments take in guiding the decisions regarding those solutions? Departmental collaborations must be encouraged, and interinstitutional solutions (e.g., uPortal, Sakai, and Kuali) should be embraced for the value and leverage they can bring. At the same time, a retooling of the IT supply skill set will be necessary to ensure that campus IT departments not only can build and run the best solutions when needed but also can make the tough decisions about what not to build and run but rather to provide through partnerships.
The era of monolithic centralized IT control via the mainframe has passed. The confusion and duplication brought about by a decentralized model can no longer be sustained in today's world of ever-shrinking resources. The time of individual empowerment through the democratization of technology is upon us. So what's it going to be at your institution: struggling to maintain control while doing it all, or embracing IT's future using the demand and supply organizational model? If you don't think you need to decide now, just ask yourself how long it will be before students are mashing up applications using your data to optimize the value of their new iPhones. Aspirin, anyone?
Research Technologies: Edge, Leverage, and Trust
Conventional wisdom asserts that real innovation happens at the edge of an organization and that leverage (i.e., efficiencies) occurs near the center. If so, what is the most efficacious path for research-intensive institutions to provision research IT? Expensive and ever-changing high-performance computing (HPC), massive data-storage systems, visualization tools, specialty software, and other "Research Technologies" (RT) are essential components for many scholarly endeavors, from the life sciences to cultural preservation. These tools and the services to train users and to support, integrate, secure, and evolve these systems over time represent a critical investment for modern scholarship.
There are two central conundrums that shape the raging debates regarding the configuration of leveraged and edge services for RT. The first conundrum is deciding what RT make up the essential campus cyberinfrastructure for any and all academic pursuits. Should faculty in the performing arts get access to the campus Internet, or is the campus Internet only for the natural sciences faculty who bring in the multimillion-dollar NSF grants? This question is silly, of course, since we long ago chose to fund and provision network access to all faculty, staff, and students as common infrastructure. As such, the Internet has become a common tool that enables a variety of scholarly research and is provisioned at a reduced overall cost. On the other hand, should we site-license and pay for SPSS statistics software for every faculty member, staff, and student as common infrastructure? No, probably not, since some humanities faculty may have no need for it, but we might negotiate a discounted campus price that is a better value than single, ad-hoc purchases. What about computing cycles on HPC systems and the staff to support research uses? Should that be common infrastructure for any researcher, or should it be cost-recovered only from those with funds? Alternatively, should each researcher or team buy and operate its own systems at the edge? The decision for each of these examples reveals an institution's philosophy—sometimes tacit—for providing the tools of modern scholarship. There is no right answer, and the choice should fit the values of a particular institution, but the choice may enable or constrain scholarly research productivity.
The second conundrum is the pervasive chicken-and-egg problem of money and capability. Even if institutions decide that a massive file system with petabytes of storage and consulting staff should be provided as a leveraged cyberinfrastructure resource, there is no immediate and obvious path for achieving the large budget to do so. For many institutions, the money to fund RT is fragmented in sponsored research grants, academic departments, and schools—essentially at the edge. Even when researchers have grown weary of the growing challenges of operating their own HPC environments (e.g., power, space, air conditioning, security, patching, staff) and are willing to help fund and use leveraged services, they often cannot take the risk of doing so until there is a track record of trustworthy leveraged RT services. For IT leaders, provisioning trustworthy RT services requires buying expensive equipment, ensuring its life-cycle funding for replacement (it will become obsolete), hiring qualified technical staff to manage the equipment, and developing an informed service-oriented group of staff who have academic discipline domain knowledge. All of this is very expensive and requires time to evolve into trustworthy services, thus further impeding the ability to generate trust and engagement among the researchers.
There are evolutionary and revolutionary paths through these conundrums, and a substantial discussion of campus cyberinfrastructure may seem implausible until there is some record of trustworthy RT services. For most IT leaders, the evolutionary path necessitates developing personal trust. Fostering sustained engagement with researchers and attending relevant RT conferences (e.g., SC or TeraGrid), funding agency workshops, and/or academic discipline meetings can help sensitize IT leaders to RT trends as part of developing this trust. In addition, small successes are essential, even if they only help individual researchers get better prices on their equipment or space. As those in the humanities evolve their use of more advanced RT, there may be exceptional opportunities for IT leaders to meet the RT needs of these disciplines. Personal trust and success with a few projects form the foundation for engaging a broader campus cyberinfrastructure conversation and rationalizing its funding. Aggressive partnering with multiple projects and disciplines can develop early signs of where leveraged services may be valuable.
In some rare cases, and usually following trust-building evolution, high-level administration may accelerate a revolution in provisioning RT. There are growing reasons why institutions may be ripe for high-level intervention that will substantially alter the path for RT funding and services. Again, however, trustworthy evolution is a desired antecedent.
For CIOs, the ultimate answer is to have a preponderance of neither edge nor leverage; rather, it is to earn a position of trust as a core contributor to a range of scholarly endeavors. In a climate of trust, RT funding and sourcing--whether at the edge or pooled for leverage—can sort itself effectively. In an absence of trust, both options seem almost insurmountable.
The Strategic Role of Lunch
The U.S. Military Academy is a highly centralized organization: an end-of-career superintendent manages a largely transient faculty and a hierarchical administration. Harvard, in contrast, is a highly decentralized organization: a president nudges and coaxes deans, who control most of the resources and who in turn nudge and coax department heads and faculty, who enjoy substantial autonomy. Like most other colleges and universities, the University of Chicago operates between these extremes—or, more typically and problematically, tries to combine the two. The budget process is centralized, for example, but its product is a set of formulas outlining boundaries within which deans and vice presidents have great freedom. Similarly, the university claims to have centralized telecommunications procurement, but somehow cell phones aren't included. Even faculty hiring has both centralized and decentralized components, causing occasional tension between department heads and the provost's office. Confusion results, especially regarding the processes for setting priorities, resolving conflicts, and negotiating trade-offs.
Senior leadership groups—an officers group, a deans group, and an executive budget committee—exist to resolve these tensions between decentralized and centralized goals and actions. To the extent that these groups evolve into collaborative teams, they work well for issues of general institutional importance. They work less well for issues that involve only a subset of units: IT and Facilities, with overlapping responsibilities for design and installation; intellectual and administrative units, with divergent goals for student life; or pairs of academic departments, with a need to exploit synergies. So I—like other vice presidents, as well as deans and colleagues—have lots of lunches at the Quadrangle Club, the standard place for University of Chicago administrators and faculty to conduct lunch meetings.
For those of us with sedentary habits and no willpower, lunch can be a problem. That's especially true for me, since the Quad Club makes a delicious BLT wrap, which is in effect a handful of garnished bacon only minimally buffered by a thin wrapper—and I love bacon. Ordinarily, mindful of my waistline, I'd try to avoid Quad Club lunches. But who has lunch with whom—and, sometimes more important, who sees whom having lunch with whom and stops by the table—is very important to the university's functioning. An aggregation of dyadic administrative lunches helps us behave as though we are centralized, even as each of us jealously guards his or her decentralized authority. Our lunches don't turn into negotiating sessions, and only rarely do concrete decisions emerge from them. Rather, lunches give us the opportunity to share thoughts, experiences, perspectives, enthusiasm, paranoia, gossip—the informal information about one another that enables us to negotiate, collaborate, complain, and respond appropriately when our domains do or should engage one another.
This coming year promises to be challenging at the university: an ambitious president, lots of new vice presidents, currents of organizational and cultural change, and many trade-offs to be negotiated. Some of these challenges will call for more centralization and others for more decentralization. Some will necessitate a lunch. In this, I think, we are typical. Bacon is good.
Déjà Vu All Over Again
Walt Mossberg's recent comments about the "regressive and poisonous" IT departments at large organizations had the familiar, bucolic-interruptus feel that Nicholas Carr's writing produced back in 2003. I felt once again as if the clock radio had snapped to 6:00 a.m. and "I've Got You Babe" was waking me to yet another day in which my very existence would be questioned. These days, about all I think I can really count on is that—regardless of what is said here in this collection of op-eds—sometime (hopefully not until 2011), some pundit will again question our existence. I believe that's as sure a thing as Richard Katz being jovial the next time I see him.
So I don't want to talk about why we exist, nor do I want to debate any point made by whichever Whatshisname has most recently questioned our existence. I want to talk about why it is we would even care and, more important, what we would have to do to not care about these occasional bits of intellectual jetsam that wash onto our CIO shores. To paraphrase a line from The Right Stuff: the issue here isn't about poisonous; the issue here is about relationships. And the first relationship in question is the one between CIOs and campus CEOs.
How important to a CIO is a good relationship with the campus CEO (chancellor, president, provost)? The answer: very important, especially if the CIO wants to be able to view these occasional Scuds from afar as having nothing more than entertainment value. I laud and am grateful to CIOs, EDUCAUSE, and others in our industry who provide eloquent responses and fact-documented counterpoints to the negative positions and opinions. But at the end of the day, how much we CIOs care about a publicly proclaimed negative opinion is likely related directly to what happens when the boss reads or hears about it: does the CEO shake his or her head, or does he or she instead nod and have a "hmmm . . . that's very interesting" response?
If a CIO is positioned—organizationally—to have quality time with the campus leader, then the CIO will have ample opportunity to, through direct communication, work on building a relationship that is bulletproof. However, those CIOs who don't report to the CEO, who don't sit in the executive cabinets in some fashion, or who don't have a communicative relationship with their CEO are the ones who are more apt to get stung by the slings and arrows of those who seek to deliver outrageous fortunes upon us. I know that as CIOs, we don't control the reporting structure, or the quality of our relationship with the institution's top leader, or whether we even get to see the CEO at all. Still, whenever we can, we should seek to enable that communication, so that when CEOs read these things, they will discuss them with us or, perhaps, simply turn their attention to the next story in the paper.
But perhaps there is a better way, one not so dependent on the relationship the CIO might (or might not) have with the CEO. As a CIO, how do you make sure that your campus community understands your decisions with respect to the use of IT? The answer: by communicating with and building a rapport with the members of this community. In fact, the relationship we CIOs have with our campus community—our constituency—is even more critical than the one we have with our campus leaders. In a great many instances CIOs who do not communicate well with others on campus (deans, faculty, students, staff) end up in trouble, more often than those CIOs who simply fall out of favor with the CEO. I won't deny that there are capricious CEOs—but they are few, and we shouldn't plan our lives around them.
So whereas having a good relationship with your CEO is one way to not care who says what about the profession and about IT on campus, perhaps the best way is to have a good relationship with the campus community and with those who report to the CEO. Because even though you may not report directly to the CEO, many other people most certainly do. And if they see value in the IT environment that you deliver and support, you can bet they'll be telling the CEO that ol' Whatshisname who just took a potshot at IT is—how shall I say this?—full of malarkey.
Addressing the Cause, not the Symptom
Thinking about Walt Mossberg's assessment that the IT departments at large organizations are "the most regressive and poisonous force in technology today" leads to a compelling corollary question: if an IT organization is dysfunctional or obstructionist and shows no signs of becoming better, why would a president allow the situation to continue to fester?
IT organizations are creatures of the institutions that create and sustain them; they don't exist in a vacuum. Colleges and universities generally get the IT leadership, support, and service they deserve. Even when things go so badly that the CIO is dismissed, it is the president who is left behind to bear the ultimate responsibility for remediation of organizational failure.
Let's face it: if there were a proven, one-size-fits-all IT model for delivering innovation and consistently high levels of service to our colleges and universities, we would embrace it en masse. Thus, in our continued search for this Holy Grail of IT organization, we come to the centralized-versus-decentralized issue. The trouble here is that most debates about the effectiveness of centralized-versus-decentralized IT organizational structures seem to focus on obvious symptoms while barely nibbling at the edges of the question of root causes. Mossberg, for example, cited the failure to embrace technological innovation as a flaw in central IT organizations. That's a symptom, not a cause, of a larger problem.
So, if simply tinkering with organizational structure—attempting to address symptoms—isn't entirely the answer, what do we say to a president who's been told by a famous technology columnist that the campus IT shop is a blight on the institutional landscape?
First, let's look at the audience. The average age of presidents is sixty. Almost half are over sixty, and only about 8 percent are fifty or younger.1 With some notable exceptions, the average president completed graduate studies, developed a scholarly or research agenda, and earned tenure at a time when the modern age of IT was in its infancy. Although the average president may be an adept user of technology—especially for communications—the visceral feel for technology that seems to be part of the DNA of today's students and younger faculty and staff is often missing among college and university presidents. Substantive conversations about technology sometimes make them uncomfortable, because they think they don't know enough about the topic.
But they do. And IT leaders would do themselves and their institutions a big favor by reminding presidents of that fact. As observers of other users and as users themselves, most presidents are sufficiently immersed in cyberculture to pose many intelligent variations on a single question: how will our investments in people and systems make life better for faculty, students, and staff and improve the institution?
Here's an easy variation that any president can pose. How often does it take more than two hours to respond to a faculty member's call for help? The answer could spawn all sorts of fascinating conversations about staffing, help desks, metrics and monitoring, research and instructional support strategies, training, infrastructure issues, and yes, even the issue of distribution of resources. Does the responsibility for responding to the faculty member's call reside with central IT or with the academic unit's IT staff?
Simple questions from presidents can make a huge difference. Suppose a president wants to see quarterly data showing progress toward the goal of a 100 percent rate of response to faculty calls within two hours. The mere request from the president establishes this as a very specific—and measurable—priority. Reviewing the quarterly reports could lead to meaningful, data-based dialogue. And the mark of success is unambiguous: 100 percent response within two hours. The IT organization will know when it has done a good job. A handful of other carefully chosen questions posed by a president could refocus attention across an organization in very short order.
For me, Mossberg's assertion recalls a cartoon I saw years ago. An enraged owner stands over his pet, shaking his finger and shouting, "Bad dog!" The chastened mutt looks up mournfully at his master with a thought-bubble floating over his head: "Could you be more specific?" More specificity—that's exactly what I'd like from our presidents. With specificity, we can address the cause, not the symptoms, of our problems.
1. Audrey Williams June, "Presidents: Same Look, Different Decade," Chronicle of Higher Education, February 16, 2007.
IT Matters: Centralization or Decentralization May Not!
The debate over the comparative merits of centralization and decentralization of power, authority, decisions, and services in higher education is a perennial one. It is also an important one because it masks two defining pressures of the modern university: the pressure to innovate and the pressure to economize. I am fascinated with the topic because I cut my teeth at the University of California system and had the chance to swap views on this issue with Clark Kerr and other "giants" at that great university. Kerr wrote about decentralization and centralization in the 1960s (and beyond) and engineered much of the overall decentralized architecture of UC. For many of us, the debate about centralization or decentralization is academic—a larger artifact of the institutions whose resources we steward. I think Shel Waggener is right: the essential debate needs to be about service quality and costs. It is no longer a question of centralization or decentralization but, rather, of centralization and decentralization.
There is a deep literature that makes the case that on balance, decentralized approaches are best suited to organizations where innovation is the primary objective, whereas centralization is best where efficiency (capturing economies of scale and scope) is paramount. Like pharmaceutical companies and other R&D-intensive organizations, colleges and universities are hybrids; polarizing the choices of management approaches to either A (centralization) or B (decentralization) is bound to get us down the wrong path. Although it is essential that we operate cost-effective business environments, it is fair to say that no one ever won a Nobel Prize for the most efficient research.
The interesting challenge for us is whether or not we can now organize (as distinct from create and operate) compelling services centrally whose service attributes, performance, and even governance look and feel local. Isn't this challenge a variation on C. J. Date's famous dictum: "To the user, a distributed system should look exactly like a nondistributed system"?1 Can we and our partners in academic units and increasingly outside the institution organize our services in ways that "feel" tailored (e.g., local) but that produce the controls (e.g., security, privacy, transparency) and economics that come with centralization? Technologies like server virtualization are giving me a lot of hope that we can. But this challenge changes the discussion—to one about where and when and how we can centralize, which is a rich arena for discussion.
I think that the glue (in our world) that will make it possible for us to create rich hybrid services that balance the institution's need to innovate with its need to economize and account for outcomes will be IT governance. Even when the technologies are all there to create this service environment, the issue comes down to trust. Do the consumers of IT services (local and central) trust the services and the service providers? Indeed, it has been said that trust is the residue of promises kept. In the history of campus computing, we need to acknowledge that our track record at keeping promises is spotty.
At the end of the day, our faculty and our students aren't so different from us. If they (or we) believe service to be insufficient or don't like the service provider, they (or we) will go elsewhere. That's not because they are malicious or are not "team players." Mostly it is because they have a job to do, and they want to do a great job. And I don't think we want to either erode that impulse in our cultures or foreclose customers' service options without giving this deep thought. In any case, as more and more services are offered "in the cloud," it will get harder and harder to fight this impulse. Again, as Shel Waggener suggests, what is emerging in the "software-as-service" model is really a metaphor about "services-as-market." Supply, demand, timeliness, performance, and cost are likely to define the service architectures of our institutions more than we will.
I hope that our discussion of centralization and decentralization will morph before long into conversations about: (1) how to build trust in mixed organizations; (2) how to create virtualized services that operate centrally yet behave locally; (3) how to demonstrate the academy's performance goals and IT's contribution to them; and (4) how to factor the emergence of services "in the cloud" (library, e-mail, etc.) into our thinking.
Demonstrating IT's contribution to institutional performance is gigantic—bigger than our IT community. But it seems to me to be at the heart of the matter. This is why Carr and Mossberg strike a nerve with us. One of the dirty little secrets of higher education is that great discovery and great teaching are not always efficiency-seeking activities. If they were, we'd simply teach in our football stadiums (kidding!) or outsource our research. I think that we need to balance the self-evident (but unpalatable) truth that these activities are not efficiency-seeking with the fact that there are real economic limits facing us. We simply cannot—politically and morally—use the "we are not efficiency-seeking" argument to rationalize waste and abuse. I cannot underscore this last point firmly enough.
So, any answer to the centralization-decentralization question will be complicated, and we have to convey this complexity to our colleagues in the press and to our stakeholders. I don't think that reasonable faculty will object to approaches that lower overhead costs, and I don't think that reasonable trustees, governors, legislators, students, parents, or other stakeholders will object to managing the academy in ways that reflect the fundamental uncertainty of the research endeavor or the fundamental craft nature of teaching and learning. Our job is to keep making the point that we need to do both and to keep building not only the infrastructure but also the trusting environment that will allow us to create the best blend of centralization and decentralization.
1. C. J. Date, An Introduction to Database Systems, 8th ed. (Boston: Pearson/Addison-Wesley, 2004).