Enterprises frequently fail to consider cloud-based applications because they have customization requirements to implement, and they assume the cloud will somehow prevent them from customizing their apps.
Customization of applications is sometimes necessary for users who require special functionality beyond an app’s native capabilities. In other cases, users will find it necessary to customize applications to more closely align the app with the enterprise’s operational requirements.
In either case, the assumption that cloud-based apps cannot be modified or customized is simply unfounded.
The decision to customize an application will often result in consequences that will be felt far into the future.
Should Applications be Customized?
Before we even look at how cloud and customization might work, the question of customization needs to be carefully considered.
As a recent piece in InfoWorld points out, just because you can do something, doesn’t mean you should do something when it comes to going forward with application customization.
The decision to customize an application will often result in consequences that will be felt far into the future. Once an app is customized and made “non-standard,” there will be support and maintenance issues for both the vendor involved, as well as the internal support structure of the enterprise.
Changes to the host operating system, adapting interfacing applications and other factors, such as support processes and training manuals, will all need to be addressed.
Regardless of the decision to customize or stick with the standard app, the decision to go cloud or on-prem should be considered separately from one another.
The Myth of the Immutable Cloud-Based Application
Old ideas die hard, and the myth of the immutable cloud-based app is a great example.
Years ago, vendors that were publishing software applications had to make some hard choices. One of these choices was to choose which operating systems their application would support. Mainframes, Unix, VAX, MS-DOS, Apple and myriad client-server environments built around many different operating systems were commonly in use within enterprises.
Vendors also had to make choices about which systems their product would be adapted to for sale. Each operating system represented a specific market segment.
The idea of hosting the app and offering it as a measured, consumable service removed much of the need for individualized operating-system-centric versions of the application. This took the vendor off the hook as far as making that choice to include or exclude specific operating systems.
SaaS and the Cloud
We are all familiar with this Software as a Service (SaaS) model. It’s a great idea. The app is hosted remotely allowing users to easily trial it, buy it and use it as needed.
SaaS is wonderfully scalable, since users only pay for what they actually use. The only drawback is that the application pretty much has to be used “as is” without much in the way of individualizing flexibility.
At the same time, the concept of remote hosting was extended beyond individual apps to include virtually the entire IT infrastructure required by the enterprise. Hardware, operating systems, applications and data could all be maintained remotely and delivered locally.
This capability has evolved into what we know as the cloud today.
Hosting an application and delivering it via SaaS involves multiple users or enterprises accessing the same code hosted in a remote location. But, cloud-based apps do not necessarily mean shared apps.
Where your app runs—in the basement of your HQ building—at a datacenter in Kansas or within a third-party managed facility—has nothing to do with utilizing shared code versus accessing discrete individualized products and applications.
That is too frequently the source of confusion, even today, when companies evaluate cloud-based alternatives. There is absolutely nothing to prevent a cloud-based app from being modified or customized as required by the end-user.
Customization vs. Configuration
Customization can mean many things. Most apps allow some level of modification or customization within their native code. We call this capability configuration. Configuration should not be confused with customization.
What is Configuration?
Configuration allows the definition of things like field attributes, the assignment of fields to specific categories and the linking of fields into hierarchies that match the user’s needs. Screens and reports can be defined, modified, saved and built to specific requirements without resorting to code-level changes to the product.
What is Customization?
Customization is more involved. Customizing a finance system to handle earned value revenue recognition for individual phases of large-scale projects would involve basic functional differences from standard AP, AR and GL accounting functions. This level of enhancement is likely going to involve some major work at the code level.
The lesson is that most applications provide some level of customization to help adapt the application more tightly to the user’s requirements.
Application Code Changes versus End-User Options
Finally, another way to consider the magnitude of change is to simply look at what is required.
If the application provides the capability to adapt, configure or define specific elements within the program or on the screen for the end-user, it is not a customization.
If the changes required mean that engineers must modify underlying code in order to achieve what is required, that type of change is indeed a customization. That copy of the application is forever changed and will be unique. This will profoundly affect future releases and maintenance requirements associated with that app.
Regardless of the level of change required, cloud should not be the deciding factor. Cloud is simply the location for the host hardware that runs the application. Remote or local, the customer can still modify the app, as needed.
