I recently had to tell someone that there was no “right answer” for a particularly thorny SPM system design question. There were a lot of answers that could potentially work, each with pros and cons. The solution we would eventually choose would be, with luck, the “right-est answer”, or maybe, the “least wrong” answer. As I’ve made a career of demonstrating, incentive compensation management software has to solve a lot of very bizarre business problems, and the way it does that is more or less elegant depending on the business policies, the available data, and the reporting requirements at the end. So how do you know you’ve picked a relatively right answer? I think that is a reflection of where work can be done in the system, and whether you have given the work to the part that can do it best. By my calculations, there are four ways to get results into and out of a system, what I call the Axis of Heavy Lifting:
- The rule or calculation engine
- Data integration, including pre- and post-processors
- Manual intervention – the users
The rule engine is all about handling the IF-THEN logic and doing the math, and it generally it does that very well. But doing lookups of data for nit-picky conditions is a drag on the system and has an impact on performance and the users’ ability to maintain the system.
Data integration, on the other hand, is a great place for moving data and looking up information stored across objects. But embedding a lot of IF-THEN into pre-processors isn’t generally a great idea because it moves business logic away from the business users and buries it in the IT department. And certain forms of logic really bog SQL down. Reports can do certain calculations if needed, but anything beyond fairly simple aggregation and you have the problems of have business logic hard-wired in a system that’s generally out of the users’ control. And it’s really not a lot faster to do the calculations in reporting than it would be to do it in the rule engine. Finally, there are the business users of the system. Theoretically they could figure out all the results and enter them manually, though that’s clearly not practical and it would be hard to show ROI in a system that requires that. But where there are exceptions that can’t be neatly handled by the system, and most importantly, are not so numerous as to be burdensome to deal with, manual intervention is a perfectly acceptable design – that’s why the applications have user interfaces, after all.
In an ideal world, the system would look something like this:
In the real world, with real world bad data, exceptions to exceptions, and detailed reporting requirements, it often ends up looking more like this:
That’s hardly elegant, and we strive to do better. But at the end of the day, you have to ask yourself whether you given the heavy lifting to the part of the system that can do it best? If so, that’s probably about the “right-est” answer you’re going to find.