Picture this: The monthly performance report has just been received, but it’s missing some data. No errors were generated, yet the blank section on the output indicates something went wrong. The analyst sends a message to IT to report the error, and this starts the Easter egg hunt for the issue.

How many times has this happened to you or your colleagues? Whether you rely on a large single vendor, multi-purpose platform or multiple integrated systems, I’d be willing to speculate it’s a common occurrence. Beyond tracking down today’s Easter egg, how can we avoid the problem in the future or remedy our existing platforms?


System implementations are complicated. In particular, those introduced years ago run a greater risk of evolving over time and further burying the business logic that led to the implementation in the first place. Middle and back-office teams are used to quickly addressing issues on the fly, yet these fixes can be like Band-aids and tend to accumulate in a mismatched manner as years go by.

In nearly every data warehouse you will find embedded business logic gone awry. From complex select clauses with nested case statements to complicated table joins, the logic is rarely documented throughout the process and, as a result, teams are forced to spend time hunting for hidden data. Unfortunately, this issue is not limited to stored procedures in a data warehouse. The proliferation of platforms designed to ease the burden of ETL (Extract, Transform, Load) integrations between systems has added yet another rabbit hole for business logic. Tools that were intended to grab, reorganize and push data sets have been hijacked by well-meaning teams who change the information as part of the transform step. Whether this is under the guise of data validation or data cleansing, the net effect is that the information contained in the data set has been changed during the move, not just moved.


The third bad actor in the chain is the reporting tool itself. We all love sophisticated reporting solutions that can join information from multiple sources and present them in a controlled, consistently branded and repeatable fashion. However, these tools can fill an upstream gap in analysis or decomposition, adding just that slight tweak to the information to meet the reporting requirements. Once again, we’ve allowed business logic to become embedded in a scattered and undocumented manner.

Remediation of these challenges is never easy, and often put to one side or labeled “technical debt.” If there is the will and the resources to address the problem, we can:

  • Perform the code archaeology and identify the issue
  • Agree where in the process it should be handled instead of where it was easiest to implement
  • Build, test and deploy the fixes

How do we avoid passing logic Easter eggs down to our successors? Easy to say yet almost impossible to enforce: Discipline and good habits. We need to work as engineers, not maverick developers.


If you’re too close to the data hunt and have trouble identifying these issues, you may benefit from an external party’s perspective. Meradia has extensive experience analyzing how these complex legacy systems are integrated and troubleshooting issues that may arise. As expert consultants, we frequently diagnose software implementations for firms across the financial services industry. Proper planning can prevent poor performance, or in this case, proper preparation can lead to a smooth implementation and ease the cost of long-term ownership.

Download Thought Leadership ArticleServices: , Expertises: Clients: , Authors:

Christopher D. Sadala

Christopher D. Sadala is a Senior Consultant at Meradia with over 25 years of industry experience including enterprise data management, system analysis and implementation, system architecture, custom programming, database administration, data warehouse design, strategic assessments and report development. 

Skip to content