Is Your Software Ready for Enterprise Customers?

I've been doing this data and software stuff (to use a technical term) for 20+ years. It's closer to 38 years, but all my bios say twenty-plus because I don't want to feel that old. Reflecting on all the software I helped acquire or use in enterprise environments, my perspective on what "enterprise-ready" means has changed.

In 1986, nearly all software was designed and deployed as a stand-alone product. If you wanted it to work with other software, you likely moved the data from it to another application. Export and Import. Save and open. Integrating systems was mostly about data movement. Almost all of that was a custom, manual project. We even had organizations that specialized in being system integrators. They ensured that all these hardware, network, and software systems could see facts consistently. Mostly.

The advent of database systems changed that a bit, as data could be queried by many modernized (at the time) applications so that it didn't have to move around as much.

What did Enterprise Software Mean Back Then?

In my mind, "enterprise" meant systems:

• could scale beyond a handful of users
• had some sort of native backup feature
• were managed more by experts in those systems
• maybe complied with some industry standards for data exchange or security
• had licensing models beyond "cost to buy a set of floppy disks in a box"

I'm sure there are many more bullet points here, and I'd love to hear them in the comments.

What Does Enterprise Solution Mean Today?

So much has changed over these decades. I started to write a lengthy list of bullet points. However, having attended several startup briefings over the last few years, I realized that my definition of enterprise infrastructure, data, and services had shifted from solution design traits to how it worked with other solutions. Sure, I have opinions about the design decisions inside a solution, but how it can be used in an enterprise environment is much more important now.

Someone on a forum said, “If we cannot source control ALL artifacts and cannot automate deployments, the platform is not enterprise-ready.” just an hour after I was trying to describe what I meant by enterprise-ready, Seeing those words on the forum was a perfectly timed gift. I am applying more and more weight at solution acquisition time for how a solution can be part of our enterprise architectural framework than what is going on inside the solution.

If we cannot source control ALL artifacts and cannot automate deployments, the platform is not enterprise-ready.

So, my new bullet point list:

• can our current management tools manage it?
• can I connect to it using other tools via a published connector?
• can I deploy it via my current deployment tools?
• can I govern it using my current governance tools and services?
• can I monitor and alert to keep it running using enterprise-class tools?
• does it follow standard security practices and use my identity solutions?
• can all its artifacts be managed in our current versioning tool?
• can the data it contains be classified and labeled?
• can those classifications be used outside that system?
• can classifications outside the solution be used inside the solution?
• can I use my enterprise analytical tools with the data it contains?
• can I use my analytical tools to get insights about events and metrics of the solution?

I could keep adding to this list, and I welcome your additions as well.

What Does This Mean for Developers and Vendors?

If you want to meet the needs of a modern enterprise framework, your products need to be manageable by modern management solutions. It's no longer about writing a great software product. If you want to be a player in the enterprise world, you likely need to understand what enterprises need to lower their costs and risks of using your product.