Campus communities are by now accustomed to the increasing frequency of new technology introductions. The rapid rate of technological change has in turn created another trend — the need for a governance structure flexible enough to manage the complexities of the ever-changing technology landscape. Berkeley is not alone in transforming our technology governance structure; institutions of higher education around the world are grappling with entirely new models for technology delivery, changes in funding sources, skyrocketing demands for technology in support of research, and universally heightened expectations from the student community for 24x7 access to interactive environments. The changes are forcing all of us to rethink how technology solutions are delivered, who designs and delivers them, how they are funded, how they are managed, and even how they are retired.
What follows below is an article that was originally published in last fall's EDUCAUSE Review (vol. 42, no. 6, November/December 2007). In it I reflect on the challenges a diverse and complex major research university faces in delivering high-quality IT services in a constantly evolving environment. I also provide an overview of the changes we have undertaken at UC Berkeley to meet these challenges: the reorganization of the central IST unit; the creation of an IT governance body, the Campus Technology Council (CTC), and appointment of Associate CIOs representing campus IT needs to the CTC; and the support of a new, activity-based budgeting process for IT to achieve more strategic campus technology investment.
A new IT services model based on demand and supply
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 defining business processes and developing 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.
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 campuswide 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 campuswide 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 inter-institutional solutions development (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? 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 we 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?
© 2007 Shelton M. Waggener