Enterprise Applications: Customization Vs. Configuration

We've been asking InformationWeek readers about their attitudes toward enterprise applications since 2010, and over the years we've seen remarkably consistent responses to certain questions. One area that's an ongoing source of pain is changing, upgrading, or optimizing existing applications. That was by far the top barrier to success in application and process management cited by respondents to our 2012 Enterprise Applications Survey, and those results were much the same in our 2011 and 2010 polls. These tasks were also cited as the most time-consuming ones respondents face, and here, too, results were nearly identical in 2011 and 2010.

One way businesses are coping with the challenge of upgrading and optimizing enterprise applications is to avoid customization. For their part, vendors are providing more options to configure applications for particular needs and industries. But in some cases, configuration options are getting so numerous and layered that they present challenges of their own

The difference between customization and configuration boils down to coding and development versus a vendor-supplied menu- or wizard-driven approach. When you develop custom code to change or extend functionality, there's always a chance the code won't work when the vendor introduces the next release, so extra validation steps are required. In the case of major upgrades, customization can be just as demanding and time-consuming as migrating to a whole new application, as broken functionality may have to be redeveloped from scratch.

As a result, some companies hold off on upgrades, weighing the benefits of new features against the pain of fixing broken customizations. In response, on-premises software vendors are increasingly embracing configuration, an approach used heavily in the software-as-a-service world, but IT shops used to the old way might be tempted to customize.

A better bet might be the cornerstone of the application strategy at Zebra Technologies, a supplier of bar code, receipt, kiosk, ID card, and RFID hardware and software. To wit: Avoid customization at all costs, a game plan that came about fairly recently. Until 2009, Zebra had 140 heavily customized legacy systems that didn't communicate well, says CIO Don O'Shea. That lineup included eight different Baan (now Infor) ERP deployments. When software broke or had to be upgraded, Zebra's own IT staff did the debugging and redeveloping, which stole attention from other projects. "In the old model, 80% of our staff time was dedicated to production support," O'Shea says. "Now 80% of the work is on new projects that bring value to the business."

That's an impressive flip. To get there, the company undertook a massive three-year rationalization and migration project that involved moves to Oracle E-Business Suite ERP, Siebel CRM, Oracle Advanced Supply Chain Planning, and Oracle Demantra demand planning software, along with Oracle Fusion Middleware and Oracle BI and performance management software.

The key has been having the discipline not to customize, O'Shea says. It might be tempting to add a few lines of code here and a handy gadget there, but customizations have a way of multiplying and adding up to trouble, particularly during upgrade cycles.

"We've lowered our support cost internally, and we're taking maximum advantage of Oracle support," O'Shea says, noting that there's never a question about the source of a problem. "We log a ticket and provide the details to Oracle support, and we get the fix back in a patch."

Configuration Conundrum

Even where it makes sense to steer clear of customization, using vendor-supplied configuration tools isn't always a simple alternative. These utilities get down into the nitty-gritty of how a company runs its business: Do you handle inventory tracking on a first-in, first-out or a last-in, first-out basis? How do you handle payment terms? What are your currency codes, tax-reporting approaches, and the details of your chart of accounts?

Vendors tout their wizard-driven configurations, but there's no getting around the depth and detail required in an initial deployment. Expect plenty of fill-in-the-blank parameters, data-element names, target destinations, and obscure and inscrutable settings.

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 they quickly get outside their areas of expertise when unfamiliar modules are introduced, Cuddy says. You need specialized and highly trained people to know which switches to switch, the rules required, and the implications for downstream processes--skills rare in Ontario, he says.

"When we look for help locally, we often can't find it, or there might be one person available, and they won't know everything we'd like them to know," he says.

So despite the fact that vendors and companies alike are embracing configuration over customization, it's unlikely that will do much to alter IT pros' perceptions of the difficulties involved in changing and optimizing apps, as indicated by our survey.

Once properly configured, applications should be much easier to upgrade and support, but the one-time configuration challenge "is a long way from download and type in 'setup.exe,'" says Cuddy.