Code of silence: the hidden dangers of customized software and how to avoid them

When it comes to effective process automation, there is no one-size-fits-all solution. It makes sense that many organizations opt for fully customized software. It makes sense to code each function to fit their unique requirements.

It makes sense until it comes time for upgrades, process changes or evaluating the ongoing fees.

It’s virtually impossible to estimate how much customization will cost in the future. If you happen to work for that one company where budget isn’t a factor, then consider that fully customized software becomes progressively more fragile with each line of code. Consistently adding and fine-tuning functionality gives users a great experience, but even light customization can turn a minor upgrade into a major hassle.

The industry at large has discovered the solution to these troubles by seeking configuration over customization. Configuration is changing the behavior of the product by selecting options from a graphical user interface (GUI), using a browser. One major strength of configuration is safety – no custom code means no custom bugs. You choose options that the program developers anticipated and other customers have already used.

Recently, ENKI created a robust and integrated system for customer support, contract management and CRM. After 6 man-months and several calendar years writing over 50,000 lines of code, they realized that the system fell short. Less than 10 days later, they had reproduced all of their required customizations and more within Agiloft – without writing a single line of code.

In reality, most products require both customization and configuration. However, the advantages of selecting a solution that leans more heavily on configuration are significant. But how do we determine if an enterprise software is truly configurable or if we’re being sold a no-code option that will actually end up requiring bottom-up programming?

Here are the questions to consider when demoing products:

  • Fields: Do custom fields that you add behave exactly like the default fields that came with the system? Can you run reports on them?
  • Tables: Do the tables that you add behave exactly like the default tables? For example, can you define which groups of users should be able to create, edit or delete records in these tables? Does the system understand the relationships between custom and existing tables?
  • Business rules: Can you create rules with specific criteria that will govern system behavior? For example, can you send an email to the widget manager if more than seven widgets with a priority of urgent are created within 24 hours?
  • The look: Can you customize the overall appearance of the system to match your corporate standards?
  • Search: Can you define searches based on specific information and then save them for later use?
  • Access: Can you define access permissions to precisely control what information people can view, edit, or delete?
  • Reporting: Can you combine multiple charts into a dashboard, then drill down into a particular chart to view the background data? Can you customize the spreadsheet output by adding your own charts that refresh whenever the report is regenerated?
  • Audit: Can you specify that the system should track which users logged in, when they logged in, what records they viewed, what records they created or deleted, and which business rules they changed?

While evaluating a system, ask vendors to demonstrate exactly how they configure the system, adding questions which reflect your particular processes. Together, we can put an end to the code of silence and start talking about the reasons no-code software is the future of automation and enterprise software.