Morey Haber, Chief Security Officer at BeyondTrust, tells us about the critical choice between customisation and configuration in cloud computing, highlighting its impact on business efficiency and costs.
It is a tale as old as IT itself. How do we, the business, procure a solution that does exactly what we need when the likelihood of such a product sitting on a shelf somewhere is negligible? And so, we engage in a tug of war (also as old as IT itself) between customisation and configuration. The choice we make has real-world implications such as hidden costs, additional risk and an increased labour burden.
The customisation-configuration face-off was never more prominent than in the years since 2020 when the GCC region moved, almost as one, to the cloud. CIOs could choose to tweak a product for their organisation’s unique ends (customisation). Achieved with or without vendor support, the enterprise could customise via a third-party add-on or write custom code to sidestep out-of-the-box limitations.
Alternatively, IT could go for a product that already comes with a lot of options to change runtime behaviour and attributes. Configuration is supported via product documentation that instructs on when to adjust settings and when to leave them alone. No custom code or software developer’s toolkits means a cleaner deployment.
But… the cloud
All this, while a conundrum, seems like a straightforward trade-off. If one weighs the pros and cons carefully, it should be possible to come up with a way forward that can satisfy business use cases. But what is described above is an old problem that occurred when deploying solutions on-premises. Today, because so much of the IT suite runs in the cloud, many of the previously available options have vanished, especially for customisation. The cloud complicates matters because multitenancy architectures mean an enterprise cannot just customise as needed to accommodate established business processes.
SaaS customisation is a rarity. In the few cases where it is offered, some customisation choices may even clash with the upgrade path. It is true that some vendors of cloud-native products allow extensive customisation. But the process is not as smooth as on-premises projects. A vendor must alter its platform and conduct a comprehensive code review of existing customisations to avoid destabilising the user experience or even basic functionality. This lack of customisation options creates problems for IT teams who take the leap and move to the cloud, as many GCC enterprises have done in recent years. There is an expectation among non-IT executives that core business applications can be teleported seamlessly to the new environment without any disruption to daily operations. In many cases, this may be possible. Even complex configurations can be duplicated.
But if legacy systems have been customised, the move is fraught with labour and costs because of the limitations of offering variants of cloud-native products in a multitenant setup. The typical SaaS solution is built around a specific set of workflows and configurations. Where an SDK exists, it is there to enhance but not fundamentally change. In other words, it is not intended for classic customisation — redesigning workflows and adding functionality. This leaves organisations with a hard choice. They must either change their business processes to meet the SaaS vendor’s product or introduce a workaround. The only other option for duplicating a customised solution is to migrate to a private cloud, which carries yet more cost.
Strawberry or vanilla?
So, how do you choose between customisation and configuration in the cloud era? I think we have established that this is not like choosing between strawberry or vanilla. The right path could make the business more competitive; the wrong one could lead to its end.
Customisation makes sense for organisations that have unique business requirements on which they cannot compromise and that cannot be fulfilled by out-of-the-box functionality. It should be made clear that this rigidity of purpose should be because of core business requirements. Where inter-departmental tensions are the reason for resistance against changing workflows, senior executives must step in. Customisation is a costly journey and some SaaS solutions do not allow it, which will rule out some vendors and products that may otherwise have brought advantages.
Configuration, on the other hand, is a no-brainer when changes can fulfil business requirements. Tweaking knobs and levers (‘settings’, if you like) to create an ideal solution is something offered in the cloud just as it is on-premises. Assuming a configuration satisfied a business case in the legacy environment, it is likely to be just as viable in the cloud (although not always). Configuration is part and parcel of functionality, so it is not affected by the presence of a multitenant environment.
Choose well
The GCC region’s cloud journey is not over. New migrations happen all the time. If you are planning one, try to remember the customisation-configuration conundrum and steer your transformation project by reviewing your legacy systems to find out what customisation, if any, has been done to the migrating solution and what business challenges it solved. To what extent can those customisations be replicated in the cloud? Will you have to change workflows, tasks, or use cases?
Success depends on knowing so much. You mustn’t assume that on-premises configuration settings can be replicated in the cloud. While this is more common than for customisation, it is not universal. It is only through asking all these questions and allowing for the role of third parties that you will get a clear picture of the costs and labour involved in recreating customisations in the cloud.
As we have shown, choosing between configuration and customisation is not like a whimsical selection of ice cream flavours. It can be the choice between plain sailing and choppy seas for your business. Even the simplest solutions can turn out to be costly when migrating to the cloud. Information-gathering is key, planning is critical and given the rate of adoption across the region, organisations must ensure they are not tripped up by the speed of the journey. Choose well.
