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

TidBITS Celebrates 20 Years of Internet Publication
plus: Twenty Years of Memories from Friends of TidBITS

I think I first encountered TidBITS around 1995. Nice coincidence: this is their 1024th issue.

Turning Web Video On Its Head

As the post says:

Here’s some fun. (For a sufficiently nerdy definition of “fun”.)