Success with Matching Engines - what does that look like?

Implementing a Matching Engine application presents a host of challenges. If you're responsible for such a project then you need to give serious consideration to a number of critical system components. Here are just a few of the questions that you'll ne to think seriously about:

• Is this a batch "slice and dice" implementation or more targeted and event driven?
• Is the scope of your match data items clearly understood?
• Have you quantified the range of operators that your match rules will need to cater for?
• How will you test your matching rules and avoid overlapping result sets?
• How will you manage your rules through quality assurance and release processes?
• How will you know what to exclude from your results set in order to avoid false positives?
• How will you see the audit of the match rule decisions?

The above questions are fundamental to your chances of success. You need to push your development team to bake the answers to these questions into your development from the start, otherwise you could experience legacy design problems even before you've gone live.

It is sometimes easy to mis-calculate the complexity of matching and rule engine implementations. Something that I try to keep in mind when tackling complex applications like these is a simple description of the problem space. For a matching engine implementation, I like to think of my problem as follows:

"I am trying to design, develop, test, implement and support a system that tries to compare a constantly changing dataset to another constantly changing dataset. I am trying to do this comparison with a constantly developing and changing set of rules. If my rules are not correctly configured and tested, I run the risk of polluting numerous downstream applications with the poor results from my application. I would desperately like to avoid being the cause of an implementation freeze in my organisation."

So what can you do to manage your way through to a successful conclusion? Keep the following in mind during the project:

• Deliver often and keep the business close during the development
• Factor in time for rework - these projects often reveal their own requirements as they go
• Build regression test packs and maintain them
• Have your developers implement automated testing functionality to run these regression packs
• Make sure that your rules are treated like any other project artifact - test them before releasing them
• Have your developers tackle the problem of identifying overlapping matching rules

All the above will put you in a position of control. You know what sort of shape your application is in and whether the latest changes have introduced problems in functionality that was previously working. You can have confidence that you have rules management and testing controls in place, guaranteeing the quality of your releases.

You never know...

You may make such a success of it that you'll be asked to do another one.