It’s the small arrows on a flowchart that are the killers.

In every project, these little arrows that depict data moving from one process to another, often result in massive amounts of work. Generally, they entail complex business rules that need significant embedded logic.

The simple “move data to X” is actually: “Check if everything in the last process worked correctly, then make sure that the follow data is complete, then check if X is less than Y and if so do Z, while this is happening sequence everything so that the order is maintained, save the state in case the machine fails at this point,  add the country code to mobile numbers removing the leading ‘0’ and replace leading ’00’ with ‘+’ and then encrypt the data using defined crypto before dropping into specified location and kicking off a script.”

Complex business rules are a common part of every project. Getting them right is a key element in the ultimate success of personalized customer communications.

We’ve often started a new client project under the premise that the rules are relatively straightforward.Very soon, we discover we’re looking at incredibly complex logic. Often, it’s only when we are knee deep in the project that the rules become self-evident. It’s part of the value we provide.

Some of the simplest rules involve data transformations – i.e. change a binary date to a readable date. Most are more complex though. For example if a customer has received three electronic statements without unsubscribing and has opened at least one, then include a paragraph about turning off the paper in the next run. The last step would be to mark the customer as ‘converting’ in the migration database.

IT departments of today are stretched and they rely on us to be flexible and nimble in the project process. This is part of the value that we provide (puzzle building in a very grown up environment). One of the coolest projects we run is  where our solution combines data from 10 different data files that arrive at different times.  It splits the output into batches and holds data until it is complete in each case.

Flexible framework brings the ‘little arrows’ into play

In most cases it’s easier for our clients to provide the data in the available format, than to try  fit it into one of our standard formats. This is classic ‘integration’ work. Thankfully we have a bunch of dedicated integration engineers whose sole function is to take customer data and turn it into useful information in the form of a document or communication.

The key to these little arrows is to map out the requirements up-front. Then turn the requirements into a functional / technical specification. This means that everyone can agree on the work and the outcome required before the project starts. The documentation process is sometimes just about making people think about what they want to start with. However, that’s’ not always possible and in many instances the rules are only apparent during the implementation process. Having a flexible framework for the development and implementation of the rules is therefore really important to the project.

Data manipulation, transformation, consolidation and translation are necessary parts of IT processes. The key to successfully incorporating these into a project is to spend more time upfront, understand the data and document the requirements within a proven framework.

We aren’t put off by the little arrows – we revel in the challenge.

Sending personalized customer communications and need to get your complex business rules right?