Contending With BI Disruption

SAP is doing a lot across its development groups to minimize disruption in customer landscapes. In other words, “hey, let’s not introduce change that significantly disrupts business processes for our customers.” Great sentiment. As an SAP Partner and developer of solutions based upon SDKs developed by SAP, I can relate. We develop software, we sell software, and we try to not ruin the lives of our customers every time they have to upgrade it. It’s not easy, and we don’t maintain anything near the complexity of SAP BusinessObjects.

In a twitter exchange with DSLayer alumn and friend, Andrew Fox a question was posed as to whether or not SAP BusinessObjects Explorer Information Spaces on a UNV consuming a BEx Query was a valid solution in BI4.1. I took the position that if it solves a business need today and is valid/supported five years out minimum, why not? What is the cost of doing nothing if nothing else solves the business need? But that lead my brain down a rabbit hole as I thought about that conversation in the context of disruption both based upon tool selection and aging content.

We are in a really interesting point in time with SAP BusinessObjects. We have a large number of tools to develop BI content with (and subsequently support) and a growing roar in the community that OMG WE HAVE TOO MANY TOOLS SAP YOU HAVE TO DO SOMETHING TO MAKE THIS ROADMAP BETTER.  Then in a conversation in the next room another group of people in the same community says “don’t disrupt me”. Wow. Rock and a hard place, am I right?

I got to spend time with my friend, Adam Binnie last week at the 2013 ASUG SAP BusinessObjects User Conference (SBOUC) in Anaheim, California. We were talking about several topics, but one thing Adam said (via Saurabh Abhyankar) that struck me as profound, and spot on, was…..

“You can expire tools but you can’t expire content.”

As a guy that develops software for SAP BusinessObjects customers to help better understand the behaviors and constitution of an SAP BusinessObjects landscape, I don’t think he couldn’t have said it any better. We help customers understand who is using BI content, who is not using BI content, and why. We try and assert value and related costs associated with that BI content. But, the second you ask to take something away from a user, they put their defenses up.  I’ve literally run up against customers with content that is quite possibly 12 years old.

The last tool we were faced with the end of life on has been Desktop Intelligence. I think. Performance Manager was in there somewhere but probably not as recently. Others? Maybe. But the point is, Deski hit end of life and we had to start working on a solution to that. SAP gave us the Report Conversion Tool. OK Business Objects actually did before that.

Now, we are facing the convergence of SAP Dashboards and SAP Design Studio, a question mark for many on the path forward for SAP Crystal Reports and SAP Crystal Reports for Enterprise, and even where Web Intelligence and Crystal Reports may or may not step on each other. As we ask SAP to start pulling the plug on some of their overlapping tool sets and giving us a clear path forward for that content we will never think of letting go of, the lingering fact is that we need not just new tools, but also utilities to migrate content between formats to migrate ahead. Now it’s just getting muddy. We’re trading one proprietary format for another. We’re taking years of content and turning it into a different type of content that will have a shelf life of N years. But is N years enough for you?

Good or bad, I think we have to ask SAP that the utilities that migrate these pieces of content between formats become as universal as exporting a document to a PDF or saving to Excel in the context of deprecating tools. That’s nebulous. I know this to be true. Feature parity is a big deal there. However, a risk in not doing so is that it gives customers a reason to re-evaluate technology selection if they have to start over anyway (Deski to Crystal Reports where Webi isn’t a fit anyone?).

But going back to that idea about expiring content… if we can’t expire the content and we have to take it forward, are customers to convert it by hand? Ouch. I DON’T PUT ALL OWNERSHIP OF THIS ON SAP. Adam was spot on in the quote above. Customers need to take some accountability here. It’s not accountability to SAP. It’s accountability to end users that use BI in your organization. It’s an accountability for BI governance and quality to ensure that relevant, trusted, and current BI live on within SAP BusinessObjects landscapes (not going into compliance here).

I’ve written a particularly long-winded post here. One that doesn’t necessarily present a solution in its entirety, but instead lays out the gap in customer perceptions about tool choice, the pains of retiring a tool or tools in selection of another, and dead weight BI.

As for Andrew and his Explorer InfoSpace on a UNV using a BEx query. Go forward. Make the business happy today. Hopefully by the time it becomes a problem someone will have figured out the solution.

One thought on “Contending With BI Disruption

Leave a Reply