IT@Illinois kicks off
Yesterday was the kick-off of the IT@Illinois project to envision the future of IT at the Urbana-Champaign campus of University of Illinois. Going into the day, we knew a little of what Sally Jackson, CIO of the campus, had in mind, but we did not know a significant amount of detail of what the Provost was thinking. We knew that the project of transforming IT on the Urbana-Champaign campus was going to be launched, but we did not know what that meant. What did we learn on the day of presentations?
I think what you learned largely depends on your background with IT on campus. If you were supporting a unit not doing a lot of research, you learned about some of the amazing technology in use for research North of Green and across disciplines all over campus. If you were helping faculty with teaching, you heard perhaps how technology was facilitating teaching and where it fell short in that effort. In the end, if you had a good handle on what IT on campus is and is not, you probably did not learn much of anything new except perhaps some more names of the really smart people around the University. The part that was new to everyone though was the call to action at the end of the day from the Provost.
At the end of the day, the Provost asked the IT community to think about how IT could be done in a way that was more efficient but yet more powerful in enabling education and research. We knew that the Provost thought that IT should be done differently, but she left it to the community to determine what that means in terms of design and implementation. She said we should not feel constrained by legacy structures or by history. While perhaps freeing, it is also frightening.
Today, Sally lead a group of about fifty IT leaders from around campus. I was very fortunate to be asked to join the group. There were Assistant Deans, IT directors from around campus, service managers from CITES, staff of the CIO's office, and perhaps two or three of the "other" category. While I am an IT manager on campus, and I felt honored to hear that Sally and Mona value the contributions I have made around campus in the last year as well as on the IT@Illinois project so far. Being one of the "other" to be a part of the group is going to be very challenging but rewarding. The group has a lot of managers and central IT types on it, but I do not think there is any one majority unduly influencing what we are going to do.
So what are we going to do?
Sally Jackson did an excellent job at the workshop today of putting the Provost's charge into three points.
- Increase the affordability of higher education
- Remove impediments due to current bureaucratic complexity
- Be Excellent
Those are pretty broad, and she reinforced that the Provost has no vision of what she thinks IT will look like. While perhaps a good feeling that there are no immediate expectations to reduce staffing or eliminate projects, it also causes a flinch reaction since it is a very broad mission. What should IT look like in 5 years? 10 years? Longer? We got where we are now without planning beyond individual organizations like CITES, AITS, college IT structures, and department IT structures. This complete lack of structure outside of immediate organizations means that a lot of effort gets duplicated both inefficiently and sometimes ineffectively. Based on what we know about IT on campus (and Wednesday's session for those without the historical knowledge), I do not think any of us would believe that IT on campus would have been intentionally built the way it currently exists. IT grew up at colleges, departments, and units for a long time out of necessity, but I believe we are long beyond the point of total decentralization for every department that wants to be on their own.
Today's workshop largely started discussion and gave us a sense of where we are. There were a few great ideas that I think generated some consensus, but they are far from resulting in any specific visions of what IT will look like on campus. This is one in particular that I think is likely to be captured no matter what we end up doing.
Innovation -> Transformation -> Operation
Technology usually goes through this sort of lifecycle. It starts out as being innovative and extremely creative. As an IT group implements a new technology in a new way, they are an innovator. Over time that technology will transform the organization and how it operates. Finally, it will go into an operational mode where it is just the way things are done. To me, I think that one of the biggest missing components for technology innovation on campus is the transition from local transformations and operations to a broader transformation and operation around campus. If something amazingly innovative is done with technology at the Physics department, there is currently no pathway that could promote that innovation to other campus users who want to use it. As another example, there are dozens of vacation and sick leave reporting tools around campus, and there really is not a way for the best tools to "graduate" and become campus-wide offerings except at the pleasure of the departments who created them.
I believe agility is a core value of IT on campus, but I also think that our current lack of broad collaboration and communication causes something like the TheLadders.com tennis commerial. In other words, if we are all trying to be completely agile without collaborating and communicating in IT, we really just end up with chaos.
What to do now?
We ended the day by working on two sets of tasks. One was a list of immediately actionable things that we can do to improve IT on campus. These were things like continuing the current efforts on desktop virtualization, data center consolidation, and the like. But they also included a few things like taking inventory of the IT projects in progress around campus and finding out what sorts of projects people were contemplating for the future. At the very least, these are things that we absolutely must do if we want to do anything at all to improve IT on campus. They are however short term activities that do not alter the organization or culture that got us to where we are today.
The activity to address that fact is yet to be determined. We know we need to identify the core values of IT on campus - things like agility or facilitating learning. Another aspect that was suggested was doing a full analysis of what our current IT organization is and does. The problem is that we have a very decentralized and chaotic IT "organization," and we only have until March to present a proposal to the Provost on our vision of IT@Illinois. When you consider that you have fifty people trying to reach a consensus of some sort, you could eat a significant amount of the next 10 or 12 weeks just looking at the current situation.
I think one idea that was described by one of the people in the group would result in the best vision and give a wide portion of the campus community the chance to participate. That idea would be to have people in the group of fifty break into groups interested in designing what they think would be the best structure and capability. One group might put together a plan for a completely centralized structure for IT@Illinois. Another group might put together a plan that takes the current IT structure and attempts to fix the significant issues. A third group might come up with something else. Then at the end of the time period, we would have a sort of business plan competition where each of the proposals could be presented and judged so that the group could decide which one is the best one to recommend to the Provost.
I think this method would work best for two reasons. One is that it would immediately enable people to work on the ideas that excite them the most. The second is that it would give the broader IT community the opportunity to contribute without it resulting in 10 or 12 weeks of debate. While we might admire IT organizations like those at Indiana University, we are not being tasked with designing an equivalently performing IT organization but with designing something that will be innovative and creative.

1 response to "IT@Illinois kicks off"
1. Suggestion
You've mentioned some things, but I'd like to take partial issue with one comment you made, and also make a suggestion for a broader adoption of a practice that is already in place at UIUC. In your post, you claimed: "IT grew up at colleges, departments, and units for a long time out of necessity, but I believe we are long beyond the point of total decentralization for every department that wants to be on their own." While IT certainly grew up that way here (though not in other universities, thus, not out of necessity), there is also an added benefit that goes along with that: the IT environments in particular schools and departments are customized for the needs of those units, and often one-size fits all solutions actually fit few to none (e.g., Banner despite its promise). For this reason, it is *not* always an improvement to centralize. Efficiency in IT administration and management may be *more* than off-set by inefficiency in daily work-flows and work practices by secretaries, students, or professors. Thus, it is extremely important that modularity of services and ability to customize them for particular units be values included in this restructuring process. For those of us who study technology, we see a future where most technological solutions/services will be composed by knitting together modular chunks of services and applications, either with minimal glue code, via APIs, or via direct data shuttling. While this future is at least 2-5 years off, and possibly 5-10 years away, it is probably a good idea to start preparing for it now, so that a second complete overhaul is not needed in the near future.
To this end, I'd like to suggest a practice that is being pioneered at GSLIS and at the Library (especially in the IDEALS project). This is the preferential adoption of FLOSS over licensed software even if the FLOSS is of somewhat lower quality, and then the hiring of skilled programmers to not only modify the FLOSS so that it has the functionality that is actually needed, but feed the modifications back into the development process so that the FLOSS is made more stable, more robust, and more customizable. Now, it is not always possible to adopt FLOSS. Sometimes no even quasi-stable FLOSS exists for a particular function. Other times, the stable, reliable FLOSS that exists does not have a feature that is vital for a local adoption to be successful. However, when it is possible, this solution benefits both the FLOSS community, thus fulfilling the University's mission to give back to Society, and the local community, because they get software that actually does *exactly* what they need it to do. Vital to this process, and easily overlooked, is that all of the units that are using this kind of solution have extremely effective feedback collection mechanisms that are used to directly inform the next iteration of the software. That these mechanisms provide tangible evidence of change to the users means that the users feel that their concerns are being taken seriously. Thus breeding good will, generally, as well. It also means that the IT people are extremely responsive to users, often providing fixes within days or weeks. Which is something CITES is notoriously horrible about (I can tell you many stories from my personal experience).
The benefit of this FLOSS-approach, so to speak, is that the economies of scale can occur along lines of need, rather than along lines of organization. This is especially true if we can convince other universities to follow this model. If Moodle, say, is really good for teaching classes in Education and Library Science, but horrible for teaching classes in Math and Physics, then it can be adopted by those departments that can use it, and not by the others. However, because other universities are using Moodle for their LIS and Education departments, and each provides a programmer or two (or half) to customize Moodle, the software grows more useful and more stable as time goes on, and gradually morphs into the package which the department in question needs it to be. Now, we're probably talking extended time frames, like 5+ years. But barring complete economic collapse and a Mad Max style post-apocalyptic future, nobody's going to stop using technology anytime soon. As a central organization, the university IT can support this evolution and look for ways in which the parts of the software can be modularized, and then plugged into a more unified infrastructure, so that data can be shared more effectively.
I don't know if I communicated the vision effectively or not. I can say that it is already being implemented, and as far as I can tell, successfully implemented too. I'd be happy to talk to you more about this, feel free to email me.
Ingbert
http://ingbert.org/