If you’re looking to buy software for your business, you might struggle to find a solution that does exactly what you need it to do. The more complex the need — application lifecycle management, for example — the less exact the fit. Your final decision will probably depend on which makes more sense for you: customization or configuration.
A highly configurable tool may cost more on the front end, but your total cost isn’t just the price tag. There are numerous caveats to customizing a simpler tool, so you need to consider how each scenario will affect your business and your teams in the long run.
Let’s look at the differences between customization and configuration, and what kinds of factors should influence your final decision.
What Is Configuration?
Configuration means activating, arranging, or adjusting out-of-the-box functionality to best suit your needs. For example, when you buy a smartphone, you might arrange your home screen, adjust security settings, enlarge font size, change background color and images — these are all configurations. You have the same options as anyone else who buys the same phone, but how you choose to set up its innate functionality is unique to you.
In reality, you’ll configure any software you purchase for your business. Things like form fields, dashboards, and user views tend to be flexible in any solution. The more flexibility you have that meets your specific workflow, however, the more effort required by the vendor to build, test, and support those functionalities. That’s why the price tends to be higher.
What Is Customization?
Customization, then, is to make a modification that is unavailable through out-of-the-box functionality. Using the smartphone example, if you have it engraved, or hack the code to get something to work in a way that is different from innate functionality, you have customized it. It took a special skill or knowledge to make your phone different from that of other users. Additionally, if these changes interfere with some innate functionality of your phone, it is not the manufacturer’s responsibility to fix it.
When you customize software, it usually requires custom coding and — in some cases — custom implementation. This creates a cascade of challenges that you need to be ready to deal with both now and in the future.
Software configuration requires no programming knowledge — you simply set up your system using out-of-the-box functionality. Customization requires changes to the code, and takes specialized expertise to execute.
Considerations for Customization vs. Configuration
Regardless of the business application, considerations for customization and configuration are fairly universal. Here are four points likely to adjust your concept of total cost.
Time
Customization requires a lot more time than configuration. If your vendor offers customization, this can reduce the amount of extra time it takes for your functionality to be built. Still, you need to develop a whole new set of requirements and tests for the customization. If you have someone else create it for you, they don’t just have to figure out the new code; they have to study the existing code to make sure everything plays nicely together. They also don’t have access to the testing that was done on the base software, so if they want to check that nothing broke, they are building those extra tests from scratch.
New functionality may also require more time to be implemented. Not only is it another thing to train staff on, but that training has to be developed. Remember that the extra work is not complete when the code is finalized.
Simplicity
It takes someone with a lot of expertise to custom-create code. Again, it’s not just about the new code, but how it interacts with existing code. If you don’t use your vendor for customizations, it becomes complicated to find the person to do that job. Are you using someone in-house? How will that impact their other responsibilities? Hiring out? How do you find the right fit? And when you need changes in the future (because you will), can you hire back the same person? Will that same in-house person still work for you? How much time and effort can you spare to bring someone new up to speed?
That isn’t to say that configuration will be super simple, either. There will be a learning curve. It’s just that anyone on the team can accomplish configuration. The same is not true for customization.
Flexibility
Once you customize the code, you’re locked into the change. If you want to go backwards, you have to do it with more new code. If a future release impacts the customized code, someone needs to figure out what changed and then create more new code.
Conversely, with configuration, you usually have the flexibility to activate and deactivate functionality quickly and easily.
Support
When you buy software, the vendor has tested all the functionality and will support it along with features delivered through future releases. This includes your base software and the configurations that come with it. With customizations, if something goes wrong in the new code or as a result of the new code, that almost always means that you are responsible for correcting the situation.
Going back to the phone example, you may have experienced this if you’ve downloaded an app that is not supported by your phone’s operating system. It might still work, but if something goes wrong, there is clear language from the app maker that they do not owe you anything to make that work. The same is true of add-ons for popular software. Customization doesn’t necessarily mean you have someone build something from the ground up. It could very well be an existing application. But if it wasn’t built for your solution, you run into many of the same complications as you would starting from scratch. (More about add-ons in the next section.)
Of course, none of this is to say that customization is bad. Sometimes it is the best option (and can be the only option.) You just need to know how accessibility and support are impacted, and decide what it may cost you in labor, delays, inaccessibility, headaches, or even customer loyalty.
How Does This Apply to ALM Software?
We mentioned earlier that application lifecycle management (ALM) software is one of the more complex solutions you can buy for the product lifecycle. A full ALM solution will let you manage requirements, tests, and issues in one platform. The available ALM tools on the market vary greatly in terms of configurability. So, it’s worth noting a couple more considerations.
Compliance
There are many intricacies to compliance. Depending on the regulation, you need to be able to prove anything from who accessed an artifact to who had authority to change it. Audits are a lot of work — buying an ALM solution that’s designed to help you stay compliant and prove it will make your life easier. For some, that alone is worth the cost.
When you customize, you could be adding a thick layer of complexity to compliance. What documentation do you need for an audit, and is that available?
Also, if you’re customizing (especially with add-ons,) you may not have great traceability (if at all.) The number one thing that regulated industries want in an ALM solution for compliance is traceability. So, consider the time, effort, and risk that’s on the table if you make a decision that leaves you without it.
Add-ons: How to Workaround
We mentioned earlier that add-ons are considered a customization. They’re important for ALM because Jira is a very popular tool in product development.
In fact, Jira is a common reason that a company will choose to customize. If their teams work well with it, they feel they can simply use addons to fill gaps. So they find single modules to manage requirements and tests to use alongside Jira, and Frankenstein a solution to handle ALM.
And maybe that works well. However, remember that if something breaks in an add-on, you don’t have Jira-level support for that. If that addon creates difficulty somewhere else in the lifecycle management, there is no one responsible for fixing that. Your monster, your problem.
Considering there is also no traceability with a piecemeal solution, if Jira is the reason you’re slimming down your ALM functionality, we recommend researching a full solution that integrates with Jira. You may be able to use your own issues management but still have the support and functionality of requirements and test management — along with traceability. Consider everything that this scenario spares you from dealing with, and factor that into the final cost.
ALM Software Customization vs. Configuration
If you’re still here, you’re in the market for an ALM solution. As we said, your options vary greatly in configurability. And traceability may be one of the top factors in your decision.
Perforce ALM (formerly Helix ALM) is the most configurable solution you'll find on the market. We know that no two workflows are the same, and it’s as important to give your team a tool they can easily work as it is to support your compliance.
It’s worth highlighting a few configurations that help ease some of the burdens you’re feeling as you decide.
Workflow — If an ALM solution forces you to work in a new way, it makes implementation especially painful. We live in a world where Agile and Waterfall exist together. Perforce ALM supports the hybrid environment so that everyone can stay productive without losing valuable documentation.
Compliance Rules — Configuration around compliance is a must for regulated industries. Signature processes and group visibility are particularly important to compliance. You should be able to configure who approves items, allow multiple people to approve, and allow exclusive visibility to specific teams — among other security measures.
Dashboards and Visibility — While workflows are different among teams, so are the items they care about. What they want to see in their dashboards is different from what a manager wants to see. And let’s not forget stakeholders. What they care about (and what they should access from a compliance stance) is an entirely different view. Having one ALM solution that truly serves the different people who will use it makes everything from reporting to the day-to-day much more efficient.
It Comes Down to This...
Ultimately, change is inevitable. When it comes to choosing between customization and configuration, the question is: when change happens, how much effort will it take to rework your software or process?
Know what’s possible before deciding on a tool you will use through many changes. See how Perforce ALM can support your process in our 20-minute demo recording.