Archive for January, 2011

Network Neutrality: Who’s Involved? What’s the Issue? Why Do We Give a Shortstop?

Who’s on First, Abbott and Costello’s classic routine, first reached the general public as part of the Kate Smith Radio Hour in 1938. It then appeared on almost every radio network at some time or another before reaching TV in the 1950s. (The routine’s authorship, as I’ve noted elsewhere, is more controversial than its broadcast history.) The routine can easily be found many places on the Internet – as a script, as audio recordings, or as videos. Some of its widespread availability is from widely-used commercial services (such as YouTube), some is from organized groups of fans, and some is from individuals. The sources are distributed widely across the Internet (in the IP-address sense).

I can easily find and read, listen to, or watch Who’s on First pretty much regardless of my own network location. It’s there through the Internet2 connection in my office, through my AT&T mobile phone, through my Sprint mobile hotspot, through the Comcast connections where I live, and through my local coffeeshops’ wireless in DC and Chicago.

This, most of us believe, is how the Internet should work. Users and content providers pay for Internet connections, at rates ranging from by buying coffee to thousands of dollars, and how fast one’s connection is thus may vary by price and location. One may need to pay providers for access, but the network itself transmits similarly no matter where stuff comes from, where it’s going, or what its substantive content is. This, in a nutshell, is what “network neutrality” means.

Yet network neutrality remains controversial. That’s mostly for good, traditional political reasons. Attaining network neutrality involves difficult tradeoffs among the economics of network provision, the choices available to consumers, and the public interest.

Tradeoffs become important when they affect different actors differently. That’s certainly the case for network neutrality:

  • Network operators (large multifunction ones like AT&T and Comcast, large focused ones like Verizon and Sprint, small local ones like MetroPCS, and business-oriented ones like Level3) want the flexibility to invest and charge differently depending on who wants to transmit what to whom, since they believe this is the only way to properly invest for the future.
  • Some Internet content providers (which in some cases, like Comcast, are are also networks) want to know that what they pay for connectivity will depend only on the volume and technical features of their material, and not vary with its content, whereas others want the ability to buy better or higher-priority transmission for their content than competitors get — or perhaps to have those competitors blocked.
  • Internet users want access to the same material on the same terms regardless of who they are or where they are on the network.

Political perspectives on network neutrality thus vary depending on who is proposing what conditions for whose network.

But network neutrality is also controversial because it’s misunderstood. Many of those involved in the debate either don’t – or won’t – understand what it means for a public network to be neutral, or indeed what the difference is between a public and a private network. That’s as true in higher education as it is anywhere else. Before taking a position on network neutrality or whose job it is to deal with it, therefore, it’s important to define what we’re talking about. Let me try to do that.

All networks discriminate. Different kinds of network traffic can entail different technical requirements, and a network may treat different technical requirements differently. E-mail, for example, can easily be transmitted in bursts – it really doesn’t matter if there’s a fifty-millisecond delay between words – whereas video typically becomes jittery and unsatisfactory if the network stream isn’t steady. A network that can handle email may not be able to handle video. One-way transmission (for example, a video broadcast or downloading a photo) can require very different handling than a two-way transmission (such as a videoconference). Perhaps even more basic, networks properly discriminate between traffic that respects network protocols – the established rules of the road, if you will – and traffic that attempts to bypass rule-based network management.

Network neutrality does not preclude discrimination. Rather, as I wrote above, a network behaves neutrally if it avoids discriminating on the basis of (a) where transmission originates, (b) where transmission is destined, and (c) the content of the transmission. The first two elements of network neutrality are relatively straightforward, but the third is much more challenging. (Some people also confuse how fast their end-user connection is with how quickly material moves across the network – that is, someone paying for a 1-megabit connection considers the Internet non-neutral if they don’t get the same download speeds as someone paying for a 26-megabit connection – but that’s a separate issue largely unrelated to neutrality.) In particular, it can be difficult to distinguish between neutral discrimination based on technical requirements and non-neutral discrimination based on a transmission’s substance.In some cases the two are inextricably linked.

