AHEAD | The Challenge of Configuration
The idea of a highly configurable and flexible product that is quick to change and deploy may seem like the answer to all of your problems, but the effort involved in getting the most out of it shouldn’t be underestimated. The following article provides a few pointers to help along the way.
You don’t know what you don’t know: If you set out with a clear statement of what you want the product to do, but without understanding what the product can do you may not leverage the full value of a product. Furthermore, by focusing only on what you want you might end up with missing features or features you don’t want. Often functionality is controlled by a configurable toggle which can easily be set the wrong way. Having stated your requirements clearly find out what else the product could and does deliver by default.
Be clear about what is important: Despite the statement above, with a feature rich product it is easy to lose sight of what is really important. As new features become apparent, it is easy for good ideas to run out of control impacting both project timescales and budgets. As with any project proper controls need to be applied to ensure change is managed and adds value. Functionality can always be added or enhanced later once the product has been bedded down and proven to deliver core requirements.
Understand what is out of the box: When you hear that a particular function comes out of the box it pays to ask a few questions because in a highly configurable system very little will really be out of the box. As an example, whilst a solution may support the cancellation of a customer order, the functionality may not operate without first having configured cancellation reason codes. This might seem like an obvious example, understanding how the product really works will reduce lost time that is the inevitable consequence of something not running properly.
Take responsibility for configuration: Don’t expect a supplier to necessarily take the lead in defining configuration values and make sure a senior stakeholder is assigned the responsibility for making sure this work is completed. While suppliers will have a wealth of experience having implemented their product with other clients they may reluctant to offer advice understanding that each business is unique. Suppliers need to be encouraged to play a key part in this exercise to make sure nothing is missed and to communicate the role and significance of a configurable items but ultimately configuration is about how your business will work.
Start defining configuration early: The effort involved in compiling and agreeing configuration is significant. It will require input from experienced and senior business users and technical staff who have a clear understanding of target operating and support models. This last point in itself is likely to present a challenge, since those documents may also be under development. Consequently, it is important that those involved in defining configuration have the authority to make any necessary changes. It is easy to configure an application to get it to work during testing, but the longer it takes to bottom out production configuration, the more retesting will be required.
Configuration takes time: Sometimes configuration can be so extensive and complicated that even a supplier has difficulty understanding. Inter-dependencies can be subtle and together with features that are not frequently used it can take a while to define and implement the required behavior in a product. This shouldn’t come as a surprise when readable code is replaced by cryptic parameters and value. Don’t expect configuration changes to work first time every time and factor this in to the project plan.
Flexible isn’t the same as easy to use: Don’t confuse feature rich and flexibility with meaning that a product will be easy or efficient to use. As with any commercial product, you are buying someone else’s interpretation of your business needs and how it runs. There will be limits to the extent look, feel, navigation and business rules can be controlled. Whilst the a new product offers the opportunity to review and potentially improve existing business processes, it is worth exploring complex areas of your business in detail with the supplier to make sure that a product doesn’t just deliver, but allows your business to operate effectively.
What to test and when: It may be convenient to change configuration to support testing but be clear about what is and isn’t acceptable. For example, the ability to change a job schedule to accelerate an event timeline is great, but when and how will the proper configuration be tested. Will this even be possible and how do you mitigate the risks of not testing? In another instance testing with a subset of values may be perfectly reasonable, such as a list of items populated in a dropdown where the data is used for information only, and the full list can be checked subsequently via a database query. Whatever strategy you adopt, don’t leave testing complex areas too late. Security models may be just another configurable area but is a common cause of incidents post “go-live” because it hasn’t assessed early or thoroughly enough.
Know how to manage configuration: As has already been indicated configurable items can range from the timing of job schedules, through dropdown values to the availability of a feature. It is critical to understand and document the configuration settings, what they do, where to find them and who needs to change them. Some may be accessible via an administrator screen whilst others may require the involvement of a DBA. Don’t expect the parameters to all be managed the same way in the same place. The value of a configurable system will be seriously diminished if you are reliant on a supplier to implement future change and the true cost of ownership may come as a surprise.
Control change appropriately: The whole point of a configurable product is that the behaviour can be changed quickly and easily if you know what you are doing. This situation can easily lead to a false sense of security and an argument in favour of the need for less stringent change control processes with testers and developers making changes on the fly. The fact is that managing configuration across multiple environments can be much more difficult than managing code and failure to control change can lead to time being wasted looking for problems that don’t exist. Good change control needs to be effective but shouldn’t detract from the flexibility that product configuration can offer.