A manifesto for purchasers of Enterprise Software

Rationale

Enterprise software is one of those vague terms which vendors like to throw around in order to add credibility to their offerings when selling into large organisations. Given the huge range of software which is branded Enterprise, it's hardly surprising that the only thing they all have in common is some claim to be useful and usable in large and complex corporate environments.

As a result, the term ultimately means little of use. It certainly doesn't guarantee that the process of installing, running, and keeping current a large environment will be made as straightforward as possible, or even that the realities of enterprise operation will be at the forefront of the vendor's product strategy.

But it should.

Over the years, I've attended numerous meetings with vendors, in which I bring up specifics of how the product makes life unnecessarily difficult for us. Sometimes the reaction is positive, with a genuine desire to understand better the realities of our environment. Sometimes we get a brush-off. Occasionally, there are signs over time that lessons have been learned. And for any particular concern, there's always somebody who does manage to get it right, proving that we're not asking the inpossible.

It occurred to me that the only way to change things would be to put together a realistic set of criteria that any Enterprise offering should meet, and to get enough support from a range of customers to make the vendors pay attention. The list below is just a start - it's intended to prompt debate, from anyone interested whether a vendor or an enterprise. There's no mention of specific products, and it has nothing to do with the core functionality of the product and whether it's fit for purpose - that's an issue which applies at all scales and has no unique Enterprise dimension.

The list of demands ( in no particular order )

Product lifecycle issues

• Enterprise software should be as much about ease of change as functionality. Each new version of the product should:
  • Not be announced until it is fit for purpose.
  • Be fully supported for at least three years.
  • Have a well defined and efficient path for upgrade from at least all point releases of the previous version.
  • Avoid the need for complete data dump and restore.
  • Client/server architectures should allow the new server to operate with the old client so that client upgrades can be phased in, or even better, guarantee a seamless automatic upgrade of the client as required.
  • If something does go wrong with an upgrade, there needs to be a credible reversion approach.
• Any non backward compatible changes, in particular loss of functionality, should be phased out gradually over several releases, and not just disappear.
• When a product undergoes a fundamental transformation, it may be infeasible to achieve all of the above. In these cases:
  • The vendor needs to provide clear advice and tool support to mitigate the effect of incompatible change.
  • They need to continue full support for the older version for an extended period - at least two years following the introduction of the new.

Product architecture issues

• Network protocols should be chosen to allow efficient operation between WAN-connected sites with poor latency characteristics.
• If the product is built on top of third-party components such as databases, web application servers etc, these dependencies should be clearly defined, in particular with respect to which such products are supported, roadmaps for support of new versions of such products etc.
• Product configuration should be implemented in such a way that the system's deployment topology can change over time without forcing a complete reinstallation from scratch.
• It must be possible to test the product, including product upgrades, in non-production environments using real data. So there needs to be a way of 'cloning' a system into a development environment.

Administrative concerns

• Multiple sites should be capable of administration either individually or in groups through a central site
• Administrative permissions should be fine-grained enough to satisfy any regulatory requirements governing data protection etc in global environments.
• Individual user account authentication should be delegatable to a firm's existing user account management/ single-sign-on infrastructure.

Reliability and monitoring

• If the product supports plugins, or is a container environment for separate applications or components, maximum protection should be provided against badly behaved code in such plugins and components, and decent tools are needed to allow the testing and isolation of suspect or new components.
• The available telemetry should include not only detailed monitoring of working systems but also full post-mortem capabilities to identify what went wrong after the event without relying on separate products whether third-party or otherwise.
• The logging and tracing levels required for normal (production) operation should have minimal impact on performance.