Adam links to a great article about asking the right questions. This has been the frustration that informs many of my posts here: I think our management is asking (and answering) the wrong questions. Adam’s question is a good one; software development is not part of the University’s core mission. Here are a couple of related questions, with some thoughts:

Does our current in-house developed ERP save the University money and other resources, particularly in comparison to what the costs would be if we had a commercial ERP? Does it allow the University to pursue its mission in ways that would not otherwise be possible?

Unless the answer to at least one of these questions is “yes,” we really have no business developing our own ERP. I think that when the BSC says it considers our ERP strategic that is equivalent to saying that the answer to these questions is yes, but perhaps translating “is our ERP strategic?” to questions like this can clarify things.

The great thing about good questions is that answering them leads to more questions. If the answer to these questions is no, the next question should be, “how can we convert to a commercial ERP with the least cost and disruption?” If the answer is yes, then we can start asking questions like “What characteristics of our ERP give it these advantages?”  Answering that question will lead to questions about tools and, eventually, we can get to a point where it makes sense to ask questions like whether a migration to Open Systems will benefit the University. Instead, we’ve been handed the answer to the last question without any plan for how to do it or any real idea of what it means.

When the AITL wrote up its recommendations on the Mainframe Migration Assessment for the BSC*, it included a section on long-term strategy:

The Architecture and Infrastructure Committee (AIC) has proposed a joint task force between the BSC, AITL and AIC to work on the development of an Administrative Systems Master Plan [SITAC 9.1]. We concur with that proposal. However, before work on the technical aspects of the plan begins, the business leadership of the University needs to provide strategic direction by answering questions including but not limited to:

• Does the University view its ERP systems as a strategic advantage in advancing its mission?
• What is our institutional strategy for making buy vs. build decisions?
• What level of integration is desirable for our administrative systems?

Once driving factors such as these have been determined, selection of the most appropriate tools and technologies can proceed.

I wasn’t invited to the BSC meeting where this is discussed. All that the minutes say about the first question is:

As to the first question, the BSC was in full agreement that the University views its ERP systems as a strategic advantage in advancing its mission.

Well, today Adam posted a link to a great article, How Will You Measure Your Life? I’d like to highlight one particular paragraph:

A theory that is helpful … concerns how strategy is defined and implemented. Its primary insight is that a company’s strategy is determined by the types of initiatives that management invests in. If a company’s resource allocation process is not managed masterfully, what emerges from it can be very different from what management intended. Because companies’ decision-making systems are designed to steer investments to initiatives that offer the most tangible and immediate returns, companies shortchange investments in initiatives that are crucial to their long-term strategies.

In other words, just saying we consider our ERP strategic doesn’t mean anything if resources are not allocated accordingly. Frankly, when I look at what the University’s management has invested in over the past couple of years, I don’t get the impression that it sees a strategic advantage in our current ERP. A real strategy needs more than lip service.

*Full disclosure: I helped write this document.

Now that I’m back from vacation, I’ll answer the implicit question Adam asked in his post about less powerful languages:

Perhaps that is what Curtis is really aiming at: a powerful language that enough people can be good at.

That’s close. I don’t want a less powerful language, but I do want one without a steep learning curve, and in fact, one where you can ignore the more abstract parts unless you really need them. There’s more to it than that, though: each language makes some things easy and some things hard. I want a language where the things that our developers need to do often are easy, and the hard things are things they rarely need to do.

When mutual funds and such issue a prospectus, they typically have a phrase like “past results should not be taken as a guarantee of future returns,” and something similar should probably be said about projecting future demand for mainframe capacity. But as long as we’re trying to predict the future, the past provides most of what little actual data we have to go on.

Continue reading →

The first browser I used was NCSA Mosaic, but I soon moved to Netscape Navigator. I switched to Firefox nearly as soon as it became available, and it’s been my primary browser ever since. (I’ve always had as many browsers as would work installed on my Mac to test things.) Lately, however, I’ve noticed that Firefox starts to get really slow after a week or so of use, and I’ve found myself stopping and restarting it periodically to get better performance.

I tried switching to Safari when Safari 4 first came out, but a couple of things moved me back: the “awesome bar”, which searched titles and the interior of URLs, and the NoSquint plugin, which remembers how much I’ve increased the font size on sites. (I also consider Flashblock an essential, but WebKit has the equivalent ClickToFlash.) When I saw that Safari 5 had similar functionality to the awesome bar, I decided to try switching again. That was Tuesday, and so far it’s going well. Or rather, it was until I started writing this post: ironically, the first time I tried to add the link to NoSquint, Safari crashed.

I haven’t found an equivalent for NoSquint, but the Reader feature has been working pretty well for me. Some people (like Ars Technica) have complained that this feature breaks the business model for most commercial sites, but all I have to say is, if you don’t want people to use the feature, make your site readable to start with.

BIG IRON: The Mainframe Story (so far)

It’s long (just over half an hour) and includes a lot of marketing/propaganda, and by the end I was really, really tired of the background music, but you might find some of the history and perspectives interesting.

(I find it curious that CA is doing as much if not more to push mainframe computing than IBM. I guess the people who took over after all the crooks were sent to jail decided that was a good way to mend fences with their customers.)

