In an earlier post I mentioned Nicholas Carr’s book Does IT Matter? and the argument that information technology has become a commodity, and therefore an organization like the University should buy off-the-shelf systems to meet IT needs. I think anyone who wants to engage in the “buy vs. build” argument should read this book in order to understand the reasoning, even if in the end you don’t agree with it.

In this book, Carr reviews how earlier technology advances, like the development of railroads and the harnessing of electricity, played out in business. At first, businesses that embraced the new technology had a strategic advantage over those that didn’t. After a while, though, all businesses were using it (or had gone out of business) so there was no strategic advantage to the technology, it had just become a part of the cost of doing business. Instead of devising a “railroad strategy” or an “electricity strategy,” businesses located near a rail line or hooked up to an electric utility and purchased standard equipment to use the technology. Carr argues that information technology has reached this same stage.

Carr applies his argument to both hardware and software. Now, I’m mostly a software guy, so my discussion will focus on that side. Software is rather unique from an economic point of view: it costs a lot to create a program, but once it’s been written it costs very close to nothing to copy and distribute it. This drives software toward commodity pricing: the more copies of the program you sell, the smaller a percentage of the fixed costs of software development each customer will have to pay.

On the other hand, a big part of commoditization is standardization. I can treat electricity as a commodity because every device plugs into a few standard outlets: rather than having to purchase the same kind of, say, toaster, as my last one because it has a proprietary way to get power from the electrical lines, I can buy any brand. If I have a Ford car, I can replace it with a Chevy without changing the route I drive to work. With software we do not yet have nearly this degree of standardization. As Brian Cantrill said in The Economics of Software :

The problem is that for all of the rhetoric about software becoming a “commodity”, most software is still very much not a commodity: one software product is rarely completely interchangeable with another. The lack of interchangeability isn’t as much of an issue for a project that is still being specified (one can design around the specific intricacies of a specific piece of software), but it’s very much an issue after a project has deployed: deployed systems are rife with implicit dependencies among the different software components. These dependencies — and thus the cost to replace a given software component — tend to increase over time. That is, your demand becomes more and more price inelastic as time goes on, until you reach a point of complete price inelasticity. Perhaps this is the point when you have so much layered on top of the decision, that a change is economically impossible. Or perhaps it’s the point when the technical talent that would retool your infrastructure around a different product has gone on to do something else — or perhaps they’re no longer with the company. Whatever the reason, it’s the point after which the software has become so baked into your infrastructure, the decision cannot be revisited.

This is another article you should definitely read if you are interested in this issue. If you do, you’ll see that his analysis has influenced mine. Cantrill’s conclusion is that the peculiar economics of software mean that in the long run open source provides the greatest benefits for both software producers and consumers.

So how does this apply to the University? We are definitely in a “vendor lock-in” situation, and the vendors that have us locked in are not just IBM (as some seem to be framing the issue) but also Software AG and, well, ourselves, with the software we’ve developed in-house. Any change is going to be costly, but also any change will most likely result in being locked in to a new set of vendors. Perhaps Cantrill is right, and we should be looking more closely at open source software if we want to have more flexibility in the future.

W3C Launches Audio Incubator Group

I’m guessing this is motivated by the controversy over HTML5 codecs.

I attended the AITL meeting yesterday. I found it encouraging and frustrating.

What was encouraging? The AITL is made up of intelligent people who are committed to making the University run more effectively and efficiently. They have a clear grasp of the issues we’re facing, and want to do what’s best for the University.

What frustrated me can be illustrated by a sentence from Brad’s “ITS Weekly Update”:

The BSC will use AITL input as it decides whether we “stay status quo with the mainframe” or “move to Open Systems.”

This is wrong on so many levels. We can change the status quo significantly while staying on the mainframe, and the move to Open Systems envisioned by the Mainframe Migration Assessment would preserve the status quo in every dimension except the hardware and operating system. “Status quo on the mainframe” and “move current Adabas/Natural applications to Open Source” are not the only alternatives!

Dennis said at the beginning of the meeting that the purpose of the assessment was to see if the University could save money by moving our existing application portfolio off the mainframe. I think the report answered that question, and the answer is clearly “no.” But I thought when it was first proposed, and I still think now, that “Mainframe vs. Open Systems” is the wrong question. (Personally, I don’t see where there’s that big a difference.) The right question is something like “what should be the University’s long term strategy for administrative information technology?” If we can answer that correctly we will actually have a basis for tactical decisions like whether or how quickly we should migrate off the mainframe. Focusing on the hardware and operating system just distracts us from the real issues.

Sometimes while in the middle of big changes or decisions it’s easy to forget the big picture, so today I want to step back for a minute and look at the context of our technology decisions.

The mission of The University of Texas at Austin is to achieve excellence in the interrelated areas of undergraduate education, graduate education, research and public service.

This is the official mission statement of the University. Notice that it doesn’t say anything at all about information technologies. If the University could run without IT, it should, because that’s not what the University is about.

However, the University can’t run efficiently without IT. Students must be registered and their grades recorded, faculty and staff must be paid, supplies must be purchased—performing these and many other necessary activities without IT would impose a prohibitively high drain on the University’s resources.

