In a recent discussion of the progress of IT@Illinois and comparing it to "rationalization" efforts at some of our CIC peers, the group felt that we have found the way to do IT "right" for a large research institution such as our campus. It is not a question of centralization or decentralization but rather positioning a given service at the highest level where scaling can actually be achieved and value provided. In other words, centralization (or decentralization) doesn't matter.

Yes, I am playing with words a bit in reference to Carr's IT Doesn't Matter. However the point is really important. Centralization is not an overall process for an institution of higher education to take because the needs and requirements of services are going to vary significantly by discipline and even often by individual faculty member or student. Starting by saying that you need to centralize every IT service and IT decision means making a conscious decision to not deliver the most user-centric services. In a centralized service, you typically think about serving the most possible users with generalized needs rather than about how each user is different from another.

On the other end of the spectrum, complete decentralization means little to no coordination, little to no benefits of scaling. While centralization doesn't matter for an IT organization, decentralization is a bad choice as well. A completely decentralized organization is going to miss out on opportunities to save money, yes, but more importantly will fail to make something greater out of the sum of the parts.

So what is this approach of not choosing to centralize or decentralize an IT organization? I have been searching for a term to stick to this organizational style, and I have settled on rationally diffuse for now. Diffuse means to be spread out or scattered. Rational not only has its own meaning, but rationalization is a synonym for centralization. Taking a rationally diffuse approach means to position a service where it makes the most sense. If a particular technology service is best built with the specific needs of an academic discipline in mind, the service is provided at that discipline's level of support. Something fundamental like email service is so consistently common that it makes the most rational sense to provide it at the campus level. To put the practice in a single sentence, you want to diffuse a service to the most rational point within the organization where scaling can be achieved while also providing the service uniquely needed by individual users and groups.

This principle is one that has guided IT@Illinois after the concepting effort in 2009, and it looks like it will serve us well as move into the future. We will be saving big money for the institution from putting some fundamental services centrally, and we are seeing the cultural changes in the community where more and more IT professionals want to be part of a rationally diffuse effort rather than build their own.