Best practice for custom requirements

Searching for a solution

When embarking on a digital project, one of the first steps is to assess different technological solutions to see if they meet your needs. Often our clients already have a target system in mind (usually Drupal or a specific flavour of Drupal such as GovCMS) but they’re not sure if the target system will meet all their requirements.

Viability assessment

The first step when assessing a product’s suitability for your project is a viability study to see how well the out-of-box features track against your requirements. You might focus on one product or compare more than one to see which is the best fit. For example, we often do GovCMS SaaS vs PaaS and Drupal viability assessments to help clients find the best content management system (CMS) for them. Same goes for CKAN, where we’ll conduct a viability assessment to determine how well our customer’s requirements fit out-of-the-box.

Requirements and specifications

We usually start with the requirements, analyse what extensions/modules to use for the requirements and work out what functionalities will need to be written/coded. The result is the project specification.

How much coverage?

The reality is, it’s highly unlikely that any product will meet all of your business requirements in its out-of-the-box form. Most websites tend to have very specific functionality and business requirements. A viability study gives you an idea of the product’s percentage coverage. For example, maybe out-of-the-box CKAN covers 85% of your requirements. This means 15% of your requirements are not native to CKAN (not part of the out-of-the-box solution). Problem is, your business needs those things. Some tailoring is required, but what are your options?

Customise the core?

For many clients the first option that springs to mind is to customise the core components. However, we don’t recommend this. When you try to customise a product, it introduces a real risk of maintenance liabilities and a real risk of poor upgrade viability. Customisation may meet your immediate needs but it introduces long-term issues when trying to update or enhance your site/solution. It makes patching hard and expensive. It makes upgrades hard and expensive.  

So you want to avoid ‘hacking’ the core of CKAN, GovCMS or Drupal (or any other open source offering) at all costs.

Better solutions  

There are three main options open to you at this stage, specifically theme changes, third-party solutions and building your own module.

Theme changes

Can the requirement be met using a theme change? Often theme changes have a much lower risk of maintenance or patch upgrade issues. However, you will need to implement theme changes using best practices.

Third-party modules

Is there a third-party module that already exists in the community that you could use and bake into your solution? When looking at this option, you’ll also need to consider the maintainer of the module. To assess how reputable the module is, ask these questions:

1. How popular is the module? (How many times has it been downloaded?)

2. Is there active community engagement around the module?

3. Is the maintainer responsive to community requests and feedback?

These are important questions and considerations. Open source is fantastic but if you use a third-party module, you are depending on the maintainer to keep it up to date.

What if a third-party module meets some of your requirements, but not all? Once you’ve qualified the module, you’ve got two options:

1. You can make generic enhancements that will then get contributed back and become part of the module the maintainer is offering. This needs a conversation with the maintainer to see if they’d find that feature desirable and if they’d consider maintaining the updated module once you’ve changed it.

2. You can also negotiate with the maintainer to implement the change for you (you’ll need to pay, but that also gets buy-in from the module owner/maintainer).

Build your own module

The final option to meet your required functionality is to build your own module. The best way to do this is to build a feature (whether it’s a module/extension or a plugin) in a generic way with good coding and implementation practices so you’re contributing a module to a community that would ideally adopt, enhance and maintain it with you. Going forward, you’ll be the official maintainer of the module, with a maintenance agreement so make sure you’re proactively maintaining it and proactively engaging the community.

Building your own module is probably the last resort but it avoids unique customisations to the core code and also brings other benefits, such as increased community engagement.

Salsa’s customisation policy

The best solution will strike a balance between not writing too much custom code but also not installing so many modules/extensions that you end up with an over-engineered application, with code for functionalities you don’t need.

We’ll always seek out native/out-of-the-box system functionality before suggesting the customisation route, due to the additional upfront costs, ongoing maintenance and loss of efficiencies when implementing or introducing customised development. By taking this approach we’re also greatly improving how easily you can upgrade and patch your system in the future.

For more information on Drupal, GovCMS and CKAN you might like to view our pages on:

• Drupal CMS development
• What is GovCMS?
• What is CKAN?
• Open source security patching and updates