A model development process

In today’s IT environments, there are very few islands of self-contained applications left. Enterprise applications have many interdependencies. They are integrated with middleware, databases, legacy applications, and other software.

Computing has, in fact, become so complex that reverse engineering applications in order to troubleshoot problems is getting near impossible.

Ed Shepherdson, vice president of global support for BI vendor Cognos, tells me that when his analysts get support calls, they go through a minimum of 20 questions: “What patch level? What database? What services are running?”

Finding answers isn’t always easy. For example, the support staff for the application server won’t necessarily know what version of the database is in use, and the documentation may not reflect changes made by the DBA.

But take heart. There’s news from a system management company called Motive that will have you humming Irving Berlin’s “Blue Skies.”

Motive likes to claim it sells “self-management” software, a phrase I’m sure would make most support managers gag. Nevertheless, Motive is doing something worth looking into for companies such as Cognos that build products for the enterprise.

Gartner’s Cameron Haight, a research vice president, says what is unique about Motive is that its approach to maintaining high levels of application performance and availability focuses less on data collection and more on developing processes.

But I believe the bigger news is the idea of linking application developers to the people who will provide support and operational management, and doing so while the applications are still being built.

“Typically, the developers finish the application and throw it over the wall,” says Mike Maples, a Motive founder. Instead, Motive’s software lets developers model the application in question, its components and dependencies, before handing it off to customers and support staff.

The model says a number of things. When it comes from the application vendor, it describes an optimal configuration. But Motive also allows enterprise IT staff to take a snapshot of the application while it is already running, to generate a model that describes it in its actual, current state.

You can also take a snapshot of what it looks like when things start to go south — and here’s where self-management comes in. To Motive, self-management, or self-diagnosis, means being able to diagnose application problems by comparing configuration parameters with the base model. According to Maples, support staff can use this process to track changes in an application and identify the errors that caused it to fail.

BEA, Hyperion, and others have already begun incorporating Motive’s model builder into their products. Earlier this month, BEA announced it will integrate Motive’s application into a version of WebLogic Server — a very good sign.

I think Cognos’ Shepherdson describes it best when he says that, in typical IT organizations, the vendor’s application is managed from inside the enterprise. What Motive does is give IT shops a vendor’s-eye view of their applications. Shepherdson foresees a future where vendor knowledge is coordinated with system-management knowledge.

Your support staff may never really sing “Blue Skies,” but with a more holistic approach to software development, perhaps they’ll at least be singing in the rain.