A case of inspiration: dealing with settings in an outsourced environment

Today I got inspired by a presentation given at our monthly developer meeting. Two of my colleagues were demonstrating a solution they designed for one of our customers.Servicedesk

This customer outsourced a large part of its IT landscape to all kinds of suppliers. The customer considers everything to be a service (SaaS: Software as a Service or Software on Demand). Their Dynamics CRM environment is outsourced as well and is being operated and maintained by one of their suppliers.

However, their CRM system is just a part of their IT landscape. The CRM system is acting as both a consumer and supplier of data from and to other IT systems.  A number of configurable (windows) services are interacting with the CRM system.

The customer is working with a DTAP environment, as the environment is in a constant state of development. This means that a lot of testing is done within this environment. This implies that settings needs to be changed on the fly.

In the old situation the settings used to be made in the configuration files of the external services. This involved the CRM administration to call the service desk for some configuration changes. The service desk had to call the supplier. The supplier had to assign a technician to alter the settings.

This process was a bit inefficient and prone to errors.

My colleagues got fed up with it, because testing meant that you had to go through the service desk supplier route in order to be able to test their software.
Therefor they decided to store all configuration settings within a number of “settings” entities. Per service they defined an entity, tailored to store the settings. Per entity a number of records could be stored. Based on a key a specific instance of a service can get it’s unique settings.
Making the solution really scalable.

Settings

One of the most important fields was the “Time to Live” field. A field in which was specified how long the settings record is valid once it is read by one of the service instances.
Once the life time expires, the service flushes its configuration and is forced to reload the actual settings.

By giving the “ Time to Live”  a short value (in this case between one and five minutes) the service can be reconfigured in nearly real time without having to address the service desk and the supplier.

For some projects implementing custom entities can be too much, not worth the hassle.
But giving an environment in which you don’t have administrative control on platform level, this approach can be recommended as it allows the local CRM administrators to alter the settings of the services communicating with CRM without having to have access to the platforms on which the services are residing.  It even can be used for services hosted on an Azure environment.

A big win!

Leave a Reply

Your email address will not be published. Required fields are marked *