Closing Thoughts
I have been pleasantly surprised with the functionality afforded by cubeSavvy even this early in its development. The “basics” are all more or less in place. cubeSavvy is not without its faults or defects though: I did experience a handful of issues during testing that required me to either manually refresh the page or navigate to a different section and then back to the section I wanted to be in. I imagine this is to be expected for now and am sure that Mr. Gates is hard at work on fixes for the issues I experience, if they haven’t been fixed already.
As I mentioned on the first page, I find myself intrigued with the cubeSavvy value and administration proposition, which is dispensing with some of the complexity of Planning (and its deployment) and going back to a more Essbase-centric view of the world. This is a possibly interesting solution for those people not wanting to make the leap to Planning but wanting to have a web interface in front of their cubes.
At this point in time, I think cubeSavvy would be well-served to take the following course of action:
- Focus on a polished user experience. There are just simply some kinks that need to be worked out to make the user experience smoother: bug fixes, text prompts, and the like.
- Adopt a strong visual identity. Speaking as no stranger to web development, using Bootstrap is a great foundation to build on. This provides for broad browser support right out of the gate and also allows for relatively easy theming. I would love to see cubeSavvy adopt either a high-quality or even a custom theme to really make it feel like its own entity rather than just the Bootstrap defaults.
- Really embrace the notion of being a front-end to Essbase and innovating on the Planning/planning experience (note that I mention Planning with a capital P and planning without a capital P). I think this is part of the game plan already, but thought I’d say it explicitly.
I’m really looking forward to seeing this project evolve and mature over time into a useful tool. If for whatever reason the business side doesn’t pan out, I think cubeSavvy would make a great candidate for an open source, community development driven project.
Keep up the great work, Harry.
Jason,
Excellent article. I had never heard of cubeSavvy but will now check it out.
Thank you for sharing!
Have you ever tried using Dodeca for budgeting instead of Planning? Just curious.
Doug
Yes I have used Dodeca – in fact, I rolled out one of the earliest and largest (at that point) Dodeca deployments several years ago! I am going to do a long blog series on Dodeca as soon as possible. As I said, I am working through the third-party Hyperion ecosystem this year and next on the list is something quite interesting, followed by Dodeca. Stay tuned. :D
Jason,
Two things I didn’t see:
1) How is dimensional security in grids represented? Does it follow the user’s username and so metaread filters would suffice or does cubeSavvy use a “ghost user” to do logins and handles security some other way?
2) Is there any way to pass grid POV, page, row, and column settings to some kind of calc script execution stage? I am thinking either the way Planning forms work with business rules (not bad, but could use some real improvement in the row and column area) or the way tokens work in Dodeca (even better because if you set the views up just right you can drive aggregations in BSO with row and column information).
Otherwise a very intriguing product.
Regards,
Cameron Lackpour
1. Dimensional security is handled by way of the user’s security — rather than all requests being marshaled through an admin user, the user uses their own credentials.
2. This came to mind as well and I almost commented on it since it’s highly relevant to what calc gets run on submit. At present I don’t think the product includes this capability, but speaking from my own experience, it is possible to do with just the Essbase Java API (i.e., generate your own calc based on a template that you parameterize). So… doable, if not trivial.
Cameron,
1) Jason is correct. You log into cubeSavvy with the same credentials you would log into Essbase. The only difference being that you would need to be in the cubeSavvy_admins group (either native Essbase or Shared Services) to create grids or cubeSavvy_users to enter data in a grid. Having users continue to utilize their own ID (instead of the “ghost user” approach you mentioned) has the added benefit of simplifying the logging of user activity.
2) This is definitely on my road map for the product. I will try to piggyback off the new Essbase as much as possible, since my whole goal is to stick with native Essbase functionality (and not bastardize it to death, as Planning has done). I envision being able to limit a calc to EXACTLY what is displayed in the grid – including rows and columns.
I’d be more than happy to hear any other ideas you have.
Thanks,
Harry Gates
That should read “piggyback off the new Essbase runtime substitution variables as much as possible”.
[…] you come up for air next week. It has been a busy week on my end, what with doing a fairly deep cubeSavvy review, building elegant/robust/awesome solutions for clients, polishing up open source Essbase […]