Entering the Enterprise
Building software for the big players is not easy.
There are so many, many factors involved in getting a piece of software into wide adoption at an enterprise. The need has to be there, the timing has to be right, the budget has to be right, and relationships have to be established. Oh, and the actual product needs to be at full sail from the start. Yes, that little detail too.
Your product or service pretty much has to kick ass to have even a chance up at the enterprise level. Everyone wants to be there because that is where the big money is. True enough, but you also have to pay the price to be in that ballpark. To whit, you need to have:
Let’s look at these in more detail.
In the movie The Hudsucker Proxy, the Tim Robbins character goes around drawing a circle, showing it to people and claiming, “You know, for kids.” He just seems a bit crazy, and no one knows what his purpose is. Eventually out comes the hula hoop, and history, at least for kids, is forever changed. Since his purpose was not clear, no one knew what to do with a drawing of a circle.
Likewise, in the boom days, I worked at a calendaring company where our focus was never clear. I felt like we were going around saying “you know, calendars” and of course everyone looked at us funny because you need a purpose behind the calendar. It needs to be very clear what the benefit and use of your product or service is.
This is no surprise. Your product should work. I have actually been at places where this concept was entirely lost. There was a deadline of course, which for whatever reason outweighed all other concerns. They launched the product with over 700 known bugs, and let me tell you, if you have that many you know about, there’s probably twice that many you don’t know about.
A different product I worked on made routine use of either not checking return codes, or just not issuing any to begin with. In the normal course of events, everything worked fine, and this was not a problem. But in the enterprise space, under stress, errors would happen for different reasons, and the client would get orphaned database records. Lack of integrity in your data is a big no-no and makes clients unhappy. Trust me on this one. You have got to be able to handle errors because you are going to run into things you never expected.
The enterprise is a sure-fire crucible for putting your scalability chops to the test. Just saying your product is scalable is not enough. Just running ten times the amount of data through that you expect is not enough. I ran into a scenario where we were bulk loading new users into the system, and, kaboom, it died with an out of memory error. Now we’re talking about 70,000 users, which, sure, is a big number, but in the scheme of computers, really isn’t that much. Whoever wrote the code must have been expecting like seven users, tested it for maybe 70, possibly 700. But if you happen to loop over those user records and accumulate a string with each user seventy thousand times, the string gets big and eventually you hit a wall. This code was just badly, badly written without any regard for scaling. Part of your entry fee needs to include data coverage and stress testing.
This one should seem pretty obvious. Sadly, apparently it is not. At one enterprise I was at we brought in a package and watched it slither slower than a sleeping snail. We dug and dug and found that there was a file open call that was made over 13,000 times. For one request. On our networked file system, yeah, it sucked, to put it mildly. What should have been one file open and a cache instead resulted in an unusable product. Completely unusable.
Another company I was at would launch over one thousand database queries for a single request. I can understand tens, maybe hundreds, when you factor in the data, related items, permissions, access rights, workflow issues, and so on, but a thousand is just negligent. Just for the record, enterprises don’t like this. No one does.
The need for solid documentation is never going to go away. It doesn’t have to be a user manual. It could be onscreen tool tips or a tutorial. The key is that even after training sessions, people forget things, and they will need a reference point sooner or later. You want to remove every possible barrier to use that you can.
When it starts raining nails, you need people with iron umbrellas. If an enterprise is counting on your software to work, and it doesn’t, uncomfortable phone calls get made. You need a crack team that can respond to critical issues in a timely way. Sometimes this means having the actual developers available as backup.
Whatever your game, it needs to look good. Not looking good is a sign that you don’t care, didn’t have the time, or didn’t have the resources to give it that nice shiny finish coat. If you don’t care, how on Earth is the client supposed to think they should plunk down serious money?
At one place we had some great technology, super proprietary stuff. It was robust, fast, and scalable — it’s main feature. But it was ugly. Getting the thing running took the expertise of crawling through cob-webbed corners and knowing at which stump in the road to turn right. We could have given it the polish it deserved, but it would have been a very large effort. As such, it did what it was built to do internally, but never made it out the door.
If your mouse trap doesn’t have everything listed here, chances are it is not ready for the enterprise. You might be able to sneak your way in if you are missing an item or two, but most likely in the long run it will catch up with you, and when it does, it is going to hurt. If you want to play with the gorillas, do your homework. Run the performance tests. Make sure you have data coverage. Try some crazy random things and see what breaks. Then, and only then, step into the enterprise jungle with your gleaming trophy.