Adam wonders what I mean by a language “optimized for business programming,” and I can’t really blame him because I’m not sure myself. However, my thinking isn’t really going the direction he guessed.

It may be nothing more than “a language that feels familiar to programmers coming from COBOL or Natural.” Languages like Java and PHP have gotten a lot of leverage out of having a “familiar, C-like syntax” (even if I always thought that was like saying, “familiar, IRS-like customer service”) and there is probably some value in providing this kind of familiarity. My main motivation in suggesting a Natural-like language that integrates with the JVM or CLR was as a migration path for legacy Natural programs.

I have a feeling, though, that mere familiarity is only part of it. Most programming languages are developed by people with relatively strong mathematical backgrounds, and I have the impression that they are in some sense “too mathematical” for people with a strong business focus.

I don’t know if this would actually work, but here are some ideas about a “business-optimized” language:

• Give variables value semantics. While you can often ignore the issue, I suspect that variables with reference semantics cause problems for lots of people.
• Include tolerance for redundancy. Programmers are usually lazy (and in fact I think unwillingness to do extra work helps make for better programming) so in Natural we usually write “READ EMPLOYEES BY PERSONNEL-ID”, but we can write “READ ALL RECORDS IN FILE EMPLOYEES IN LOGICAL SEQUENCE BY PERSONNEL-ID”. Human languages have lots of redundancy for good reasons, and if we allowed more in programming languages it might help, at least in reading comprehension.
• Segregate higher-level abstractions from basic capabilities. We want a language with coroutines, functions as objects, etc., but it should be easy to write simple programs without dealing with them.

I realize that these ideas might actually make things worse, but who knows.

(In response to Ross’s comment, I would like to develop an Adabas library for Python at some point. I’m just not sure if that’s really best.)

Yesterday Adam wrote a post about learning new languages, which prompts me to write a few thoughts I’ve had about the programming languages we use at the University.

As much as I like Python and Ruby, they don’t come from the “data processing” tradition and these languages aren’t really optimized for business processing. About four years ago I suggested to Software AG that they develop a new language, like Natural but with a more modern foundation, and design it to run on the Java VM and Microsoft’s CLR, with hooks to call out to routines written in the other languages available on those platforms. Software AG hasn’t done anything with my suggestion (not that I expected them to) but I sometimes wonder what it would be like if they did.

(Sometimes I toy with the idea of writing such a language myself, but then I return to sanity.)

RAS is an acronym IBM likes to use a lot; it stands for “Reliability, Availability, Serviceability.” In general, it’s about how much you can count on a system to be up and running when you need it.

While we’d always prefer systems that were perfectly reliable and always available, getting there costs a lot of money. Part of designing a system involves trading off RAS characteristics against cost: if it’s OK for a service to be down for hours at a time, why spend the extra money for highly reliable hardware and software?

IBM’s z Series hardware and the z/OS operating system are designed for very high RAS, which is one of the reasons for their high prices. I think that we have many services on our mainframe that need this level of reliability, but there are lots of other services that are there because they have integration points with the mission-critical services. It would be really good if the business leaders of the University would try to categorize the various services provided by the mainframe according to how critical they are. Then, if we could solve some of the integration problems I mentioned in my last post, we could start running the less critical applications on less costly platforms.

This would also help us more immediately during registration and other times of peak capacity. Since we don’t have a big enough mainframe to meet the demand at these times, our only way of getting through is to stop some of the services. (By the way, why does last summer’s “mainframe efficiency initiative” keep getting touted as a success? We only made it through August registration because Jon turned off the Trim monitor on Adabas, which means we now have no way to diagnose database performance problems, and in January we did have to turn off services.) As systems administrators, we can’t really evaluate the relative priorities of different applications, so during crunch times we don’t know what to stop and what to try to keep running. In January we picked services that were timing out anyway (it seems safe to turn something off if it’s not working) but if that isn’t enough we really shouldn’t be the ones trying to decide.

(As long as I’m talking about RAS, I should mention that one of the problems we had with the migration assessment plan is that the hardware recommended is from a lower reliability class than the current mainframe. Multiple hardware vendors had provided specifications for candidate systems, but the one that made it into the report was the one that didn’t meet what we felt were minimum reliability criteria. Also, the other high-reliability systems didn’t cost that much less than a z Series machine.)

For administrative computing at the University, integration is one of our greatest strengths, but it also may be our greatest weakness.

Integration is a strength, because when different applications need to work together they do so easily.

Integration is a weakness, because when an application needs to change those changes must be coordinated with the other applications it works with. This is greatly highlighted when we consider possible projects like the proposed mainframe migration.

When I first started working here, integration usually happened at the Adabas file level. If application A needed access to application B’s data, application A was given appropriate database permissions. But now if application B wanted to change their file layout, it had to be coordinated with application A. Also, there are clearly security implications for this.

So we invented secured modules. This has helped with the security issues, but I don’t think it has decoupled applications as much as we might want.

Is there a next step, something to replace secured modules to decouple our applications more? Some way for applications to communicate more flexibly, so different areas can move in different directions more easily? Doing more with Broker might be one way, but at a significant cost in performance. Where one application is moving off the mainframe, Adabas Replicator might be a useful tool. Any other ideas?