When this showed up in my RSS reader this morning, my first response was, “wait, today isn’t April 1!”

Emotion Markup Language (EmotionML) 1.0

Apparently it’s serious:

As the web is becoming ubiquitous, interactive, and multimodal, technology needs to deal increasingly with human factors, including emotions. The present draft specification of Emotion Markup Language 1.0 aims to strike a balance between practical applicability and scientific well-foundedness. The language is conceived as a “plug-in” language suitable for use in three different areas: (1) manual annotation of data; (2) automatic recognition of emotion-related states from user behavior; and (3) generation of emotion-related system behavior.

I’ll believe it when I see it.

I just want to point to Ross’ response to my last post and Adam’s: Asking the right questions.

My nomination for the right questions (or some of them):
“What kind of ERP would help us make the right decisions?” (this does not only include Business Intelligence tools, but also almost everything that an ERP does)
…my answer to that, if you believe it, leads to…
“What kind of IT structure (people and equipment and software) would allow those collecting (or making) data and those making decisions to have a shorter chain (of people and processes) between them?”
“What kind of IT structure would enable for easier/more rapid modification to accommodate more rapid changes in the objectives of decision makers (e.g. switch from other objectives to budget cuts)?”

All good questions, although I’ll add that from the perspective of his job Ross focuses more on decision making than I would. Beyond decision making, our ERP needs to make sure certain things (like payroll) get done correctly and on time.

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.