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 others quickly responded that their tools were already being used in that capacity, therefore, they were “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 compliance. 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 willing 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 company’s 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 felt 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 interoperable library doesn’t require such things?

• Lock-in
  If packages of code do not work well with other packages of code and somewhat force the use of tools created by the same entity, this is known as “vendor lock-in”. Thinking back to the days before open source became viable for common use, I can’t help but remember struggles with IBM, Microsoft, Oracle, and others. If one of their tools was used it required me to use others, resulting in even more costly licenses.Even when software “appears” free, “vendor lock-in” can exist, and this leads toward limiting options in the long run. Enterprises are finding that less “vendor lock-in” in their applications means they can make better decisions and pivot faster. Therefore, monolithic frameworks and packages are becoming undesirable in the Enterprise. Decoupled middleware, microservices, and frameworks are the desired flavor of Enterprise Ready.

  I often speak with companies who say things like, “We want to switch to another framework, and we’ve chosen X.” But yet they can’t substantiate “why”. They use terms like “open” and “popular”, which prompts me to help them create a solid list of pain points leading them to their decision. Usually, we find the framework they were choosing will yield the same pain they desired to leave behind. The number one pain point is typically vendor lock-in.

• Contributors
  Another very important consideration among Enterprises “in the know” is the number of active contributors to a given software package.More contributors mean more eyeballs on the code and often result in fewer bugs and security issues in a given package. And for Enterprises, it can also mean bugs get fixed faster, or new features get added more quickly.
• Bus Factor
  The term “bus factor” is a rather cold term describing if the leaders are hit by a bus, and what the effect on a project would be.  If a popular package has a single “head”, and that person were to disappear for some reason, would the package continue without that person’s vision, drive, and direction?I know of many popular PHP packages that have plans in place to facilitate such a tragic event. The more popular a package gets, the more important this is. Of course, having such a plan doesn’t always mean the “bus factor” has been avoided. Often the leader is the glue that keeps it all together, and disruption can lead to the death of very strong communities. However, it is important to ensure these plans exist for true Enterprise adoption.
• Documentation
  No matter how great a package is, or how widely it is adopted, documentation is important to ensure developers can use the tools provided. Some have said that a good developer can read the code and figure out how to use a framework, but that is not what leads to widespread usage. In order to gain true market share it is vital to have great documentation making it easier for anybody to use something.A truly strong community helps in this area and is self-fulfilling, as good documentation leads to more usage, and more usage leads to a stronger community, which aids in the creation of better documentation. Companies are more likely to use a package if documentation helps their developers create faster.
• Support
  Despite how good documentation is, occasionally we all get stuck and need a helping hand. Eventually, for a great package to be leveraged by Enterprise it is required that an Enterprise can somehow reach out for support. In the early days of a library, this could simply be blog posts from “fanboys”, but for widespread use in Enterprises, it may mean more interactive things like phone or email support, consulting, and a “throat to choke” if things go wrong.Good support is multi-pronged: support boards, email, consulting, “fanboy” network, outside agencies available, and other forms of community forums.
• Compliance
  If a package is performing activities with a database, filesystem, personal information or content, encryption, and authorization, there may be regulations in place that Enterprise level companies must be in compliance with.It is important to Enterprises that the code they will use also be compliant, or at a minimum make it easy for the company to remain compliant while still leveraging the package.
• Longevity
  We all like the new and shiny. However, for Enterprises, this can be a negative. They require things to be a bit more tested, and “aged” in some cases. If a library has been around for a while it can mean a more mature API, fewer bugs, more security, and better documentation and examples.At the same time, if a package has been on the same version for too long it can also indicate stale and/or dead libraries that will someday no longer be supported.
• Upgradeable
  How easy is it to upgrade the software from one version to the next, or how easy is it to upgrade from another library, are considerations prior to using a software package.

  Many leading packages go to great pains to prevent breakage between versions and provide documentation to allow users a step-by-step process for migration. I’ve even seen some create tools that handle the necessary pieces. A company must consider the past track record of a package prior to usage.

• Roadmap
  Enterprise applications tend to stick around for a very long time. It is easy to find applications that have been around for 10 years or longer in some companies. Therefore, one thing companies look for is an accurate and active roadmap.

  A roadmap can indicate if there are good ideas being developed and if there are major changes coming in the future that a company may need to be ready for. It can also indicate when a package has lost its way and is no longer paying attention to its users, and an exit may be a good idea.

  In any way, a good roadmap is an easy way to keep Enterprises informed.

I hope you found this post informational. Many developers struggle to understand what defines “Enterprise Ready”, or even why it is a thing to be considered. While there is no definitive list, I have attempted to share what the many Enterprise level companies I’ve consulted with look for.

If I think of more points, or if others share something I feel is important enough, I will return here and update this.