 Okay, so I'm going to talk about the status of IT at Cornell. Some of you may have heard the talk I gave about three years ago on, as we were just being going through our initial crisis and had some talk about that. And so this will give the story since then. So a little bit of it, for those of you who did hear that talk, a little bit of the beginning is going to be review. But much of it will be new. So I'll start with my disclaimer. I am not speaking for Cornell University. I am not Cornell University. These are my personal opinions. We'll start out with a little history of the whole crisis and what happened. So in 2009, like many institutions, we suddenly faced a major financial crisis. Ours was perhaps a little more severe than some. We had turned out to have an operating budget deficit of $130 million a year that we had to fix in a pretty big hurry. So Cornell brought in being consulting to do a high-level review of the administrative budget, including IT. So they looked at purchasing HR, their administrative activities, but I'm just going to focus really on the IT piece here. They identified a bunch of key IT issues in that process. The IT governance was very complex and led to really bad choices and decisions. There was significantly more spent on end user support than they felt was reasonable compared to industry benchmarks. They saw a significant amount of money being spent in applications development maintenance, but people were in fact pretty unhappy with what they were getting from that. And there was the server and storage infrastructure was fragmented across the institution. So by comparing Cornell's IT spend with standard industry metrics, they estimated that the university could save $10 to $13 million a year out of a total administrative savings of $90 million a year that we were seeking. So this was the third highest area of potential savings, and so was a real target of interest to the administration as they tried to fix our financial problems. As everybody knows, crises focus the mind and give you an opportunity to do things differently. It really does create opportunities, although they may be very painful opportunities. We, the folks working in IT for many years at Cornell already knew a number of things. We had a number of independent IT units scattered across the campus. Many of them were very small. The central IT group, CIT's cost recovery models imposed by the institution made central services look very expensive. I mean, they were very expensive. We could typically save money by doing stuff locally rather than relying on the central services. There's no budgetary or governance support, you know, asking people to collaborate and work together. There really wasn't institutional support to help make that happen. And we really saw that if we could break down budgetary and governance barriers, you know, sitting there we realized there were a lot of things we could be doing much better across the institution if we could figure out how to make it happen in a reasonable way. You know, people were sort of comparing the decentralized model versus the centralized model, you know, which is better. In fact, both have their strengths and weaknesses. You want something that's local, that's responsive, that's really accountable to the local departments, not some, you know, distant central organization, and that's locally effective. The downsides of the decentralized piece are it tends to be redundant across the entire institution and more costly. Centralized stuff can be efficient. It provides common support, single enterprise, unresponsive, less accountable, and can be very inflexible. So we were striving for the best of both worlds for coordination among the various parts rather than centralization, where IT is embedded in and reports to the individual units, capability of creating flexible local solutions, particularly important for the library I will say, but have a suite of common Cornell-wide services and infrastructure that we can take advantage of so that we don't have to build everything for the ground up. So our overall three-part solution, there's an IT governance council, small at the high level, the provost, the chief financial officer, an academic representative who happens to be the dean of commuting and information science, and the CIO. That group works together with the CIO to provide coordination and oversight across all IT at the institution, setting aside sponsored research, which is a little bit of a different animal. The central ITU group provides these university level common services and infrastructure, the networks, things like that. The IT service groups provide comprehensive appropriately sized unit level support. So typically these groups are about 25 to 50 people in a service group dealing with a fairly significantly sized unit. So we've gotten away from lots of tiny little small units. So the timeline, in early 2010, the small teams developed IT recommendations, including the recommendation that we create these IT service groups at this sort of scale across the institution. In August, the first IT service groups were created. In January 2011, our new CIO, Ted Dodds, began, got immediately to go around to all the deans and say, I'm cutting your budget by $100,000, which was a challenging way to begin. Through the period 2011 to 2012, there were significant IT budget and staff cuts. And now really in the last year, we've begun to start to achieve some significant progress in governance and user support, applications development, and other areas. So I'll talk through all of those areas and how it's going. So the Bain consulting folks came up with a bunch of recommendations, and I'm going to go through and sort of compare what they offered as suggested solutions and where we wound up. Bain's slides tend to be excessively busy. The only thing I'll sort of ask you to take away from this one is that they saw about two and a half to three and a half million in end user support savings, seven to eight million in application development and maintenance support, and a small amount, half a million to a million. These are all per year in storage and server. So a total of between 10 and 12 and a half million. So where are we, the budget savings, i.e. cuts, being projected these savings, so-called savings. By fiscal year 13 now, Cornell has cut $11 million per year from the IT staff budget. And FYI, 10 staff spend a 77 million a year. So it's pretty significant. The total IT headcount is down by 15% over a fairly short period of time. I'll just say generally compared to what Bain recommended, Cornell has saved more and done more in the area of servers and storage and less in terms of savings from applications development. But some of what happened was just everybody got a budget cut and we've just had to try and do the work with fewer people. I think we're going to get better and I'll talk some about that as I go through as we go along. As we implement these changes, I think we're going to start to see savings as well as just facing cuts and some of that's happening already. So let's start with governance. All sorts of units had all sorts of totally independent IT governance, reporting within to department chairs or deans or other things. It was scattered all over and there was really no significant coordination. So Bain's recommendations were kind of a top-down governance structure with a close review of all IT projects greater than $25,000, very limited exceptions to adopting standard university level services and solutions. So really somewhat of a command and control approach. IT at Cornell, we've strived to put incentives in place so that the right things happen, encouraging transparency at all levels of IT, so it's clear what decisions my IT service group is making to the institution, to all of the rest of the IT. And it's clear what the central IT is doing, what they're charging for, what's going on. And ensure strong communication and collaboration among the service groups and between these IT service groups and the central services. So one of the challenges we faced, I already mentioned the cost issue, the challenges with my service group relying on central services are really threefold. One is the cost. I need to believe that the cost would be similar at least, hopefully lower than doing the same thing myself with local resources. I have to trust that the services will be supported and prioritized based on the needs of my group, not on some central set of priorities or on some other service group around it. If the servers that are running our library management system go down, we need to know that this is a priority for the central organization, not just for us. And we have to have some level of control. We need to believe that those services are sufficiently flexible that when we have clear specialized needs, they can adjust. They can meet the needs that we have. So the main change in governance has been this IT service group directors committee, if you will. Basically the ITST directors cover almost all local IT. There are a few small pockets of exceptions, but essentially we've got about 15 people covering all the local IT across the entire institution. We've been meeting weekly for more than a year with the associate CIO and talking both among ourselves and with the central IT directors. So a typical meeting will involve bringing in a central IT service or several, discussing what's happening in this particular area, how's progress going, getting our feedback, having us talk among ourselves, and to some extent talking with each other and coordinating potential solutions across a couple of IT service groups rather than necessarily relying on central services for everything. So we've got three IT service groups that have a particular need that are now working together as a result of this. So the result of this is services that ideally meet the needs of all these IT service groups. They'll come in and say, well, this is the way we're planning to do it, and we'll say, well, no, wait, realize that if you roll this service out then, you know, we've got midterms going on, this is going to have a serious impact on what's happening in the academic units. You can't do it that way. And, you know, having them be responsive to that, to those needs. So in addition to the sort of IT service group directors meetings, there are some global IT at Cornell initiatives. They're just starting up a broad quality management effort that's focusing at application support and infrastructure, looking really at service quality. We're seeking to free up resources from the more utility administrative applications to better support the academic mission of the institution. And in the sort of partnership and collaborative area, we're working with Internet2Peers and NetPlus to create cloud-based services and solutions for research universities. We're also a partner with Kuali on a number of enterprise-level systems, and most recently the Kuali Mobility Environment for some mobile solutions. So it really is an evolving governance model. Here's the current picture. We're actually sort of in discussions right now whether these advisory committees down here make sense, because really the IT service group directors as a whole has been doing a lot of that function. And we're saying, you know, does it make sense to sort of divide things up, bring in a few more people? Or are we just sort of duplicating things? And really everybody, all the IT SD directors should be involved in everything that's being reviewed at this level anyway. The governance committees are also, these are intended to sort of, bring in dean-level folks, faculty and others to really sort of address more strategic issues with student experience, with teaching and learning, and with administrative systems. So let's look at some of the particular areas starting with end-user support. So Bain recommended that we create economies of scale by clustering resources, that we standardize on a common desktop infrastructure across the entire institution, and that we potentially outsource desktop support to a third-party external provider. So what we have done is created a central service desk, potentially a one-stop starting place, a single phone number, web form, whatever, for anybody with an IT problem anywhere across the institution. That has only been rolled out to one IT service group so far. And interesting experience, they actually need to touch more than 90% of those service tickets locally, but they have still felt that having the initial cut and ticketing done centrally has been worthwhile for them. So they've seen this as a positive thing, even though, as I say, they're doing most of the work at the second level themselves. We've standardized the desktop and support infrastructure, and we have chosen not to do outsourcing. So let's see, I actually got ahead of myself. Central service desk, the first level support for ITSGs and campus community. Common ticketing system, we're now using that on a library. It's been very helpful as we track tickets back and forth with the central organization and follow what's happening. I'm not sure that I would recommend Remedy on Demand as the solution. We're actually reviewing that internally to see if there's a better alternative out there. We just did standardize on a set of small number, about four desktop and laptop PC configurations across the institution. The expectation based on review of past purchases is that this will cover at least 90% of the needs of the campus. However, what they have done is authorized local units, i.e. me, to be able to do any exceptions that we need. So if we have a lab and we look at the standard configuration and we say we need more RAM for this lab we're putting in, we just do it, file it, fold it in to the decision making about what configurations to standardize on in the future. We're working with Dell and we've got a pretty good agreement that is seeing some significant savings across the institution for purchasing. The central group provides managed desktop support. We're doing this sort of light thing where potentially we'll eventually make use of images that they'll provide, but right now we're doing a lot of the support ourselves. And the other thing that's happening is we're looking at cloud solutions for some of our end user provided services. WebEx Office 365, we moved from our local exchange. We had a local exchange solution. We're just finishing a complete move to Office 365, so cloud based email. And so far it's working. Next area, application software services development maintenance and support. So this was probably the most interesting one. It was where Bain had identified the largest amount of IT savings. They recommended several steps here to sort of improve on the current model, share resources, further improve efficiency, and then offshore services. This was in 2010, realize. They said that trends indicate that a lot of people are moving more toward offshoring IT development practices. They identified significant potential savings as part of that. So here was their note. Offshore refers to using lower cost resources in other countries to perform applications development enhancement and maintenance activities. If Cornell chooses not to utilize offshore resources or to utilize vendors, based in the US savings, estimates will need to be adjusted. In fact, adjusted by 2 to 3 million, about 25% of the total IT savings were associated with offshoring with a potential reduction in staff of 75 to 100. Moved to January 2013 and the most recent economist. Here are a couple of quotes. Up until last year, around half of GE's information technology work was being done outside the company, mostly in India. But the company found that it was losing too much technical expertise then its IT department was not responding quickly enough to changing technology needs and they brought it back. Quote, there has been widespread disappointment with outsourcing information technology and the routine back office test that used to be done in-house. Some activities that used to be considered peripheral to a company's profits such as data management are now seen as essential. It's hard not to believe in the current environment that IT is pretty essential to the academic mission of the university. So I would say that Bain made yesterday's recommendations to tomorrow's problems for us. The recommendations cluster resources to eliminate duplication and better deploy resources against university priorities. Utilize lower cost offshore resources to expand capability and increase flexibility of labor pool. So what we've done is we did a complete applications inventory across the entire institution to identify unused and duplicated applications and to see opportunities where potentially we could provide central solutions for redundant individual applications across the institution. We've moved to more standardized cloud-based solutions. Office 365 is an example and others. Where that's been possible. We focused on community source and shared development. I'll talk about some specific areas within the library where we're looking at those solutions. And I think that leverages a lot of the kinds of savings that at least theoretically would have resulted from offshoring. We have selected a temporary IT staff provider, a company called Tech Systems, to support project surge requirements. They can very quickly provide IT staff to meet, you know, as a Java developer. In the library we have a Lua development project. They've identified somebody from Texas and somebody else from Ohio who appears to have the skills we need and to provide that. So this seems like an interesting and flexible alternative to us to sort of surge and unique IT staffing needs. Specific applications development initiatives. I mentioned the application streamlining process. In one case, in the facilities department, they wound up turning off 170 obsolete applications. Turned out they were simply running a whole bunch of old applications so they could get access to data. And in some cases just unnecessarily. And they realized they had much cheaper alternatives available to them. So the applications inventory process across the institution has been a pretty valuable one for us. We've identified some areas where we can potentially coordinate across solutions. But not as many. I think the sort of understanding of what was happening was probably the biggest win there. There is an applications approval process at the 100k level and up for major projects that happens centrally. So for our new library management system, we're putting together the business case and proposal saying here's what we're proposing to do. Use an externally hosted solution. Here's the business case all on one page. It's a pretty lightweight process. And I think useful for, you know, even just among the IT SG directors to know what else is going on. What are other people doing in the way of projects? What are they looking at? There is a new cloud services group in CIT to advise us on technical legal issues for cloud-based applications. They worked with the university council's office to come up with standard boilerplate language for issues like FERPA, software escrow, governing law, all those kinds of things. So when we're looking at coming, you know, as a service group in the library, there are resources for us. If we're looking at a hosted solution, they can provide support for us in helping make sure the right things happen. Okay, servers and storage. Bain's recommendations were fairly simple. Eliminate unnecessary servers and systems. Centralize location and management of servers and storage. We've actually made a major focus on virtualization across the entire institution to get all of these service groups out of the business of running local servers in closets that are not being well maintained and not well supervised. You know, there are the sort of obvious savings that come from more efficient, you know, cooling power and other things in a central virtual machine array. We've got more power. And then there are the kinds of savings where, you know, you don't lose six months' worth of somebody's half-time work because it turns out the RAID system on your server was not being monitored and everything and the backups weren't being done. Nobody bothered to do a test recover from the backups and nobody noticed until the second light went red on the RAID array. So there's significant risk avoidance in using a carefully monitored and well-run central system like that. Let's see. The goal is 80% virtualized across the entire institution. The library is actually now over 80% virtual. We've gotten rid of most of our hosted and local servers. They've set up a new shared file service, a centralized Active Directory. It's been wonderful for us. Again, we've been able to shut down and unplug a bunch of local Windows servers that we were using for shared file service. The cost to the ITSGs for the VMs and storage is below rack space in Amazon. So the way they're doing costing and the kind of incentives they're providing is none of the fixed cost is included in our charges. We only pay the incremental cost of the next VM, the next terabyte of storage. So it suddenly goes from, you know, in a budgetary sense it goes from being a no-brainer to do it ourselves to a no-brainer to use the central system. And that's been a critical change. And then we have some interesting local RID cloud providing on-demand VMs for potentially competing with Amazon. So what about library IT? What's happened within the library? The library used to have two completely independent IT organizations in different unit libraries that did different kinds of things and didn't necessarily cooperate all that well. Individual IT staff were scattered across the library system. The IT units had defined areas of responsibility but there were gaps and overlaps, you know, even just within the library. And the IT units were each a mix of IT-related activities. They would include some desktop support, they would include some software developments, and they'd run some servers, all sorts of different things. So we now have one common organization with, you know, support group, one web development group, one library systems group, one sort of focused project development and then a repository development group. And this also gives you a sense for sort of the scale of our library IT organization. So what's working for the library? The developers now across the library share common web services and web service development, a common code repository and practices. We're now working together on a common discovery and access system in regular sprints that bring together the developers from all across the library and that's worked really well for us, the sort of scrum approach. We've created common service monitoring systems and common configurations running on the central VMs. All the library units now can draw on the expertise of the entire organization, the IT expertise. So I just met with a law library, they want to shift out of their old web services to Drupal. We have Drupal knowledge and capability. They no longer have to do it all themselves, which used to be their model. They can rely on us for those things. And from the library point of view and our point of view, if anyone in the library has an IT problem, we own it. We are responsible for figuring out, working with them, figuring out how to prioritize their problem, how to try to help them get the resources to address it. We've also focused significantly more on partnerships. We have a strong partnership with a central IT group. As I mentioned, growing partnerships with certain of the IT service groups that we work more closely together with or that have common needs with us. We're partnering with external partners significantly as well with this too-cool effort, as is partnering together with Columbia on a next-generation library management system and on changing our business practices actually within technical services in exchange of common cataloging and technical services, development, selection, other areas. We're involved with Vivo. It's a partnership with now over 100 institutions. We have Vivo installed around the world. We're working with a door space organization on that. We're moving toward the hydro framework and may even become a hydro partner at some point soon to try and standardize and simplify our digital content stack. We're trying to figure out how we can, again, simplify our lives, free up resources to do the things that are critically important academic differentiators. So what happens next? So IT is valuable to the university in two important but very different ways. IT provides utility services and infrastructure and differentiating activities. The utility things, things like desktop management, a central service desk, the sort of basic enterprise applications, foundational infrastructure. The differentiating activities, instructional design and support, a couple that are particular interest and importance to the library, scholarly communication, research data support. We run a research data management support group, online learning. So we want to maximize the value for the utility areas and we want to be able to invest in the differentiators and really shift the IT culture from one area to the other. We're now working on, just finish an IT strategic plan. If you're interested, you can go to the CIO, Cornell CIO site and see it all there. But really we're trying to focus on learning technologies, on the student experience, research support, service excellence, and minimize, you know, previously administrative systems would have sort of been central to a strategic plan for IT at Cornell and that's really no longer the case. As you can see, it's a word cloud of our strategic plan. Services and support are the two biggest elements. So the unifying themes, I'll keep repeating myself here. We want to rebalance the IT investments shifting from utilities to differentiators. We want to develop the role, skills, and organizational structure for the future of IT at Cornell. Make sure that IT at Cornell really is focusing as a coordinated workforce and create intentional interdependence among the elements of IT at Cornell. So the central IT isn't trying to do the work that should be happening in the service groups and vice versa. Become solution designers and brokers, minimize resource constraints through agile models of development, community, rural crowdsourcing, augmentation, and focus more on students and student groups which has been something we've neglected in the past. So what can I draw as lessons or conclusions from this? I think we've made significant progress in saving money and actually saving money and not just getting our budget cut and improving service delivery over the past three years. The BAME process did help in highlighting the problems, but as I've said, it was kind of mixed on their recommendations and solutions. And IT at Cornell is succeeding into a dramatic change in the level of trust between the units and central IT which has been driven by a really high bandwidth communications. I mean, we're meeting for an hour and a half every week all together and an openness to change. They're sitting at the table saying, we will do what you guys need and we're sitting there saying, okay, and how can we take advantage of what you guys can provide. So I think it really has been a significant cultural change within Cornell and we're still in the process but I think we're making good progress. I think we're right at the end of time so thank you very much.