Architecting vs. Building: Introduction to Roadmapping

In the course of my "real job" I work with colleges and universities to get the most out of their significant technology investments.

This is a challenge in any market enterprise, but it presents a greater challenge to those in higher education than many others because of one factor, complexity. The average college or university runs a wide array of technologies that support everything from student information and academic functions to financial records, human resources, financial aid, facilities, security, and more. The reality is that even a relatively small college can easily have more technology complexity than some relatively large corporations.

Unfortunately, the information technology (IT) team that supports most smaller colleges or universities tends to be much thinner than that supporting a corporation. This creates several challenges. First, there is a tendency to be completely focused on tactical efforts. A thin team in a complex environment is frequently taxed to merely keep everything running smoothly. At the same time, there is often little time available to plan beyond the immediate demands at hand. When you add the consideration that education and research (the core "business" of higher education) are dynamic processes, and that the typical higher education environment is full of smart people (stakeholders) with great ideas for new, nifty technology uses, the list of demands for IT tends to expand constantly, often at a rate that exceeds the team's ability to execute...resulting in an ever expanding list of tactical activities, and stakeholders who are demanding that their needs be met.

The result of this set of realities is that it is not uncommon for IT departments to spend everyday, all day, building...with no time for architecting. And this can work...at least for a while. In fact, as long as there are unconstrainted resources (capital and human) this approach is sustainable. Unfortunately, the minute there are limits on resources (and for most higher education systems this is occurs quickly) problems arise. All too frequently, individual projects become silo'd efforts, and energy expended to support one activity are not considered from a broader perspective. Priorities tend to be established based on either the crisis d'jour or "whoever is screaming the loudest". This creates an environment that is less than optimal for those people who work in IT, who end up working, more often than not, under stress.

What can be done to alter this kind of challenge? How can an enterprise move from the tyranny of the urgent to an architecting approach? The first step is to develop a Roadmap.

A Roadmap should outline the major objectives for IT in alignment with the key goals and objectives of the enterprise. To be successful, your Roadmap will need to include: current state (where are you today); clear targets for future state (where you want to go); metrics and benchmarks that map to both current and future state (how you will know when you have reached your goal); and a phased approach to move from current to future state (the "road" you are going to take). Once the phased approach is mapped, the IT team can map tactical efforts and projects across more than one area, and efforts will increasingly support an architected aspproach, as opposed to merely building to meet immediate demands. Without a Roadmap, efforts tend to be driven by demands that are less than logical. With a Roadmap in place, IT can begin to take a more planned approach to responding to multiple demands.