The SAP BI product portfolio is big. We encounter reporting tools, dashboarding tools, and data discovery tools. Some support mechanization while some support on demand analysis of data. Given the sheer multitude of these tools and the complacency of developers in either a) being bound to the tools in the portfolio they are licensed for or b) being unmotivated to learn other tools in the portfolio, it’s not uncommon to uncover choices made to use the wrong tool for the wrong use case.
I’m going to pick on a customer. This customer will remain nameless. They are good friends. However, I’m going out on a limb and I’m going to guess that this story will seem vaguely familiar to you. You’ve either done this yourself, or encountered another developer that has done the same. In this example, they used SAP Crystal Reports as an ETL tool.
Gasp.
In this effort, literally 7+ years ago, they identified a resource with Crystal Reports skills, a requirement to extract some data, shape it up a little bit, and load it into another database. In that solution, Crystal Reports did the data acquisition and transformation, and some custom SDK code bulk loaded that data into the target database. The biggest blasphemy here isn’t that they used Crystal Reports for this effort (it’s a big one…not getting off that easy). I think the critical flaw was not in taking an inventory of the technology portfolio to make an appropriate selection of tools, where they would find they had access to SAP Data Services. And, Data Stage. And, Informatica. Yeah, they were that big they had just about one of each.
The real insanity began for this customer when they were required to migrate all of this to BI4.1 and it didn’t scale as well as it used to.
Fulfilling the Needs of the Business
I fully recognize that when someone in the business says “jump” you genuinely find yourself asking “How high?”. You also find yourself being told they need it like “yesterday”. We often find comfort in tactical solutions to these problems that make everybody happy and use the tools we know but we don’t always articulate the difference between the value in banging out some code and taking a proper approach to implementing a solution that won’t cause other issues in the long run.
Big Issues
How do you tell a business user that doing something so quickly that you have to use Crystal Reports to extract and transform 10’s of millions of rows of data will adversely affect the performance of your SAP BusinessObjects landscape? How do you make them understand that a simple, single node landscape will likely be brought to its knees as it processes those 10’s of millions of rows of data across 100 or so reports as it does its processing? The business doesn’t care. They are driven by results and making decisions based on that trove of data.
That’s where being a developer in this ecosystem is two parts technical, one part diplomat. OK there may be a bunch of other parts but let’s use those in this context. Diplomacy takes time and practice. For you, the business doesn’t want to take the time to describe to you the risk of doing nothing vs. doing something (potentially desperate). For the business, you can communicate these risks, your proposed, tactical solution, and the steps beyond to ensure you are not creating more problems than solutions and their associated costs. Everything comes at a cost.
So take a cue and think about picking the right tool from the toolbox from the start for your business problem. Be able to communicate the inherent risks in using inappropriate tools and how they can also adversely affect other BI in the process. In the end, we all want to strive for high tool and BI adoption/consumption. Don’t mar that by adding fuel to the fire with bad technical solutions.