Stop Customizing Everything

The business of customizing automobiles has been a global phenomenon for decades. It’s a hobby focused on aesthetics, performance, personal expression – rarely on practical concerns. Customizing a car is usually justified by the pleasure it generates, both in the work involved and the joy of showing off the results.

In the much more pragmatic world of enterprise technology, the word “customization” raises caution rather than excitement. Customization brings effort , complexity and risk. And yet, technology teams continue to turn to customization again and again when deploying software products. This trend is more than a little troublesome, since its breadth does not appear to be shrinking (quite the opposite), and over-customized systems run the risk of crippling your ability to deliver value to internal AND external customers.

Note: There’s a footnote at the end of this article describing what I mean by “customization” – it can be an overloaded term.

There are valid reasons for customization, of course. Justification for them boils down to a classic return-on-investment (ROI) assessment. A “good” customization gives you capabilities with a value of X and has costs/risks Y, but X is greater (hopefully much greater) than Y. In the world of customizing cars, this is equivalent to the very pragmatic (but rather boring) decision to install a roof rack on your car to get more storage capacity. You have some minor costs up front, almost no costs going forward, and some good ongoing benefits.

That’s a Bad Custom(ization)

There are many, many bad justifications for customizations. At one level, these boil down to misjudgements or mismanagement of the ROI assessment. You make an inaccurate estimate of the numerator (value) or the denominator (costs + risks), or you fail to assess the ROI at all before leaping into customization. Some of these fall under lack of due diligence – you thought system X did what we needed, but it doesn’t, and now you are forced to customize to meet business needs (or just expectations). Some fall under poor value assessment – you miscalculate (or fail to calculate at all) the true value of the capability in terms of efficiency, cost avoidance, differentiation, etc. Some fall under poor cost assessment – you miscalculate (or fail to calculate at all) the true up-front and ongoing cost of the customizations needed.

So that all seems pretty straightforward, right? Just make sure you get an accurate value and cost estimate before committing to a customization – easy! Well, as with most financial math, what seems clean and clear-cut on face value, can be far more complex in practice. People and processes operate more organically than the math might lead you to believe.

What are the actual root causes of poor customization decisions? Well, the principals involved in any of these scenarios are the system vendor selling the technology, the technology team implementing and supporting the technology, and the business stakeholders using and realizing the value of the technology. Bad customization decisions can almost always be traced to broken communications and relationships among these players.

There are some very common modes for these breakdowns:

Snake Oil

Vendors can misrepresent their platforms as “configurable” in specific ways, when in fact these “configurations” enable limited functionality compared to what you need (actual value < estimated value), or these “configurations” are actually customizations in practice (actual costs > estimated costs). An even more egregious version of this is a vendor who implies (or states outright) that their platform has a capability, when it’s actually only feasible with customization. And a disturbing corollary version of this mode is when technology teams have unhealthy biases towards a vendor, or a less-than-healthy relationship with their business partners, which can lead to skewed justifications for customizations.

Fail to Prepare / Prepare to Fail

Technology teams can hang themselves by not doing proper due diligence and assuming capabilities exist natively or via configuration when, in fact, they do not. One classic example I’ve heard recently: “They have SSO support, so I’m sure they support our very common SSO system”. Realizing your mistake after acquisition leaves you with some really terrible options – try to back out of the contract with the vendor (unlikely since you are at fault), live without the needed capability (not a good option, since it’s “needed”, hence of value), or try to fill the gap with an unplanned customization (which will very likely involve a very low ROI).

Lift-and-Shift

This is a classic and sadly prevalent anti-pattern. Here, business stakeholders assert (or the technology team assumes) that today’s process is immutable, and therefore any and all customizations required to enable it with the new technology are justified. Weak technology teams and/or misguided business stakeholders enable this mode of operation. They collectively avoid the opportunities to transform architecture and business processes. Instead they seek to recreate “the devil that we know”, nullifying the value of a new platform.

“Good Custom”

Conversely, what do positive, high-value customizations look like? They support sustained, provable top-line and/or bottom-line value. Simple as that. Top-line value customizations are the most interesting and easiest to justify, because they are connected directly to revenue and market share. The exemplar for this is a product or operational differentiator. In these situations, your position is that no technology solution supports this capability directly because you are doing something different (perhaps even innovative?), and this differentiator is going to be a competitive advantage. Obviously the ROI rule still applies – your hypothesis about a capability being a differentiator needs to be validated and the resulting value needs to be estimated as quantitatively as possible. But assuming this has the results you expect … customize? Yes, please.

Customizations connected to bottom-line value can be a bit murkier, but can have as strong a numerator in the ROI calc as anything else. In these situations your theory is that your new operating model, enabled with this customization, will save you X person-days/-months/-years of effort on a monthly/quarterly/annual basis, cutting your costs and improving your margins. Obviously false-positives are a risk here as well, especially when you are betting on anticipated efficiencies from people and processes. Organic things don’t always behave according to plan. Honest thought experiments with the principals involved can be very illuminating here – imagine operating without the customization, and with. The level of contrast between these two scenarios, coming from people that actually live the process, will give you a good sense of the true value.

Bottom Line

All of these lead to a few strategic principles around managing customizations effectively:

Consider your tech holistically

Don’t fall into the trap of putting blinders on and focusing just on the tool or system under consideration. Look at the whole architecture in your domain (and even beyond). Local optimization may lead to an unnecessary customization effort. Looking longitudinally may show you more macro dynamics and possibilities for plugging in a new system instead of wiring and bolting it in.

Be honest about the nature of any customizations that you do consider. They need to be considered as distinct components that have their own operating costs and need to be managed that way.

Consider your people holistically

One common justification I hear for a team’s customization decision is “The technology needs to support people and process, not the other way around.” I couldn’t agree more, as a general rule of thumb – with heavy emphasis on the point above about the appropriate “aperture” of your view of the technology…

BUT, process change always needs to be a lever in your architecture optimization. Discounting it out of hand will lead to nightmare architectures, with technology components patched together by expensive customizations to make them behave in ways they were never designed to behave.

Don’t leave broken windows unmended

If something in your architecture is not operating well from a process perspective, it can often be traced to an ill-advised customization that is adding friction to the system, or to a needed customization that could eliminate the friction, or even to the need for new solutions for key capabilities.

In other cases, the issue can be traced to a process change (or outright transformation) opportunity. Is there a transformation needed at a technical or process level that could also transform your customization profile to a high-ROI one? Don’t leave these opportunities on the table.

Choose Your Partners Carefully

Your enterprise platforms need to enable you to make effective customization choices based on the principles above.  Common capabilities leveraged in common contexts should come with little or no customization overhead.  Genuine, justifiable customization needs should be met with effective, full-throated support for enabling these in a reasonable way. This drives our platform strategy at Ironclad, where we strive to push the standard, self-service, out-of-the-box envelope as far as we reasonably can, while we also recognize that many of our customers will live outside of that envelope, and we need to meet them there.

FOOTNOTE: Customization is an extension or wholesale replacement of standard functionality provided in a software product, involving the creation of some form of runtime code that has to be maintained by the software consumer. Embedded CSS/Javascript code in a web UI (e.g., in a WordPress site), custom components that you add to your instance of a platform’s runtime (e.g., a custom APEX class in a Salesforce org), integrations that you develop using a platform’s APIs (e.g., an Oracle Fusion integration connecting your CRM to your ERP) are all typical examples of customization. A truly configurable feature, in the definition being used here, doesn’t create any new technical debt for you to own. Flipping flags in an admin UI, setting runtime attributes in a preferences screen or file, are typical examples of configuration.