You've been warned: Application configuration is no cakewalk, and it's not the only option for tuning cloud-based apps.
It's time to lay to rest two common myths of the cloud computing era. One is that configuring enterprise applications--whether deployed on-premises or accessed in the cloud--is easy, which is far from true even if it's easier than customizing an application. The other myth is that you can't customize cloud-based apps.
Unless we kill these myths, we expect too much, or too little, from our applications.
There is no doubt that IT shops are increasingly using software's built-in configuration tools rather than coding their own customizations, and there are several reasons for the move toward configuration. For starters, IT teams have been complaining for years about the burden of maintaining their ERP, CRM, supply chain management, human capital management and other enterprise apps. More than half (54%) of the 338 business technology professionals who responded to our just-released InformationWeek 2012 Enterprise Applications Survey cite "changing, upgrading or optimizing existing applications" as their most time-consuming challenge.
By comparison, "implementing and integrating new apps" and "changing business processes" is cited by only 31% and 29%, respectively, and our survey stats have been much the same for the last three years.
Configuration promises to be easier than customization because it's done through vendor-supplied menus and wizards that help companies set up applications to meet their specific needs. That's the theory, at least. The customization approach, by contrast, usually entails coding and time-consuming, iterative software-development steps. And when the vendor upgrades the app, there's no guarantee that customizations will still work. Configurations are vendor-supported features that are built right into the app, so there's no need to worry about upgrades.
Vendors of on-premises software have been adding configuration options to their apps for years in order to add industry-specific features to appeal to new markets. But it's the success of SaaS vendors that's fueling the configuration trend lately. "Configuration is hot right now because, in going to the cloud, there are different customer expectations in terms of being able to move to the latest version quickly," explains Jannik Bausager, director of the Microsoft Dynamics NAV (ERP) product management team.
SaaS applications are generally built for configuration from the start, and SaaS vendors tout the fact that they offer several releases per year. This lets customers take advantage of new features immediately, but it's the vendor's responsibility to ensure a fast, trouble-free upgrade. Salesforce.com and Workday, for example, offer three updates per year, while SAP and its SuccessFactors unit now deliver four.
On-premises software vendors, by contrast, typically offer incremental releases once per year and major new releases once every two to three years. Microsoft switched its Dynamics CRM software to two upgrades per year when it moved the formerly on-premises-only software into the cloud, and it's promising to do the same when it offers the Dynamics GP and Dynamics NAV ERP systems in the cloud later this year.
Now, getting back to those myths. It's safe to say that configuration is easier than customization but that's not to say that it's easy. Those who think configuration is a cake walk are "wearing rose-colored glasses," says Mike Cuddy, CIO of Canadian heavy equipment supplier Toromont Industries.
Toromont runs SAP ERP and has a couple of employees with SAP configuration knowledge on staff, "but we easily get outside their area of expertise when we get into modules that they don't know," he says. Even with configuration, you'll have to set plenty of fill-in-the-blank parameters, data-element names, target destinations, and obscure and inscrutable settings.
You likely need specialized people who know which switches to flip, the rules required, and the ripple effect the changes will have on downstream processes. Bausager of Microsoft acknowledges that Dynamics app configuration is handled mostly by highly trained Microsoft partner resellers and systems integrators. Even in the case of SaaS pure-plays like Salesforce and Workday, companies often face weeks or even months of setup after the initial signup to get the apps configured to their specific needs.
As for the second myth, while it's true that SaaS vendors rely heavily on configuration, that doesn't mean that it's impossible to customize a SaaS app. Salesforce.com, for one, supports customization through its Force.com development platform. On Force.com you develop using the same APEX programming language, application programming interfaces, reporting and analytic calls, security model, and workflow and approval capabilities of the vendor's core apps. It's Salesforce's problem to ensure consistency between Force.com and its apps even as it upgrades and adds new features.
NetSuite, which offers a suite of ERP, e-commerce, order management, asset management, inventory tracking and CRM applications in the cloud, provides SuiteBuilder customization tools and a SuiteFlow workflow engine. Here again you're working within the framework of the native application, so your customizations won't break when there's an upgrade.
"NetSuite gives us advanced warning that there's going to be an upgrade, and we have 2-1/2 months to validate all of our scripts in a test environment," Baumer says.
So when do you configure and when do you customize? You can read our advice in detail in the InformationWeek 2012 Enterprise Applications Survey report, but it boils down to deciding what is commoditized and what's a differentiator for your company. If custom functionality is your key to competitive advantage, by all means customize. Otherwise, stick with configuration so you can worry less about breaking the app with each and every upgrade.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.