© 2004 Carrie E. Regenstein

EDUCAUSE Review, vol. 39, no. 4 (July/August 2004): 68–69.

The Bright Places on the Technology Roadmap

Once upon a time, there was the mainframe. Only a handful of applications were available on this great big computer. A few hearty users took advantage of these applications, often accessing them one at a time. Folks generally did not expect to use any application with another. Why would they?

Now, of course, the world is very different. College and university networked computing environments include hundreds of servers and thousands of desktop computers. Virtually all students, faculty, and staff use these computers and many available applications. They also generally expect these applications to work seamlessly with each other. "Whaddya mean, ‘academic’ and ‘administrative’ technology?" Faculty and students view course management systems and student information systems as the two halves of the yin-yang diagram: perfectly aligned and effortlessly part of the whole.

No problem. Colleges and universities have talented technologists to support enterprise systems. In addition to employing administrative and academic technologists, they have beefed up security teams, added middleware groups, interspersed some operating systems gurus, and peppered the mix with staff who monitor new regulatory requirements to ensure that the systems pass muster. There are folks who slay the dragons of viruses and spam while others—equally heroically—ensure that thousands of users enjoy an easy-to-use portal to access e-mail, calendars, and all kinds of personal information whenever they desire. By day and by night, on weekdays and weekends, the systems recognize who users are and what services they’re entitled to. Pretty nifty.

Or is it? Do our systems in higher education really work this well? Can users truly access data—just the right data and just the right amount, of course—as they need to? Are we able to diagnose problems quickly when the system hiccups? I’m not so sure. We’ve built this construct from bits (no pun intended) and parts. I worry that the environment is like some of the highways developed in the oldest U.S. cities: the on-ramps occur just before the off-ramps (instead of the other way around); the intersections include lots of swirling, turning curlicues; lanes appear and disappear without sufficient notice; and the signage is confusing. It’s hard to focus on where you’re going when the trip is so stressful.

In like fashion, our complex networked environments in higher education require a completely different way of thinking about technology architecture. No longer can a few very smart staff sit in their separate offices and roll out new applications. We must ensure that the technology services we deliver are the product of coordinated planning so that they meet and exceed requirements and expectations.

This sounds good, but how do we do it? At the University of Wisconsin–Madison (UW-Madison), the Division of Information Technology (DoIT) has been grappling with this issue for several years. DoIT created a small group of three architects (in an organization of over five hundred staff) whose mission is to lead and facilitate the creation of a coherent architectural roadmap. And as DoIT implements new systems, it holds the architects accountable for understanding the whole design: the flow of functions and data, the paths and vulnerabilities of identity management and security, the requirements for interoperability between the new and preexisting applications. Having led the development and communication of the technology roadmap and standards, the architects are called on to provide guidance about technological decisions—even within enterprise applications—in order to help staff understand the consequences of decisions and to ensure interoperability. The architects lead campus forums about the technology roadmap, including the road’s inevitable detours and surprises. They engage in active dialogue with campus technologists and leaders to avoid dead ends and confusing signage.

But now we’re in rough territory. Application developers don’t much fancy having other technologists tell them what to do—or what not to do. It takes time to develop a culture in which the technology architects are seen as organizational and institutional intellectual leaders, even if they aren’t "management" leaders.

One of the natural areas for architectural leadership has been the growth and enhancement of the My UW-Madison portal (http://my.wisc.edu), where access is role-based. When the Division of Student Affairs requests that the university reconsider the moment at which new incoming students have access to their NetIDs and campus services, DoIT needs to respond and deliver quickly and securely. Who needs to be part of the team to ensure that the implementation takes all the technical issues into account? Ask an architect. Who will lead that team to identify the issues to be addressed, the standards to be followed, and the resources to be used? Ask an architect. Who allocates the resources and decides the priority order of the work? Not an architect. That’s when a technical assessment team led by an architect reports to senior management for a decision.

Over the last couple of years, the complexity of the UW-Madison systems has kept everyone busy—for example, accommodating increased demands for access while also complying with increased security requirements. This environment has given the architects a chance to demonstrate a new timeliness in their accountability, helping to overcome the old perception that architects, unlike people who do "real work," never have deadlines. Increasingly, they are seen as a key resource for help in asking the right questions, understanding the technical environments, and making hard choices about standards. They are teaching technologists and executives alike how to meet the challenge of defining interoperable and seamless service. They help all of us know—or, at least, know better—where we are on the journey at any given point in time.

I was hoping to find a famous quotation to help summarize the value of working from a foundational architectural roadmap—maybe a quotation from a realm other than technology, such as philosophy. Yogi Berra is one of my favorite philosophers, but all he suggested on this topic was, "When you come to a fork in the road, take it."

I decided it was probably best to follow the advice of Annie Stunden, the UW-Madison CIO, and reread Dr. Seuss. In Oh, the Places You’ll Go!, he reminds us of what our environments look like without architectural leadership and roadmaps:

You will come to a place where the streets are not marked.
Some windows are lighted. But mostly they’re darked.
A place you could sprain both your elbow and chin!
Do you dare to stay out? Do you dare to go in?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple it’s not, I’m afraid you will find,
For a mind-maker-upper to make up his mind.
You can get so confused
that you’ll start in to race
down long wiggled roads at a break-necking pace
and grind on for miles across weirdish wild space,
headed, I fear, toward a most useless place.

A most useless place?

NO! That’s not for you!

And it’s not for me either. Let’s keep all our technologists talking to each other to arrive at the fine spot that Dr. Seuss suggests:

Somehow you’ll escape
All that waiting and staying.
You’ll find the bright places
Where Boom Bands are playing.¹

See you there!

1. Dr. Seuss, Oh, the Places You’ll Go! (New York: Random House, 1990).