Configuration vs. Customization
Discussion and Confusion about the Difference
There is a healthy amount of discussion (and an unhealthy amount of confusion) over the difference between configuration and customization where software is concerned. If you are one of our clients (and if you aren’t, there’s way to fix that), you probably know this already, but we think it is a big enough deal that we thought we’d talk about it more. And we’ve done a quick 30-min presentation on this same topic.
If you’ve had more than two conversations with me, you’ll know that I love analogies. In fact, my love for analogies is like a simile. I’m not always great with either of them. But to explain the difference between customization and configuration, I have just the analogy for the job. We will use the wardrobes of two famous billionaires.
First up, Customization
And who better to exemplify all things customized than this guy?
Yes, Tony Stark, AKA Iron Man. The poster child for customization, Tony is well known for building (and then destroying) suits with some basic common elements, but imbuing each with a special abilities to handle specific tasks. Don’t believe me? Take a look at these:
Arctic Armor. ARCTIC ARMOR. Tony can’t be bothered to put on long underwear, so he just builds a blue suit instead. Now THAT’S customization.
What’s the alternative? Configuration
Batman and his secret identity, Bruce Wayne, is all about configuration. (Don’t be fooled, Bruce is the mask. Batman is the real identity here.) This isn’t going to devolve into, “Who spends their money better?” Tony and Bats have a ton in common, mostly being super rich, super smart, and super human (as opposed to superhuman). Their schtick is their gear, but their approach is different. Bats wears the same thing every night, though he might configure the contents of his utility belt as needed.
This might be the basic setup, but we all know that Batman always has just the right gear for whatever he’s doing. Batarang? Check. Tiny Bat Grenades? Doublecheck. Bat lockpics? Mega-check. Bat shark repellent when needed? MOTHERFLIPPING CHECK ALL OVER THAT.
These two approaches are a perfect comparison for configuration and customization.
Tony has lots of great armor, all custom built for a specific purpose. That means his Space Armor Mark II is perfect for going into space. But if he need to head underwater, he may need to stop and change into his Classic Hydro Armor. And if he’s fighting the Hulk down there, he may regret not having his Hulkbuster capabilities at hand. That’s the downside of customization. It may give you a tool that works perfectly for a need, but you have fewer capabilities that work across a wide range of needs. For software, this can lead you to some very difficult situations. If you build a tool to meet custom requirements, it becomes very difficult to upgrade that software across a range of users. This very often leads to needing a dedicated team of programmers or consultants just to maintain the status quo, and a large consulting bill when a system upgrade comes along.
Bats knows that one suit fits all needs. His utility belt allows him to have just the right tool for the job without needing a full wardrobe change, (despite what the movies or toy companies might tell you).
By tweaking the contents of his goody bags, Batman configures his gear to the moment flawlessly. He can take what he needs for the moment, but is also confident that whatever unexpected situation arises, he’s got the right tool for that job as well.
This is our mindset when building software.
We live in a world of configuration, meaning you can build our tools out to work the way you need. We do so on a foundation of a simple interface and flexibility, allowing our clients to decide when, where and how to deploy features. Don’t need to use Broadcasts? No problem. Turn them off. Want to launch our Employee Portal next month? It’s already there for you, waiting to be called to duty. Want to completely change your case types and team structure? You can do that, too. And you can do it without an army of consultants.
The Real Impact
If you want to see the real impact of the different approaches, look at how a platform handles updates. A customized system may be built in such a way that it cannot be updated, or could require a massive project to implement. If you are being charged for an update, it’s a good sign that your system is built on customization. Platforms that are on-premises, or adapted from on-premises to look like SaaS, often follow this model. Most true SaaS platforms, including ours, are built on configuration. It allows for faster and painless updates, since new features can be delivered in the background, ready for you to choose to enable them. We deliver the features, you decide what works for you. And if you change your mind, you have the ability to turn a feature on or off. We’re big believers in handing you the keys and letting you drive.
Is customization evil? It’s hard to say for a fact. But only one of these approaches led to…
So maybe we should all stick to the configuration path. It’s safer for us all.
**For additional information / understanding about SaaS, check out “The Community Garden of SaaS”