Consider several ways network operators might discriminate with regard to Who’s on First.

  • Alpha Networks might decide that its network simply can’t handle video streaming, and therefore might configure its systems not to transmit video streams. If a user tries to watch a YouTube version of the routine, it won’t work if the transmission involves Alpha Networks. The user will still be able to read the script or listen to an audio recording of the routine (for example, any of those listed in the Media|Audio Clips section of http://www.abbottandcostello.net/). Although refusing to carry video is clearly discrimination, it’s not discrimination based on source, destination, or content. Alpha Networks therefore does not violate network neutrality.
  • Beta Networks might be willing to transmit video streams, but only from providers that pay it to do so. Say, purely hypothetically, that the Hulu service – jointly owned by NBC and Fox – were to pay Beta Networks to carry its video streams, which include an ad-supported version of Who’s on First. Say further that Google, whose YouTube streams include many Who’s on First examples, were to decline to pay. If Beta Networks transmitted Hulu’s versions but not Google’s, it would be discriminating on the basis of source – and probably acting non-neutrally.

What if Hulu and Google use slightly different video formats? Beta might claim that carrying Hulu’s traffic but not Google’s was merely technical discrimination, and therefore neutral. Google would probably disagree. Who resolves such controversies – market behavior, the courts, industry associations, the FCC – is one of the thorniest points in the national debate about network neutrality. Onward…

  • Gamma Networks might decide that Who’s on First ridicules and thus disparages St. Louis (many performances of the routine refer to “the St Louis team”, although others refer to the Yankees). To avoid offending customers, Gamma might refuse to transmit Who’s on First, in any form, to any user in Missouri. That would be discrimination on the basis of destination. Gamma would violate the neutrality principle.
  • Delta Networks, following Gamma’s lead, might decide that Who’s on First disparages not just St. Louis, but professional baseball in general. Since baseball is the national pastime, and perhaps worried about lawsuits, Delta Networks might decide that Who’s on First should not be transmitted at all, and therefore it might refuse to carry the routine in any form. That would be discrimination on the basis of content. Delta would be violating the neutrality principle.
  • Epsilon Networks, a competitor to Alpha, might realize that refusing to carry video disserves customers. But Epsilon faces the same financial challenges as Alpha. In particular, it can’t raise its general prices to cover the expense of transmitting video since it would then lose most of its customers (the ones who don’t care about video) to Alpha’s lesser but less expensive service. Rather than block video, Epsilon might decide to install equipment that will enable video as a specially provided service for customers who want it, and to charge those customers – but not its non-video customers – extra for the added capability. Whether an operator violates network neutrality by charging more for special network treatment of certain content – the usual term for this is “managed services” – is another one of the thorniest issues in the national debate.

As I hope these examples make clear, there are various kinds of network discrimination, and whether they violate network neutrality is sometimes straightforward and sometimes not.  Things become thornier still if networks are owned by content providers or vice versa – or, as is more typical, if there are corporate kinships between the two. Hulu, for example, is partly owned by NBC Universal, which is becoming part of Comcast. Can Comcast impose conditions on “outside” customers, such as Google’s YouTube, that it does not impose on its own corporate cousin?

Why do we give a shortstop (whose name, lest you didn’t read to the end of the Who’s on First script, is “darn”)? That is, why is network neutrality important to higher education? There are two principal reasons.

First, as mobility and blended learning (the combination of online and classroom education) become commonplace in higher education, it becomes very important that students be able to “attend” their college or university from venues beyond the traditional campus. To this end, it is very important that colleges and universities be able to provide education to their students and interconnect researchers over the Internet. This should be constrained only by the capacity of the institution’s connection to the Internet, the technical characteristics of online educational materials and environments, and the capacity of students’ connections to the Internet.

Without network neutrality, achieving transparent educational transmission from campus to widely-distributed students could become very difficult. The quality of student experience could come to depend on the politics of the network path from campus to student.To address this, each college and university would need to negotiate transmission of its materials with every network operator along the path from campus to student. If some of those network operators negotiate exclusive agreements for certain services with commercial providers – or perhaps with other colleges or universities – it could become impossible to provide online education effectively.

Second, many colleges and universities operate extensive networks of their own, or together operate specialized inter-campus networks for education, research, administrative, and campus purposes. Network traffic inconsistent with or detrimental to these purposes is managed differently than traffic that serves them. It is important that colleges and universities retain the ability to manage their networks in support of their core purposes.

Networks that are operated by and for the use of particular organizations, like most college and university networks, are private networks. Private and public networks serve different purposes, and thus are managed based on different principles. The distinction is important because the national network-neutrality debate – including the recent FCC action, and its evolving judicial, legislative, and regulatory consequences – is about public networks.

Private networks serve private purposes, and therefore need not behave neutrally. They are managed to advance private goals. Public networks, on the other hand, serve the public interest, and so – network-neutrality advocates argue – should be managed in accordance with public policy and goals. Although this seems a clear distinction, it can become murky in practice.

For example, many colleges and universities provide some form of guest access to their campus wireless networks, which anyone physically on campus may use. Are guest networks like this public or private? What if they are simply restricted versions of the campus’s regular network? Fortunately for higher education, there is useful precedent on this point. The Communications Assistance for Law Enforcement Act (CALEA), which took effect in 1995, established principles under which most college and university campus networks are treated as private networks – even if they provide a limited set of services to campus visitors (the so-called “coffee shop” criterion).

Higher education needs neutrality on public networks because those networks are increasingly central to education and research. At the same time, higher education needs to manage campus networks and private networks that interconnect them in support of education and research, and for that reason it is important that there be appropriate policy differentiation between public and private networks.

Regardless, colleges and universities need to pay for their Internet connectivity, to negotiate in good faith with their Internet providers, and to collaborate effectively on the provision and management of campus and inter-campus networks. So long as colleges and universities act effectively and responsibly as network customers, they need assurance that their traffic will flow across the Internet without regard to its source, destination, or content.

And so we come to the central question: Assuming that higher education supports network neutrality for public networks, do we care how its principles – that public networks should be neutral, and that private ones should be manageable for private purposes – are promulgated, interpreted, and enforced? Since the principles are important to us, as I outlined above, we care that they be implemented effectively, robustly, and efficiently. Since the public/private distinction seems to be relatively uncontroversial and well understood, the core issue is whether and how to address network neutrality for public networks.

There appear to be four different ideas about how to implement network neutrality.

  1. A government agency with the appropriate scope, expertise, and authority could spell out the circumstances that would constitute network neutrality, and prescribe mechanisms for correcting circumstances that fell short of those. Within the US, this would need to be a federal agency, and the only one arguably up to the task is the Federal Communications Commission. The FCC has acted in this way, but there remain questions whether it has the appropriate authority to proceed as it has proposed.
  2. The Congress could enact laws detailing how public networks must operate to ensure network neutrality. In general, it has proven more effective for the Congress to specify a broad approach to a public-policy problem, and then to create and/or empower the appropriate government agency to figure how what guidelines, regulations, and redress mechanisms are best. Putting detail into legislation tends to enable all kinds of special negotiations and provisions, and the result is then quite hard to change.
  3. The networking industry could create an internal body to promote and enforce network neutrality, with appropriate powers to take action when its members fail to live up to neutrality principles. Voluntary self-regulatory entities like this have been successful in some contexts and not in others. Thus far, however, the networking industry is internally divided as to the wisdom of network neutrality, and without agreement on the principle it is hard to see how there could be agreement on self-regulation.
  4. Network neutrality could simply be left to the market. That is, if network neutrality is important to customers, they will buy services from neutral providers and avoid services from non-neutral providers. The problem here is that network neutrality must extend across diverse networks, and individual consumers – even if they are large organizations such as many colleges and universities – interact only with their own “last mile” provider.

Those of us in higher education who have been involved in the network-neutrality debates have come to believe that among these four approaches the first is most likely to yield success and most likely to evolve appropriately as networking and its applications evolve. This is especially true for wireless (that is, cellular) networking, where there remain legitimate questions about what level of service should be subject to neutrality principles, and what kinds of service might legitimately be considered managed, extra-cost services.

In theory, the national debate about network neutrality will unfold through four parallel processes. Two of these are already underway: the FCC has issued an order “to Preserve Internet Freedom and Openness”, and at least two network operators have filed lawsuits challenging the FCC’s authority to do that. So we already have agency and court involvement, and we can possiible congressional actions and industry initiatives to round out the set.

One thing’s sure: This is going to become more complicated and confusing…

Lou: I get behind the plate to do some fancy catching, Tomorrow’s pitching on my team and a heavy hitter gets up. Now the heavy hitter bunts the ball. When he bunts the ball, me, being a good catcher, I’m gonna throw the guy out at first base. So I pick up the ball and throw it to who?

Bud: Now that’s the first thing you’ve said right.

Lou: I don’t even know what I’m talking about!

Michelin’s Experts versus My Restaurant Preferences: Should, Say, or Do?

Robert Benchley’s core premise, in his funny but oh-so-true article “How To Get Things Done“, is that being productive requires deceiving oneself about priorities. My premise today, closely related, is that what we say isn’t what we should say, and that what we actually do isn’t either of those.

That’s obviously an issue in higher-education information technology, my usual focus, but today I’m writing about Chicago restaurants, and specifically about discrepancies among expertise, preferences, and behavior. Such discrepancies are clearly important in higher-education IT practice. The reader will have to deduce that relevance since I’m going to stick to the matter at hand and hope I finish before I get hungry.

Chicago’s a great restaurant town, no matter whether one is interested in the latest molecular gastronomy, regional cheeses and salume, appropriate garnishes for hot dogs or Italian beefs, or nuanced differences among the seven moles of Oaxaca. So it was wholly appropriate that Michelin would choose Chicago to be its third American Red Guide city. Following a year’s worth of visits, Michelin critics awarded stars to 23 restaurants, and Bib Gourmand recognition to an additional 46. Presumably, since they’re chosen by the experts, Michelin-rated restaurants are where one should prefer to eat.

Years ago I needed a nested list of something to teach myself how to use <li> tags in hand-coded Web pages. I arbitrarily chose to draft a list of  restaurants where I’d eaten and might eat again, and over time that list has grown steadily. When I became a Quicken addict, as a byproduct of record-keeping I began tracking how frequently we ate at various restaurants.

Since we’ve lived in Chicago for almost fourteen years (and still spend most of our time there), we’ve developed preferences that guide both what we recommend to visitors and presumably guide where we actually eat. So I have data on where we should eat (that’s the Michelin ratings) and where we do eat (my Quicken data), and since our recommendations to friends over the years have been pretty consistent, I can also say what our preferences are.

I thought it might be interesting to compare those. I’m curious what one might deduce about why restaurant-choice behavior differs from stated preferences, and why personal preferences differ from those of experts. I munged together a list of restaurants comprising the union of

  • the Michelin starred and Bib Gourmand lists and
  • Quicken data on where we’d dined (arbitrarily defined as an expense of at least $20) at least once in 2008-2010.

Without looking at frequencies, I then rated the restaurants we’ve ever dined at based on how we characterize them to others. I reduced the ratings to five categories: Not Rated (which usually means I don’t remember the place), Okay, Good, Favorite, and Event.

There are 172 restaurants on the combined list. Of those,

  • Michelin awards 69 at least one star or a Bib Gourmand rating,
  • we dined at least once in 2008-2010 at 103 restaurants that remain open,
  • 9 places we dined have closed (none of those is on the Michelin list), and
  • we rate 105 of them Okay or better (we rate more places than we dined at because we have opinions about places we haven’t visited since 2007).

First, let’s look at should versus say.

  • There were 26 restaurants that both Michelin rated Bib Gourmand or Starred and we rated Good, Favorite, or Event.
  • Our Event restaurants (definition: places definitely worth going to once, or if someone else is paying) all received stars from Michelin.
  • However, four of their one-star restaurants we rated merely Good.
  • Conversely, of our 13 Favorite restaurants in the jointly-rated set, Michelin awarded one star to 5 and Bib Gourmand to 8.
  • If we expand the set to include restaurants Michelin didn’t rate and our Okay ratings — that’s a total of 105 restaurants — we learn that Michelin didn’t rate 9 of our Favorite restaurants, and we thought 3 of their Bib Gourmand restaurants were merely Okay.

It’s interesting to look at the discrepancies.

Our 9 Favorites not rated by Michelin are Avec, Café des Architectes, Coco Pazzo Café, Gioco, La Sardine, mk, Pelago, Rosebud Steakhouse, and Shaw’s Crab House. Three of the Favorites omissions from Michelin’s list are curious: Avec, Café des Architectes, and mk are clearly good as or better than many restaurants Michelin rated. The same is true of Pelago, but it may be too new for the Michelin people to have rated it. Some of the others make our list and not Michelin’s because part of their appeal to us is location (that is, they’re near where we live: Coco Pazzo Café, Pelago, and Rosebud Steakhouse), and Michelin does not include that in its judging. And some we find to be consistently good for the money or to be especially welcoming places, which are judgment calls.

Conversely, we rated 4 of Michelin’s one-star restaurants Good, and 3 of their Bib Gourmand places merely Okay. The 4 in that first group are Naha, NoMI, Spiaggia (one of Barack and Michelle Obama’s favorites), and Takashi, and in each case it’s because what we ate, although fine, didn’t live up to billing or price. The 3 in the second group are Bistro 110, Green Zebra, and The Purple Pig, the first of which just hasn’t impressed us that much, and the latter two of which we found disappointing especially given the hype that attaches to them.

All in all, though, we’re not too bad on should versus say. That is, what we recommend and what experts tell us we should be recommending are reasonably well aligned. Yet it’s clear that exactly what criteria one uses becomes very important as one approaches the edge of Should or Say. The general point is that understanding experts’ or one’s own preferences is important. Small differences in criteria can produce substantial differences in what one seeks.

Now the more Benchley-like issue: How does what we say correspond to what we do? Let’s start with an interesting extreme observation: Of the ten restaurants we visited most in 2008-2010, only 1 — Perennial — is on Michelin’s lists, and only 5 — Rosebud Steakhouse, Coco Pazzo Café, Pelago, Perennial, and Avec — are on our own Favorites list.

So what we say and what we do most frequently clearly aren’t quite the same (although at least our top 10 don’t include any restaurants we rate below Good). That is, if we constructed our recommendations based on our behavior, our list might be quite different.

Fortunately, the overall comparison between our ratings and our visits is less discrepant. Across the 105 restaurants we rated, 6 are in the Event class, and we ate at half of those once in 2008-2010 — not a bad number, given that these can cost upwards of $100 per person before wine, tax, and tip. Another 22 we rated Favorite, and we ate at 17 of those at least three times — but two of them went unvisited.

There are 56 restaurants in our Good category, and we ate more than once at almost half of them. Looking at those 25 places, it’s clear that some of them we should rate a bit higher, since they’re at the border and we clearly like them: for example, Branch27, Mercat, Quartino, Rhapsody, Taxim, and The Gage.That list may be the most interesting of all: It clearly suggests that accumulated behavior should figure explicitly in recommendations. That is something the Michelin ratings don’t do.

But this list also illustrates how location can bias behavior-based ratings. Frankie’s Scaloppine is a perfectly good restaurant, albeit one located on the fifth floor of an indoor shopping mall. We visited it 17 times not because it warrants a Favorite rating, but because’s it’s inexpensive, fast, and a block from our home. Several other frequently-visited restaurants on our Good list have that same attribute: even though they’re only Good, they nevertheless have attractive features.

So what should we make of all this? The point, I think, is that we have to be very careful to understand why experts tell us what they tell us, we have to be very careful to understand why we state our preferences as we do, and most of all we need to pay close attention to our behavior. That’s not to say that data should drive preferences — if we do that, nothing will ever change — but rather that divergence between what we say and what we do tells us something, and that something requires attention lest we confuse mythology with fact.

Okay, I can hear at least one of you asking: Where’s that list of Favorites? Here they are. They’re labeled with * for Michelin stars and + for Bib Gourmand, and are in italics if we dined on them at least thrice in 2008-2010:

Avec
Blackbird*
Boka*
Café des Architectes
Coco Pazzo Café
Crofton on Wells*
Frontera Grill+
Gioco
La Sardine
Lula Café+
Mexique+
mk
Pelago
Perennial+
The Publican+
Riccardo Trattoria+
Rosebud Steakhouse
Sepia*
Shaw’s Crab House
Smoque BBQ+
Topolobampo*
West Town Tavern+

Bon appétit! ¡Buen provecho! Time to eat!

Change Rewards, Change Leadership

A few nights ago, at a meeting of IT people from a subset of research universities, dinner conversation turned to why IT people work in higher education. If you do IT in higher education, everyone pretty much agreed, it’s not to get rich. Rather, you’re driven by some combination of four reasons.

  1. IT jobs in higher education have tended to entail a complicated, challenging, and rewarding set of challenges. IT organizations in colleges and universities tend to be relatively small, and tend to involve teamwork across domains that might otherwise be separate. There’s not the neat division between, say, technical and support staff that one might find elsewhere, and so there has been ample opportunity to grow along various dimensions.
  2. IT jobs in higher education have generally involved a certain amount of flexibility. One spends most of one’s time on one’s job, but it’s been commonplace for a certain fraction of time – perhaps as much as 20% — to be essentially the staffer’s to allocate. Much of that time has gone to experimenting with new technologies, or ways to use old technologies, or even to thinking about things not strictly technological. In the aggregate, much of that “uncommitted” time has gone to innovation, some successful and some not. But the opportunity to spend time on activities that are not strictly part of job descriptions, with part of that involving experimentation and innovation, has enabled IT organizations in higher education to be sources of administrative, educational, research, and technological progress.
  3. IT in higher education has usually provided good job security. Absent failure to produce or malfeasance, IT staff in education could reasonably assume that they would have jobs so long as they continued to perform well.
  4. This one’s somewhat different from the other three reasons. IT jobs in higher education have been an interesting and useful way station for recent graduates with abundant energy and skill but little sense of career or personal-development paths. For many IT staff, the job is not an end in itself, but rather a reasonable way to work for a few years while figuring out what to do next – be that graduate school, marriage and family, relocation, a more remunerative job, or whatever. That is, part of what appeals is working where one recently got – or is soon getting – a degree.

For reasons good and bad, the reasons to work in higher-education IT work have eroded, without commensurate offsets such as better pay. This has had little effect on those who work in higher-education IT for reason #4. So long as economic downturns have affected the corporate and .com worlds more than colleges and universities, it also has had little effect on those who work for #1-3. Since the economy has been on a bit of a roller coaster for some years, we’ve thus seen little erosion of IT staffing in higher education.

But as financial strictures settle firmly into higher education, this is changing. There have been greater compartmentalization of tasks, tighter accounting for time and effort, and layoffs unrelated to performance. These directly undercut reasons #1 through #3 for working in higher-education IT, and they’re beginning to have effects on staffing.

What many perceive is a key shift in the higher-education IT workforce: fewer young staff stick around to rise through the ranks, and loss rates do not reverse with age as they once did. The staff-by-age distribution is becoming bimodal, and whereas the left-hand mode is staying put or moving left – that is, staff who leave are leaving sooner – the right-hand mode, starved for replenishment from the middle, is moving right. As a result, higher-education IT organizations are increasingly starved for middle management, and as a second-order consequence they are decreasingly able to fill leadership positions from within. We therefore see more middle-management and leadership hires from the corporate sector.

Those new hires, unaccustomed to reasons #1-4, are likely to magnify rather than counteract the changes that underlay their hiring. The result, if we can avoid a vicious circle, is that non-pecuniary reasons for working in higher-education IT will give way to pecuniary ones. IT staff in colleges and universities will have more focused, less flexible, and less secure jobs, but they will be paid more to do them. If productivity under the new regime grows sufficiently to offset higher IT payrolls (which may mean that staffing levels decline), then the evolution can succeed. If it doesn’t, then increased spending will fail to yield commensurate progress.

Let’s assume, for the moment, that the evolution is both desirable and successful. What issues might we need to address? Here are five for starters:

  1. Whether we like it or not, colleges and universities operate with cultures that are very different from corporate cultures. If staff are hired from the latter, then we need to find effective ways to quickly give them an understanding of the former. This doesn’t mean that outside hires must go native, accepting their new culture as gospel, but rather than they must understand the status quo if they are to change it.
  2. If pay does become a dominant reason for people to work in higher-education IT, then colleges and universities must adopt modern approaches to compensation: bonuses for effective work, putting some compensation formally at risk, direct connections between performance reviews and compensation, benefits suited to staff needs, and most important compensation levels that truly compare favorably with the outside market.
  3. Even if we successfully integrate and compensate staff from outside higher education, inevitably staff turnover will be higher than it has been in the past: that’s another attribute of corporate IT cultures. This means that college and university IT organizations can no longer rely on long-term employees as the repositories of accumulated experience. Rather, they must adopt formal mechanisms for reaching, making, and recording decisions, for documenting implementation and change, and generally for ensuring that wisdom survives turnover.
  4. Idiosyncrasy, long the hallmark of higher-education IT and in many cases the guarantor of continued employment, will give way to standardization. The default for decisions whether to outsource will no longer be “no”. The burden of proof will shift to those opposing outsourcing, and there will be increased scrutiny of “we’ve always done it this way” arguments.
  5. Partly as a result of #4, possibilities for inter-institutional collaboration and joint procurement should expand. In some cases this will lead logically to joint-development efforts, especially where higher education has unique needs (for example, student systems, learning-management systems, and many research applications). In other cases it will lead logically to demand aggregation, especially where higher-education needs are consistent, they resemble those outside the academy, and they yield no competitive advantage (for example, email systems or cloud-based storage).

Many of those currently preparing to become leaders within higher-education IT are ill prepared to address issues like these. Many of those who come from outside to take leadership positions in higher-education IT do not understand why issues like these are hard to address in higher education. The solution, as with many of the changes we face, is serious, deep-thinking professional development: places where those rising or jumping into college or university IT leadership can learn what the future is bringing and how to address it. These can be didactic, like EDUCAUSE’s management and leadership institutes, or collaborative, like the Common Solutions Group, the Council of Liberal Arts Colleges, the League for Innovation, and other entities where peers gather to share experiences and best practices.

In the past we’ve built leaders informally, by drawing them from those who have been with us for a long time. As that pool dries up, we need to think differently.

The Era of Control: It’s Over

Remember Attack Plan R? That’s the one that enabled Brigadier General Ripper to bypass General Turgidson and the rest of the Air Force chain of command, sending his bombers on an unauthorized mission to attack the Soviet Union. As a result of Plan R and two missed communications – the Soviets’ failure to announce the Doomsday Device and an encrypted radio’s failure to recall Major Kong’s B-52 – General Ripper ended the world and protected our precious bodily fluids, Colonel Mandrake’s best efforts notwithstanding.

Fortunately, we’re talking about Sterling Hayden, George C. Scott, Slim Pickens, and Peter Sellers in Stanley Kubrick’s Dr. Strangelove, or How I Learned to Stop Worrying and Love the Bomb, and not an actual event. But it’s a classic illustration why control of key technologies is important, and it’s the introduction to my theme for today: we’re losing control of key technologies, which is important and has implications for how campus IT leaders do their jobs. We can afford to lose control; we can’t afford to lose influence.

Here’s how IT was on most campuses until about ten years ago:

  • There were a bunch of central applications: a financial system, a student-registration system, some web servers, maybe an instructional-management system, and then some more basic central facilities such as email and shared file storage.
  • Those applications and services were all managed by college or university employees – usually in the central IT shop, but sometimes in academic or administrative units – and they ran on mainframes or servers owned and operated likewise.
  • Students, faculty, and staff used the central applications from desktop and laptop computers. Amazing as it seems today, students often obtained their computers from the campus computer reseller or bookstore, or at least followed the institution’s advice if they bought them elsewhere. Faculty and staff computers were very typically purchased by the college or university and assigned to users. In all three cases, a great deal of the software on users’ computers was procured, configured, and/or installed by college or university staff.
  • Personal computers and workstations connected to central applications and services over the campus network. The campus network, mostly wired but increasingly wireless, was provided and managed by the central IT organization, or in some cases by academic units.
  • Campus telephony consisted primarily of office, dormitory, and “public” telephone sets connected to a campus telephone exchange, which was either operated by campus staff or operated by an outside vendor under contract to the campus.

Notice the dominant feature of that list: all the key elements of campus information technology were provided, controlled, or at least strongly guided by the college or university, either through its central IT organization or through academic or administrative units.

There were exceptions to campus control over information technology, to be sure. The World Wide Web was already a major source of academic information. Although some academic material on the web came from campus servers, most of it didn’t. There were also many services available over the web, but most campus use of these was for personal rather than campus purposes (banking, for example, and travel planning). Most campus libraries relied heavily on outside services, some accessible through the Web and some through other client/server mechanisms. And many researchers, especially in physics and other computationally-intensive disciplines, routinely used shared computational resources located in research centers or on other campuses. Regardless,  a decade ago central or departmental campus IT organizations controlled most campus IT.

Now fast forward to the present, when things are quite different. The first difference is complexity. For example, I described my own IT environment in a post a few weeks ago:

I started typing this using Windows Live Writer (Microsoft) on the Windows 7 (Microsoft, but a different part) computer (Dell) that is connected to the network (Comcast, Motorola, Cisco) in my home office, and it’ll be stored on my network hard drive (Seagate) and eventually be posted using the blog service (WordPress) on the hosting service (HostMonster) where my website and blog reside. I’ll keep track of blog readers using an analytic service (Google), and when I’m traveling I might correct typos in the post using another blog editor (BlogPress) on my iPhone (Apple) communicating over cellular (AT&T) or WiFi (could be anyone) circuits. Much of today’s IT is like this: it involves user-owned technologies like computers and phones combined in complicated ways with cloud-based services from outside providers. We’re always partly in the cloud, and partly on the ground, partly in control and partly at the mercy of providers.

Mélanges like this are pretty much the norm these days. And not just when people are working from home as I often do: the same is increasingly true at the office, for faculty and staff, and in class and dorms, for students. It’s true even of the facilities and services we might still think of as institutional: administrative systems and core services, for example.

The mélanges are complex, as I already pointed out, but their complexity goes beyond technical integration. That’s the second difference between the past and the present: not only does IT involve a lot of interrelated yet distinct pieces, but the pieces typically come from outside providers – the cloud, in the current usage. Those outside providers operate outside campus control.

Group the items I listed in my ten-years-ago list above into four categories: servers and data centers, central services and applications, personal computers and workstations, and the networks that interconnect them. Now consider how IT is on today’s campus:

  • Instead of buying new servers and housing them in campus buildings, campuses increasingly create servers within virtualization environments, house those environments in off-campus facilities perhaps provided by commercial hosting firms, and use the hosting firm’s infrastructure rather than their own.
  • A rapidly growing fraction of central services is outsourced, which means not only that servers are off campus and proprietary, but that the applications and services are being administered by outside firms.
  • Although most campuses still operate wired and wireless networks, users increasingly reach “campus” services through smartphones, tablets, web-enabled televisions, and portable computers whose default connectivity is provided by telephone companies or by commercial network providers.
  • Those smartphones, tablets, and televisions, and even many of the portable computers, are chosen, procured, configured, and maintained individual users, not by the institution.

This migration from institutional to external or personal control is what we mean by “cloud services”. That is, the key change is not the location of servers, the architecture of applications, the management of networks, or the procurement of personal computers. Rather, it is our willingness to give up authority over IT resources, to trade control for economy of scale and cost containment. It’s Attack Plan R.

The tradeoff has at least four important consequences. Three of these have received widespread attention, and I won’t delve into them here: ceding control to the cloud

  • can introduce very real security, privacy, and legal risks,
  • can undercut long-established mechanisms designed to produce effective user support at minimal cost, and
  • can restructure IT costs and funding mechanisms.

I want to focus here on the fourth consequence. Ceding control to the cloud necessarily entails a fundamental shift in the role of central and departmental IT organizations. This shift requires CIOs and IT staff to change their ways if they are to continue being effective – being Rippers, Kongs, or Turgidsons won’t work any more.

Most important, cloud-driven loss of campus control over the IT environment means that organizational and management models based on ownership, faith, authority, and hierarchy – however benevolent, inclusive, and open – will give way to models based on persuasion, negotiation, contracting, and assessment. It will become relatively less important for CIOs to be skilled at managing large organizations, and more important for them to know how to define, specify, and measure costs and results and to negotiate intramural agreements and extramural contracts consistently. Cost-effective use of cloud services also requires standardization, since nothing drives costs up and vendors away quite so quickly as idiosyncrasy. Migration to the cloud thus requires that CIOs understand emerging standards, especially for database schemas, security models, virtualization, system interfaces, and on and on. It requires that CIOs understand that strength lies in numbers – especially in campuses banding together to procure services rather than in departures from the norm, however innovative.

Almost as important, much of what campuses now achieve through regulation they will need to achieve through persuasion – policy will give way to pedagogy as the dominant mechanism for guiding users and units. I serve on the operations advisory committee for a federal agency. To ensure data and program integrity, the agency’s IT organization wanted to revise policies to regulate staff use of personal computers and small mobile devices to do their work from home or while traveling. It became rapidly clear, as the advisory committee reacted to this, that although it was perfectly possible to write policies governing the use of personal and mobile devices, most of those policies would be ignored unless the agency mounted a major educational campaign. Then it became clear that if there were a major educational campaign, this would minimize the need for policy changes. This is the kind of transition we can imagine in higher education: we need to help users to do the right thing, not just tell them.

On occasion I’ve described my core management approaches as “bribery” and “conspiracy”. This meant that as CIO my job was was to make what was best for the university also be what was most appealing to individuals (that’s “bribery”), and that figuring out what was best for the university required discussion, collaboration, and agreement among a broad array of IT and non-IT campus leaders (“conspiracy”). As control gives way to the cloud for campus IT, these two approaches become equally relevant to vendor relations and inter-institutional joint action. We who provide information technology to higher education need to work together to ensure that as we lose control over IT resources we don’t also lose influence.