What is Enterprise Ready?

First, let me clarify, this post is not about Star Trek and the starship we’ve all come to know. Further, this post is not to attack any one group, and rather is my (perhaps poor) attempt to help others gain some visibility into what large companies (Enterprises) do, or perhaps should, look for in software prior to using it.

The Backstory

I saw some rumblings over the weekend between various communities where members of one were accusing another of not being “Enterprise Ready”. Of course, the other quickly responded that their tools were already being used in that capacity, therefore, they were indeed “Enterprise Ready”. (If it swims like a duck, it must be a duck.)

Following this I saw many more statements from various folks saying, “We are Enterprise, and we use it, and it’s working fine.”, and “What is ‘Enterprise Ready’ in any way?”

I’m sorry folks, but just because a company “can” or “will” use a given tool doesn’t mean they “should”, and it certainly doesn’t mean a given tool is indeed ready for use in companies reporting to shareholders or having requirements to meet certain compliance thresholds.

The Risks

There are no definitive guidelines to clearly state what “Enterprise Ready” really means, and there are certainly no lists of which applications are, or are not, Enterprise Ready.

Sure, there are different regulations for security, legal, and financial compliances. But even these only scratch the surface and do not clearly define what can/should be used. Especially when it comes to the many open source software packages available.

In many ways, it can come down to what a company is comfortable with. How much risk they are open to accept. And in some cases, how much liability they are willing to ignore and/or absorb when things go sideways.

On other fronts, a companies choices are led by the future. Large enterprises try to plan ahead because they know it is hard to change later down the line. Choices made today are often carried for 10 to 20 years, so it is very important to ensure they do not get caught in the trap of using tools lacking support and/or no longer getting security updates.

How It’s Made

I consult, and work directly with, some of the largest companies in the world every day whom I consider “Enterprise” in size. Since there are no pre-made lists of tools that are definitely “Enterprise”, I will share what many of these companies look at when choosing a tool or software, prior to allowing it to be added to their portfolio for the next 10 years.

The Requirements List

So, off we go:

• Licensing
  If software/code does not include a license, companies and developers can’t use it. Making code public doesn’t automatically make it open for others to use. By default all code is subject to copyright and private.

  Also, in the same vein, adding an open source license doesn’t mean everyone can use it. Each open source license carries certain criteria which can prevent companies from using the code behind them.So, be careful to understand the ramifications of the license applied to a software package.

• Interoperability
  Enterprise level companies have lots of software/code. I often see 4+ million lines of code in applications, not including 3rd party code and frameworks. This means that libraries must be able to work together in order to be used.

  In PHP, the PHP-Fig has worked hard for many years in an attempt to create conventions that, if followed, allow PHP libraries and frameworks to work together more easily. Therefore, Enterprise level companies tend to use code that follows the many PSR standards set by this body. Meanwhile, tools that do not follow these standards, regardless of how awesome, are rejected by Enterprises.

  Ask yourself, why should a company create internally maintained wrappers to facilitate “vendor lock-in” when another library doesn’t require such things because it is already interoperable.

• Lock-in
  If packages of code does not work well with other packages of code, and somewhat forces use of tools created by the same entity, this is known as “vendor lock-in”. Thinking back to the days before open source becoming viable for common use, and I

Truncated by Planet PHP, read more at the original (another 6648 bytes)