If we truly want to have a university “of the first class,” we need a quality administrative IT infrastructure. The University will not be able to attract and retain top faculty and students as effectively if they are forced to deal with slow, buggy, or difficult to use administrative applications. Costs to the University will rise if staff are forced to spend excessive time or effort working with or even circumventing poorly designed applications.

The problem we’re trying to solve is to provide first-class IT services without consuming so much of the University’s resources that it detracts from fulfilling the University’s core mission.

One of the things that becomes clear if you look at the Mainframe Migration Assessment report is that Software AG license fees form a major part of the University’s administrative computing costs. We need to either make sure we’re getting our money’s worth, or find less expensive/more effective tools.

I’ve felt for some time that Natural is not adequate for what we need to do. Twenty years ago it provided more than enough power, but no longer.

Natural and Problem Domains

Also, several things Software AG has done have convinced me that they no longer see Adabas and Natural as a source of future growth. We really need to explore new tools and expand our tool set. The PyPE project is a step in the right direction, but if we’re going to continue to write our own applications we need to do more.

(This is a long enough blog for now, but once we do develop more tools the question of migrating our applications to them arises. All I’ll say for now is that I don’t see the Mainframe Migration Assessment telling us much of value about that.)

I’ve talked a little in the last few posts about switching to a commercial ERP or continuing to build our own. There is a third alternative that sits somewhere between these two: switching to and participating in open source projects like Kuali or Sakai. This could relieve us of some of the costs of software development and help ensure we don’t deviate from industry-standard practices, while avoiding some of the problems of vendor lock-in and allowing us to maintain a committed developer community.

Again, the costs of migrating to this would be high (although I expect they might be smaller than some of the other alternatives.) If I were the one making the decisions about the University’s strategic direction, I would give it a lot of consideration.

~~~~~~~~~

Update: I took a walk at lunch and decided I should explain what I meant by “maintaining a committed developer community.” One of the dangers of switching to a commercial ERP is that it is likely to be a one-way transition. (I’m indebted to Adam Connor for this insight.) People who enjoy application development and are good at it are almost certain to leave during a migration to a commercial ERP, and if you later decide it’s not working out you will most likely have a staff without the skills needed for in-house development. Since part of the “price” of participation in an open source project is contributing code back, this shouldn’t be as big an issue.

Even if we do continue to develop our own applications in-house, that doesn’t mean we can take a “business as usual” attitude. To keep up with our competition and continue serving the University, we have to constantly reevaluate our tools and practices.

One of the ways that our development culture seems to have changed over the past decade is that we now seem much more risk-averse than we were. I don’t see this change as positive: the only way to guarantee you won’t fail is to never try to do anything, but that’s just a failure of another sort. You can’t push ahead without going where you haven’t gone before. If we really want to continue to build our own administrative systems, we need to recover a tolerance for mistakes.

(This is a continuation of the previous post. I will probably have more to say after this one, too.)

One way to avoid developing a vision for administrative IT would be to in effect outsource it by stopping in-house development and migrating to a commercial ERP package like PeopleSoft. There is a strong argument for doing this: Nicholas Carr wrote a whole book (Does IT Matter?) arguing that IT has become a commodity and that there’s no strategic advantage in building your own applications. While I think he overestimates the maturity and stability of the IT industry, he may be right.

On the other hand, we do have some evidence suggesting that building applications ourselves has benefits. In his post for staff appreciation week, Pres. Powers said:

The percentage of UT Austin’s budget spent on administrative costs (5.5%) is about half of the average for Texas public universities.

I’m sure there are many factors that contribute to these lower costs. UT Austin can undoubtedly take advantage of economies of scale that smaller universities can’t. Austin probably attracts more intelligent and creative people than most places, so UT has a better caliber talent pool to recruit staff from. But I also suspect that one of the things driving lower administrative costs is the caliber of applications we’ve developed here—if we used the same software as everyone else, it seems likely that our costs would be more in line with everyone else’s.

Also, we should realize that the cost of moving to a commercial ERP would most likely be similar in scale to the costs outlined in the mainframe migration assessment, as much of the effort would be the same or similar: testing, integrating the migrated pieces with the parts not yet migrated, purchasing new hardware, retraining staff, and so on.

I’m not convinced that migrating the a commercial ERP would benefit the University, but if you believe the argument that IT is a commodity it would make more sense than the proposed mainframe migration.

One of my earliest posts on this blog was about an open letter I wrote in which, among other things, I argued that before doing a mainframe migration assessment we should develop a strategic vision for administrative IT at the University. Well, here we are, ten months later, and we have a migration assessment but no strategic vision. So how are we supposed to evaluate this assessment?

(Although, while it may be just a lack of imagination on my part, I can’t imagine any strategic vision where the kind of migration envisioned in this assessment makes any sense. If I’ve understood the ROI section, even  the least costly scenario has a negative $1 million return on investment after 11 years.)

Anyway, things like hardware and operating systems and even programming languages, databases, and other development tools are, ultimately, tactical issues. Without a vision of what administrative IT will be like—what kinds of services we’ll provide to students, faculty, and staff, and how those services will fit into their workflows and lives—without knowing where we want to go, how can we begin to decide if we have the right tools to get there?

Where there is no vision, the people perish. (Proverbs 29:18)

via Daring Fireball: That Lost 4G Phone