Drinking the Web Intelligence Kool-Aid

Kool Aid Man

I admittedly stole that catchy little phrase from an old manager and good friend of mine, Chris (hi Chris). About four years ago while working for him, our organization made the determination that we were going to do all new development on Web Intelligence (Webi) going forward. This was a very progressive and bold choice to make with XI R2 being in its infancy.

Fast forward four years or so to the Business Objects User Group meeting I presented at today. I got to present on Sherlock and nursing a growing environment, but also got to hear some great presentations all in the same day. One topic that came up in the final “open discussion” was the pain of migrating from Desktop Intelligence (Deski) to Webi. I will use the term “passionate” to describe that discussion. It got me thinking about what made people so hot over Deski going away.

Having been a classic Business Objects guy and reformed Deski developer, making the switch to Web Intelligence and Crystal Reports was quite the transition for me (especially considering I barely knew how to spell Crystal Reports). What I’m saying is, I get it. I hear a number of common arguments as to why people will NEVER let go of Deski. Note that this blog isn’t really about a feature set comparison. It’s about the approach to making the conversion. So, to name a FEW arguments I hear/read:

– No free hand SQL
– No folding
– It’s slower/is a memory hog
– Lack of support for various data sources
– Lack of support for some of the output (although this is a slim margin)

I can’t argue there. However, if moved gently towards Webi as the reporting solution, I think user satisfaction ultimately increases and support costs go down. It seems to me that people who are die-hard Deski fans refer to it as an all or nothing transition and I guess today I want to layout that it really isn’t. There is no reason to believe flipping to Webi will be like drinking from the fire hose. Let’s circle around a few major steps to make the switch to Webi in a quasi-iterative approach.

Draw a line in the sand for new development. Don’t assume on Friday that on Monday everything is going to flip to Webi. Start taking in new requirements for reports and first attempt to solve for them in Webi. The universe is the same on either end. If the universe doesn’t meet the requirements as is, modify the universe, don’t just revert to free hand SQL. I’m talking to you…you know who you are…

Enable Power Users and educate them. Power Users can be one of your strongest advocates if you give them the data and the tool they need. Without that education, their use of the tool set will never live up to its fullest potential. They will help others come to the realization that when given the rights to create their own docs, they can accomplish 95% of what they need with common Webi functions vs. the hard stuff we still think we need Deski for.

Analyze history. Understand what content exists in your environment, if it is being used, if it requires conversion, etc. Tools like Sherlock are ideal for giving you this insight. If you do not need a report, not only should you not convert it but you should not keep it unless bound by regulatory rules. If that is the case, consider my document archival thoughts.

Test the big migration with the report conversion tool. We all know this tool is not perfect. However, I really like to stand this up in a sandbox and let the tool run on the Deski document stack for a test run to see what percentage of my documents it is going to convert in a non-impacting environment. This step will help you forecast the level of effort involved AFTER the report conversion tool is actually run. I understand that the conversion rate is much higher nowadays, but results will vary by environment and report.

So what is left? Some percentage of your reports that require migration that the report conversion tool couldn’t help with that may require re-architecture to follow best practices in using universes and renegotiation with clients on some layout issues or output type issues.

But what about all my free-hand SQL reports? You are already thinking it, aren’t you? First, don’t hack your Webi reports to overlay the SQL in a Webi report. The semantic layer is one of the key components of this architecture. Why throw it away? Why hack up all that elegant SQL your universe generated for you? Off my soapbox. If you absolutely need to use free hand SQL, it may be time to start embracing our Crystal Reports heritage and learn the tool. I will never admit this to my Crystal Reports buddies, but I do kind of like it and it really wasn’t that hard to pick up once I got in bed with it. You will find that it will be a better enterprise reporting solution than Deski ever was (mostly). Uh oh, I think I just thought of another blog post topic. Oh well.

I think adoption of a web-based reporting platform is an important step to springboarding organizations towards cloud computing concepts, the ability to promote BI in a mobile platform, easier extranet deployments, and overall, getting with the 21st century (no offense). Consider it a stepping stone to reporting goodness.

 

Leave a Reply