So you think you’re enterprise class?

We’ve all known the person that believed they knew everything there was to know about topic X. In IT this person is so commonplace that I have wondered if there isn’t an advanced cloning device that spits them out on a daily basis. While this self confidence (or bravado, whichever) in the right individual, at the right time, has done some amazing things in world history and specifically in the history of computer science, most of the time it is merely annoying. When any attempt is made to explain even what the individual doesn’t know, they tend to walk away thinking you’re too dumb to understand. That passes annoying and enters dangerous. Not dangerous in the sense that someone is going to get hurt, but dangerous in the sense that this person with incomplete knowledge and overweening arrogance is working on your IT systems. Without the complete picture.

In my experience, the in-your-face “I know everything” person rarely does… Though I knew a really annoying UDB guy who really did know everything. He could do just about anything with UDB, if you could convince him it was important. He saved my project timelines more than once, because I sat through his “you’re an idiot” tirades to get him to do what needed doing. And everything he did was right when he was done. But he is the exception. I have far more anecdotes of people who had a chip on their shoulder and it wasn’t warranted. Including being lunged at in an interview I was conducting when the interviewee got a question wrong and I tried to explain why to him. I didn’t hire that guy ;-).

In IT – in business in general - it really isn’t acceptable to be this person. And yet they seem to exist at every level.

For the last few nights I have been working to get an open source library working in my environment. Normally there is nothing to this process when Java is the language – that is one of its strengths, but there were several sticky problems with this one, starting with corrupt jar files, and ending with incoherent documentation. In the end, I decided that there were other ways to tackle this problem and I had wasted enough time on the library at hand. Part of my decision absolutely was the mentality of the developers on the project. One person had posted to them “I must use Eclipse, because that is the standard for my team, and X isn’t working”. Guess what several of the developers answered? “Don’t use Eclipse, it’s stupid” (paraphrased because they’re amalgamated). NOT. HELPFUL. This poor guy was left on his own because their new “environment of the week” was all they cared about, and the vast bulk of Java developers still using Eclipse were “stupid”.

You see the same types of answers – even from commercial products – about which browser you’re using. Even today.

It’s a decade into the 21st century, browser wars hurt your organization/project, do not let your people tell enterprise customers to change toolsets, support them or don’t.

Most enterprises want a few things from products they use. Provide them, and whether open source or commercial product, they’ll use your tool when it solves their problem.

1. Stability. The product needs to be stable, and if it isn’t, complaints need to be handled with tact. Nearly every IT product suffers stability problems at some point in its lifetime, so the tact part is very important. Tell them to do things your way, or imply that they’re stupid, and they will replace you. Maybe not today, but they will.
2. Enough users to warrant taking a risk on your product (assuming your product is new to them). You can’t make up for users with bravado. Attract them with quality and a helping hand, or you won’t be enterprise class.
3. Quality documentation. It no longer matters if your documentation is a big-old printed bundle, a PDF, or even a website. Most larger organizations use a mix of all three, in fact. What matters is that it exists and is usable. This is where a ton of open source projects lose out to commercial competitors. And another problem that has been around forever, and yet most don’t get. For commercial products, this is most often a problem when documentation is translated. Seriously, spend the extra money when moving it to a new language, and get the best translation you can.
4. Support. If the people supporting your project are the dev team, you have a problem. The dev team (be they open source or commercial) believes they made a great product. That belief colors their responses. This is worse in open source, because they don’t have to worry about their jobs, so they make loud statements like the above “don’t use Eclipse” one. But no matter how small you are, or if you’re all volunteer, you must have either great documentation or a support team that is capable of listening and driving solutions. I would argue in the case of APIs or libraries, you need both, simply because people are going to put them to uses you never envisioned.
5. Longevity. Most (but certainly not all) products adopted into enterprises have been around for a while, and have good prospects of being around well into the future. Companies have failed because they couldn’t convince customers their stuff was going to be supported for years, and one need only look at the content management OSS world to see what splitting teams and branching source trees can do to pretty good open source products. This one is harder to fulfill than the ones above, but conveniently, the previous longevity is less important than the prospective longevity. So if a lot of people are talking about how cool the product/project is, this one can be met as easily as the others.
6. References. In recent years, this requirement has become so simple that it is almost overlooked… A prospective user can go online and find out what others are doing with a product, how they like it, etc. Good relations with those using the product works. All of the above build these, not just with early adopters, but with a growing base. Several really cool technologies/products have done a smashing job of winning early adopters, then failed when the general market tried to hop on board, and the above didn’t exist in consumable format. Soon the early adopters are drowned out by disappointed general users, who don’t have the time to invest that early adopters must have.

Now, I get the fact that many open source projects don’t care if they’re enterprise class, but a lot want users, and are making projects most useful in the enterprise. And these points have been known forever. I didn’t invent them, they’re what enterprises have looked for in the bulk of their projects for a very long time.

So one is forced to wonder, why are both commercial and open source products still failing on these points so often?

It’s easier to see how/why in open source. No matter how much I’d like to argue it, as a geek who also writes, the type of person who is qualified and motivated to work on an open source project is often not the best choice for talking to users and helping them understand… And yet they are the ones doing it. For developer oriented projects it gets worse, because the early adopters are often not patient with people who don’t “figure it out”, amplifying the issue. Linux is the poster child of oss projects that survived this stage of life. So many people were out there acting like you were an idiot if you couldn’t figure out X or Y or Z, and had no concern at all that their attitude turned more people away from Linux than the initial learning curve did. For every Linux though, there are thousands of abandoned projects. Recruit someone on your project who is technically competent, but can write. Get them involved, have them do the documentation. Please. For your sake and all your potential users’ sake. Better, get them to gather ideas/plans for the future and turn them into something digestible. And get them out on places like StackOverflow to answer questions. Essentially, bring in an evangelist.

In commercial products (including the OSS/commercial hybrids) it is a little more complex. Companies have to care about income streams and how to be successful. Money and resources must be funneled toward that end, and that sometimes means product X or Y or Z doesn’t have the above, because there just isn’t time or money to invest in them. I guess my recommendation to enterprises in that case would be to look for another supplier. It’s tough to walk away from a great solution because it doesn’t have some of the above points, but if the “great solution” breaks and there isn’t decent support for it, well, then it’s not such a great solution. The same is true of the other items in the list. Lacking them is a sign the product you’re considering is not ready for enterprise level use.

Just my thoughts on the topic. In the end, it’s your enterprise network/dev environment/apps, you absolutely should do what’s right for your environment. And yeah, I have once or twice chosen projects/products in the enterprise that were missing one or more of these items, either because the options were limited, or they were so good at what they did that I figured they’d catch up with the other stuff long before they burned out.