B2B Analysts
About the Company   Services   Research   Pressroom  

Spotlight on Innovation

Newmerix is trying to do something about a big problem: the huge number of patches that flow continuously out of the big application companies.

Their first product, now in beta, is focused on PeopleSoft. Essentially, it is a suite of patch management and patch testing tools that allow you some measure of automated control over what had been an entirely manual process.

It is not widely known, but most application companies put out patches that can have significant and unpredictable effects on functionality as often as once every two weeks. To keep up, any company with a large ERP system must be continuously installing and evaluating the patches.

It is difficult to overstate the nastiness of this problem.

You see, what you get from the software company is simply some code and a list of programs or objects that are affected by the code. (This list can include hundreds of different items.) But that doesn't tell you what the patch does at a business level. And even if it did tell you (sort of), it won't tell you what it does to your system, because you've got customizations.

So you literally have to install the patch and sit down and test everything that has a remote chance of being affected.

Now you might think that there are things called test scripts that enable you to do a lot of this testing automatically. Isn't that what companies like Mercury sell? Wrong. You can't easily use the standard programs like Mercury on business applications because what you're trying to test is how the program affects business processes, not whether the program works.

In fact, the way Newmerix tells the story, the Newmerix people started out in the automated script management business, but realized that the application market is poorly served by this kind of software, and decided to build something different.

What they've got is still new and untested. (They're looking for beta customers.) But the approach seems to me right. A lot of it's pretty simple stuff, I have to say.

The first component developed, Program Manager, just tries to set up a system for managing the patching process. A workflow, audits, reporting of test results, records of what was installed. It's really just making tracking simpler.

The second component (still in development) addresses what I've always thought was a major problem: managing test scripts. You see, you typically have to change a script in order to test a patch. What you need, therefore, is to track changes in the scripts and tie them to the patches.

There are things which I still don't understand how they're going to address. One of the big problems in regression testing of patches is that the underlying data changes. If you're doing forecasting, for instance, your prediction algorithm tells you what sales will be in the future. But every day, the future moves one day forward. So as you test, you either have to set the date on your computer back, so the data predicts forward to the same day each time you test. Or you have to keep on putting in new data.

Neither is very practical. So what people do is just to use the same database and have the underlying data change. This means that regression tests are unreliable. But what are you going to do?

Clearly, one thing you could do is persuade the software company to be more disciplined about their release of patches. Releasing patches every two weeks is just a way of shifting costs to the users, and users already pay a lot in maintenance. But until that happens, maybe Newmerix will be a sort of latter day Army Corps of Engineers, which builds a concrete ditch that can at least contain the flow.

If you do take a look at Newmerix, let us know what happened. But it does appear to us as if this really could help.