What Makes Software Products “Enterprise-Ready”?

There are a lot of companies out there who claim their software or services are “Enterprise-Ready”. I’ve evaluated hundreds of products that make that claim. I don’t trust the term at all any more.

Your product has its obvious users. It fulfills its business role enough for people to pay for it. To be Enterprise ready you need to understand not just your customers’ sponsor & needs, not just the business users and their needs, but also a stakeholder role that is commonly left out by too many products claiming to be ready for the enterprise. It’s not just a stakeholder role, but also a third kind of user of your product. In my experience they are the people who support your product at your customers’ sites. They can make or break your product’s success.

Th most important “users” of your product are the ones who support it. If you make it easy for them they will have more time and resource to help the intended users, making your product more useful to your customer. If you screw these people you are screwing your own product.

Here are some thoughts about the subject.

Report who is using what and how much are they using it

Your customer bought your product to make a transformation in their company. The fundamental truth about making a transformation is the need to monitor how well it is spreading out, how much it is benefitting, how much it costs,where it is hot and where it is not. Your product should track this information and make it easily available to your customer’s Ops group. No enterprise likes flying blind.

Make it easy for your customer’s Ops people to know when your product is “healthy” 

You will actually have to either test your product at scale in your own shop or do it in your customer’s shop when in beta. You are not enterprise ready unless you can tell your customers’ Ops staff these things about your product when running:

  • Is it running normally?
  • Is it trending toward unhealthy and what is going wrong? Warn your customer before it breaks. What are the moving parts that cause the most trouble?  What can they do to reverse the unhealthy trend?
  • If your product fails, what was its internal state when it failed? Was it the server(s), the environment, out of spec use patterns, or your own code?
  • How do they know when it is getting healthier, like after a fix or a workaround? How do they know it’s working?
  • The 10 or fewer measurements that they can monitor to tell them this? – Yes, 10. No more. Health monitoring should not burden the infrastructure.

Understand how your product scales up or down

You need to make it as easy as possible for your customer to make a “right-sized” purchase. Like understanding your product’s health you will need to test to find this out. You may have an idea about this since the components of your product may have pretty well understood scaling rules, but it is the aggregate of all these components that your customer is paying for, and they paid you to figure this out for them.

Allow the enterprise customer to behave like lots of separate companies but maintain your economy of scale

Most enterprises are made up of smaller, internal organizational units which want to use your product in their own way, separate from others. On the other hand the central Ops staff need to manage your product in bulk, across the boundaries of those organizational units. This business reality manifests itself in your product. You need to get into those details and deliver. Some examples:

  • Unit bound Roles – Shield the behaviors of one unit’s users from others. Don’t let their actions affect anything within other units’ spaces.
  • Delegated Administration – let each unit manage their own users and roles. The folks supporting your project will be grateful since you will cut their operating overhead significantly.
  • Allow pull-down field values to be independent across units – One unit’s choice of filed value choices may not be the same as other units’. This is especially true for any workflow management enterprise products. It is amazing how differently units will name the steps in an otherwise universal process.
  • Separate as many Processes as possible – simply put, don’t let one group’s actions crash another’s.

Security, security, security

Take this seriously. Integrate with all the authentication & authorization systems available to the enterprise. Publish all network-based data paths, their protocols, port, content and connection requirements. If you use common,”firewall friendly” ports then encrypt the data before going over the wire. Just build it in.

Create friendly, modular, quick-to-consume, online training packages that are easy to access by your customers

The more time it takes for users to ramp up and be productive using your product the easier it will be to sell. Many corporations are cutting back on their training budgets and assuming that their employees will train themselves. You do not want your users to get it wrong. You want them to get it right and keep up with their normal workloads at the same time. Remember, while your product may be used for very technical or specialized purposes, you are safe to assume that your users will already understand the knowledge domain it serves. Your product is their tool, so make it easy for them to learn how to use your tools.

Of course many companies need to hire or train their people on the domain your product may support also, just so they can start using your tools effectively. You may have to extend this training paradigm to educate users on the domain as well as the tools. You may need to make their training a major component in your overall business plan.

More? Of course!

But I’d like to get this posting out today. I’ll open up comments for this post. Why don’t you tell me what you think are important features for a product to have before it can call itself “enterprise-ready”?