20 Years of ERP/CRM Deployment Options

Rewind: The 1990s

A short history lesson on these business application publishers: in the 1990’s, most existing and new software publishers built their business software applications to overcome the connectivity constraints most of their customers encountered at that time. Most organizations had either no or almost now external connectivity and if they did, it was VERY expensive. Internally, most organizations had slow networked connectivity as well.

As a result, “client-server” applications were developed to take advantage of the processing power available at employee’s desktop computers to lighten the amount of traffic being delivered over the organization’s local area network (LAN). For these types of applications, the end user’s interface to the application was typically driven by the user’s local workstation, as was some part of the processing required to run the application’s business logic. The application’s database and the rest of the business logic processing was then done on one or more servers with data and calls being made over the LAN.

A smaller segment of software publishers had all the processing done on an organization’s servers and limited the amount of traffic going over the LAN by transferring only user commands to the servers and graphic updates from the servers to the users’ desktops. This type of setup required very fast centralized processing power, which was fairly expensive.

Rewind: The 2000s

In the early 2000’s the first of the “SaaS” (software as a service) options were debuting using the latest technology, at that time, to provide public hosting only subscription services to their clients. To keep processing and storage costs low, the publishers of these services created “multi-tenant” business applications that could only be accessed via the publisher’s public cloud. Multiple customers could securely run the same business logic being used by non-related organizations and store their organization-specific data within the same database instance as non-related organizations.

Great economies of scale could be enjoyed as more and more customers were added to the publisher’s public cloud. Downsides, however, were that changes to the business logic (i.e., updates/upgrades to the back-end application) would affect ALL organizations at that same time and there were no methods to easily move to another deployment option.

Ever have a challenge find a date to have a holiday party for your organization or team within your organization? Well, imagine how likely it is that the date and time the SaaS-only publisher chooses to down their application in order to perform updates/upgrades/maintenance will not adversely affect some of their customers? Not too likely is my guess.

These SaaS-only vendors are, by definition, NOT in the business of helping their customers move their data, much less their data and business logic to an on-premise or private cloud deployment.

These business application publishers bet on the fact that a public cloud

Today: There are choices, make sure you know them all

The good news is that many of those client-server applications from the ‘90s have not only matured in terms of functionality and feature set, many have also expanded their deployment choices. Most business applications that can be deployed on-premise can also be hosted in a private cloud.

Most, not all; be sure you check whether yours can be. A smaller number of applications that were originally developed as on-premise client-server applications now offer “thin” or “zero” footprint client interfaces to their public cloud service. Again, some, not all; check today whether the on-premise applications you have today have both private and public cloud options. If they don’t, identify replacement applications that do.

The same holds true for hosted applications and Software-as-a-Service applications: make sure that there are on-premise, private cloud AND public cloud versions of the service available and that you can easily move from one to another with your data intact. Feel free to laugh at SaaS publishers who tell you that “it’s not a true SaaS unless it’s multi-tenant (i.e., everyone uses the same business logic instance and/or database instance) and it’s only available via public cloud”.

Today’s “true” solution is one that is architected to be able to work on premise, from a private cloud or from a public cloud. Demand no less; if you do, you will be putting your organization at risk.

Leave a Reply

Your email address will not be published.