|
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.
|
