Our (ahem) glorious OneStream planning book
As I write this on the 12th of December, 2022, I realize that it’s just about a year since the book Celvin and I wrote came out. It has sold, and sold better than hoped for. Our egos believe that this is because we wrote it, reality suggests that this might be true but a more likely reason is because the book serves an audience starved for deep theoretical and technical OneStream planning content. With every endeavor it is easy to look back and think of missed opportunities and mistakes; we wouldn’t change a single word. For two introverts, that’s a pretty bold statement but we think the book’s work stands up to that level of quality.
So just what’s in it, Cameron and Celvin, or is that Celvin and Cameron?
The following will act as a précis to the book.
OneStream Planning: The Why, How and When is available at OneStreamPress.com
Pedagogy
We felt that if we showed our readers merely how to do something we would have failed in our educational effort for without understanding the why behind a technique or approach, the reader will inevitably fail in his or her OneStream implementations and administration. This is not speculative theory for we have both seen OneStream code blindly copied and pasted with the sad result of suboptimal or simply broken functionality.
Scope
The scope of book has three broad themes: good (not a subjective best) practice in all things OneStream, Cube-centric operations, and expanding OneStream beyond traditional performance management through an embrace of relational data.
Use cases
The book also presented an opportunity to inform the way we have learnt best: via business and functional use cases that provide context to code. Code without that context is largely incomprehensible when complexity is anything other than most basic. The Cameron and Celvin (or is that Celvin and Cameron) Coffee Company is used to provide those use cases.
Creative process
While the chapters were largely written by one of us or the other, (the first three chapters are mine, the latter three are Celvin’s), every sentence was examined by both of us, seemingly endlessly debated, and then finally agreed upon. Moreover, as we wrote each made suggestions to the other. Celvin’s were largely technical in nature, mine were more organizational and structural. We continued this constant revision practice until who wrote what exactly faded into the past although our respective chapters do reflect our voice. For better or worse, purchasers of this book are getting the combined professional essence of the two of us.
Chapter 1: Theory, Philosophy, and Practice
This chapter is a mix of functional and technical practice with the functional principles the distillation of more than 25 years of performance management consulting. It was incredibly satisfying to put these beliefs into words and just as cathartic as there are statements that need to be said and yet can be incredibly impolitic if not presented with care. I got to write them, no matter how provocative (and some of them are), and I get the last word. Perfection. Seriously, when you read this section, pray realize that I put an awful lot of thought into what I wrote. If wisdom is applied experience, the principles of planning content fit that category.
In the same vein I covered common OneStream technical planning practices. As noted, some are (mildly or not depending on your perspective) controversial, e.g., OneStream is never going to pry Excel’s hands out of FP&A so why try? Other things like Direct Loads vs. Imports, Aggregate vs. Consolidate, basic extensibility, and the role of BI Blend vs. that of a Cube are all there as well and are hopefully just as thought provoking as the functional principles.
Chapter 2: Core Planning 1 – Data and Calculation
This chapter is far more technical in nature.
In its first section, the chapter goes beneath the covers to review how OneStream stores Cube data in its fact tables, what NoData, Real, and Derived data really mean, getting rid of zeros, the impact of the Level 2 Data Unit (maddening, sort of understandable, and thankfully work-aroundable). Hacking OneStream’s tables…oh, how can I convey how incredibly satisfying to suss out how OneStream really and truly stores the numbers we look at in Quick Views, Cube Views, and reports of all nature was and still is. I probably need to get a life but writing the normalized query (code is in the book) to pull out what’s really there was fun. Yeah, I need to get a life.
The second section is where I think all beginning to medium skill OneStream practitioners will find value: understanding and calculating data using Data Buffers. If such a mythical reader were to understand one thing in this chapter, knowing that api.Data.Calculate in the middle of a Data Buffer loop is a Bad Thing would be it. Buffer calculations are fast, but only if you do them correctly; they can be dog slow with very little effort.
The chapter goes on to show how to break the Data Unit using MemberScriptAndValue. When I first moved to the OneStream world I was told, “It’s impossible to write outside of the Data Unit.” That ain’t so and this chapter explains just how to do that. Liberating stuff.
The penultimate section is an entreaty to COMMENT YOUR CODE. Please. Good programming practice demands it as does our collective sanity.
Lastly, there is a review of Hungarian notation and CamelCase naming styles and the power of custom classes. Standards matter.
Chapter 3: Core Planning II – Command and Control the Cube
Understanding data and writing efficient calculations are key to successful OneStream practice. Just as important are techniques that drive metadata selections in user artefacts such as Cube Views, Member Filters, Data Management Steps, Dashboard Parameters, and any other place that text is used. XFBRs are incredibly powerful with their usage limited only by your imagination and ability to code. Once you understand the basics, their power becomes obvious.
What is not obvious, or at least not to me, is the role of Scenarios in planning applications. Like so much of OneStream, they are highly configurable and making them work can be a bit of a shot in the dark. I tried to break down every single planning-centric property and illustrate how they work in practice and what good practice is.
If the preceding sections were about enabling data in its loading, calculations, and presentation, the end of this chapter is all about restricting it. Conditional Input Finance Business Rules (eh, I get it, I don’t like it) vs. Data Cell Conditional Input (oh yeah, I get it, I really like it) and what I believe to be the only full use case-driven example of Slice Security with users, groups, and inheritance are reviewed in excruciating detail. I have never logged onto a single application with so many fake usernames as I did with this section. I tried (and I think succeeded) to make it just stupidly complex enough to highlight the power and pitfalls of security by Slice. Natalie, Jessica, Amy, Neviana, Sandra, and Tiffany all make an appearance.
Chapter 4: Planning Without Limits
Do you like code? Lots of code wrapped within specific use cases? If so, Chapter 4 onwards will be as mother’s milk to you.
Celvin is a huge advocate of going beyond the in-built Cube and addressing large and rapidly changing data sets that are not good candidates for Cubes when it makes sense. Only OneStream provides this flexibility. Only Celvin’s chapters give this complex topic the attention they deserve.
Relational Blending, OneStream’s technique of blending the two data types, are conceptually discussed and technically examined. The technical aspects are code oriented and cover:
- API Methods
- Cache levels
- Their retrieval with dynamic Formulas
- Data Mart schemas
- Sample retrieve SQL
OneStream’s own Specialty Planning solutions are Relational Blending within a predetermined framework. This chapter’s subject range is unmatched – data storage, field usage, custom XFBR calculations, security, data loads, installation and initial configuration, the user interface, differences between the multiple Specialty Planning products, custom event handlers, the role of Globals, and an overview of custom solutions vs. OneStream’s products are all dissected and dispassionately reviewed. There really is nothing like this: not in blogs, not in presentations, and not in OneStream’s own documentation.
But this is just the beginning of extra-Cube content.
Chapter 5: All Data Points Lead to Reporting and Analysis
Data is fine, data is good, and data is after all why customers purchase OneStream. But data without a way to access it and then present it is at best difficult to understand and at worst useless. Design matters, particularly when Dashboards are in play.
Celvin conceptually covers how a Dashboard should work (you would, perhaps unless you’ve experienced the horror firsthand, be surprised at how bad, nay practically evil, dashboards can be unless care is take) and then how to make all of the constituent bits work together.
Data must be accessed both in a UX and externally. Fast Data Exports (FDX) is one way to get data out, really out, of OneStream. As always, a simple use case sets the context for that data export, the code to perform said export is provided along with an explanation as to objects methods and properties and their usage within an Extender Rule and via a Cube View itself. Yes, you read that right (I was certainly surprised when I read his draft), a Cube View itself can act as a data source. Good grief, is there nothing that OneStream can’t do? Only maybe, but probably not.
Access large data sets is done in OneStream via BI Blend. Every aspect of that module – potential use cases, functionality, architecture, and configuration — are detailed. That’s BI Blend as OneStream presents it. Celvin then expands it by using a REST API Connector Rule to pull the USDA’s farmers market directory and data directly into OneStream. When I read this section, I realized that Celvin is likely a genius, possibly probably quite likely definitely a mad one. Seriously, this is cool stuff and definitely Outside The Box yet all doable within OneStream. Amazing stuff.
Chapter 6: Specialty Planning Analysis
Specialty Planning is relationally based and so user analysis cannot be performed using Quick Views or Cube Views. The OneStream way is to use Pivot Grids which are akin to Excel’s Pivot Tables.
This being OneStream, configuration and code, glorious code, are part and parcel of using them effectively. This chapter reviews that and goes beyond in providing code to bring Slice Security to these Pivot Grids via Dashboard Data Set Business Rule which is Not Possible except of course Celvin shows exactly how to do just that. Magic and incredibly useful in applications that are more than science projects.
Analyzing relational data goes beyond Pivot Grids and includes Table Views which are excitingly now (as of version 5.2) available directly in Excel for both reading and writing to Specialty Planning’s base Register
Lastly, techniques for bypassing OneStream’s in-built Stage and instead interacting with custom tables is explained.
What do we have?
We like to think that OneStream Planning: The Why, How, and When performs the vital role of an encyclopedic repository of OneStream planning practice in an approachable manner.
We hope you do as well.
Purchase your copy of OneStream Planning: The Why, How and When at OneStreamPress.com
