HomeDownloadable ResourcesContact Me

Wednesday, October 8, 2008

IT vs. Business Role in Essbase

The Business units have a functional perspective while the IT department will focus on the technical processes.  This is rarely disputed but also rarely analyzed as to how well they complement each other.  In regards to Essbase, the line that separates these two elements is a bit blurry, although less so with each new version.  Sometimes, however, this is *not* for the better.

While IT has the focus, knowledge, and understanding of things like data extraction, transformation, data loading, automation, backups, disaster recovery, and so on; the business units are often still tasked with maintaining different hierarchy elements.  The reason is simple enough, because it is much more of a business issue than a technical one.  With Essbase, however, the tool that manages hierarchies natively is the same as the tool that manages all the other technical items.  Is this a bad thing?  No, not really.  What is needed, and what has been provided, is a tool making this process more of an enterprise managed resource.  This is good, as long as you are in a big company that can afford the relatively large cost of taking this route.


For the rest of us (and by now you should know I tend to represent the little guy more than the big groups), I would like to talk about the logical separation of this process.  It's rather like a "Doh!" moment at first, but the more thought applied to this, the more clearly you might see how it really shouldn't cost an arm and a leg to manage something so far from the company's bottom line.

Okay, the obvious: let IT handle the update, and the Finance/Accounting/whatever group handle the definition.  So far, so good.  But how best to supply the definition in a way that is actively managed without excessive cost?  Should you really have to go out and pay tens or hundreds of thousands of dollars to control your chart of accounts or regional structures in essbase?!?

The answer: No, it should be inexpensive and easy.  Easy enough so the business unit is comfortable without learning new skills, at least.  Don't let IT pull your business units into a techno-jargon filled environment and make it into the hierarchy equivalent of a scientific graphing calculator with mode buttons and function keys.  Instead, realize that together, IT and the controlling department must arrive at a working solution that is easy on everyone.

Step 1: ensure that EACH AND EVERY hierarchy element has a person assigned to be responsible for it.  For me, this includes giving each element a formal name.  The #1 best way to eliminate confusion is to provide a unique, fully understood name to every process, object, event, trigger, or other conceptual entity that requires any form of control.  You should end up with a table of elements and points of contact that can be agreed upon by everyone.


Step 2: determine how hierarchy elements are to be dealt with for the following aspects:

  • Adding new members
  • Validating data issues related to them
  • Changing descriptions/aliases/attributes
  • Deletions

Step 3: determine the frequency for which updates will occur and how they are logged or documented.  While often the new elements could be added whenever the data is loaded, it is this kind of assumption that should be explicitly turned into a policy.  Not all IT people would understand why it's a bad thing to update a regional structure in the middle of a budget process, for instance.

Step 4: Package the details into a policy.  This doesn't have to be complicated, and in fact, could be nothing more than a text file (yes, written in notepad!), that includes a simple list of named events, event triggers (i.e. key dates, data loads, phone calls, email, etc...), contacts, processes to be completed (and by who), and any other relevant details.  It doesn't have to be a book, just be complete enough to guide the process at the highest levels.  For instance, if each process had it's own process document, the policy should only have to refer to the process documents.  The goal for this document is to be short and succinct enough to be a one or two page "daily reference" or at most, a turn over document cover sheet.  I call mine the "change control master", and it has enough detail to act as a checklist.

The overall concept is that both IT and the business unit work "their side of the fence" in a neighborly fashion, respecting the need for the other side to stay informed.  A formal policy is not designed to add bureaucracy, but to help illuminate the process so everyone can navigate more effectively when odd-ball events occur.

6:49 pm est

Monday, August 18, 2008

Essbase Backup Methodologies
I admit it.  I like to keep things simple.  I am also a rather complex person.  Is this a dicotomy or a natural result of one begets the other?  I don't know, but what I do know is that simple cannot be defined from a universal perspective.  What is simple for one person is more often than not very complicated for others.

Take for instance the task of backing up databases.  The simplist approach from an IS perspective is to just throw a tape drive at it and call it done.  Most IS professionals will tell you that they have software than can back up files while they are in use, so this is all that is needed.  While it's tempting to laugh at this concept, it's often hard to convince certain people that this is not the wisest choice of actions to take.  What's worse, the tape access to the machine is often done at the worst possible moment during the day (thank Murphy for that one), in the middle of your key calculation -- despite assurances that the backup window is set in stone and won't be violated.

Do I blame IS for this?  No.  I blame the underlying concept of backing large files up directly in a non-static environment.  This is the issue, and once you understand that, you can free yourself from the problem entirely.  It really is that simple.  No matter how big your database is, the backup must be of high enough priority to justify keeping a static copy of the data.  The backup can access this "dormant" copy at any time, especially if that copy is not on the same drive set as production. 

So how best to do this?  Well, this gets back to the definition of simple.  In my case, I use the archive.cmd file from the downloadable content section here.  It's a simple command script, meaning that you don't need to have additional skill inventories to support it.  What you DO need, is a good understanding of notepad and command scripts though.  This "throwback" technology is a lost art, admitedly, but easily mastered -- at least sufficiently to do the installation and extremely infrequent maintenance for the backup.  Other than reconfiguring the script, I haven't changed it in many years (and I haven't even edited the script in more than two years now).  It's complete, one call and it does the whole thing.

So what else?  Well, how about what and when?  I perform a backup whenever I do the primary data load for any production database.  This way, the downtime is just a part of handling the data load itself, and kept minimal at that.  I also keep three copies of the database, although the script can do up to 9 generations without modification with any number of uniquely named "types".  Why three?  Mostly to allow a Monday recovery of Friday's data -- but this was just a matter of simplicity on the automation side.

What else should be considered here?  How about the server's configuration itself?  I have three drive sets for the production server.  The "C" drive is dedicated to the operating system, as most people would guess.  The "D" drive is for backups ("Data"), and the "E" drive is for essbase.  This simplicity is just a matter of isolating one set from another.  It also allows me to tell IS to backup the C and D drive however they want -- although I recommend a Weekly Full drive C/D backup and Daily Differential backup of D.  Either way, using this configuration keeps things simple from an isolation perspective, even if it seems like three drives are otherwise more complex than one.

Yes, I often make things more complex on the automation/design side to keep them simpler on the maintenance/user side.  In other words, it's not about making it simple for me to design, but simple to use and maintain.  Often, the two are in harmony, but not always.

-Doug.
1:08 pm est

Sunday, July 6, 2008

Updated ESD (again), and uploaded new OtlComp.exe version
I fixed the cosmetic bug in ESD, which affected filtered with Meta-Read assignments.

I've also uploaded an updated OtlComp.exe, which compares two outlines for differences and now allows command line arguments.  Not much checking is done on the arguments, so until I beef that part of the logic up, it's considered a definite "beta" feature.

I haven't played Entropia Universe all weekend long, so I'm going to do a quick check on the forum and then go spend some PED.  If this sounds like greek to you, visit www.entropiauniverse.com, it's not a cheap game to play (even though it's technically free), but as a hobby it's a lot of fun, although definitely not for everyone.
6:00 pm est

Saturday, July 5, 2008

Updated ESD, adding it to downloads

I took a detour in my update priorities because something was bugging me.  I was experiencing strange behavior in some applications and needed to track it down.  It turns out that my conversion of the Essbase Version 7 API was flawed and some of the length constants were set wrong.  The behavior caused for loops to execute once and move on, so it didn't look like any kind of API issue at all.

Anyway, I finally resolved the issue and ESD will be ready for download shortly.  So what is ESD?

Essbase Security Dumper -- it's a stand alone security dump that takes a snapshot of all the users, groups, applications, databases, and filters.  It also highlights key details and allows uploading the file back to a server (yes, I said "a", not "the" -- think about it).  So what kind of key details does it include?  Here are some outtakes of the file:

Server: Ess_Prod.SomeWhere.Com
   Date Made: 7/5/2008 10:20:08 PM
   Security: Yes
   Logins: Yes
   Default Access: None
   Validity: 90 Days
   MinLength: 6 Characters
   TimeOut: 1500 Seconds
   Check Frequency: 300 Seconds

Group: Accounting_Dept
   Access: None
   Users: 00_Accounting_User, JoeBlow, ...

User: 00_Accounting_User * Account Disabled * Password Expired * Inactive *
   Access: None
   Last Login: <Unknown>
   Groups: Accounting_Dept, Balance_ReadOnly, ...

User: JoeBlow
   Access: None
   Last Login: Monday, June 23, 2008
   Groups: Balance_ReadOnly, HR_Dept, ...

Application: BalFY07
   Description: Balance Archive
   Loadable: Yes
   Autoload: No
   Default Access: None
   Connects: Yes
   Commands: Yes
   Updates: Yes
   Security: Yes


Database: Balance
   Description:
   Loadable: Yes
   Autoload: No
   Default Access: None


Filter: AndersonM
   Active: Yes
   Default Access: None
   Read: @IDESCENDANTS(Organization)
   Filtered: Actual,@IDESCENDANTS(AndersonM)
   * Filter is not used by any users/groups *
   *** Filter failed to verify (ref=1054012, msg='Invalid syntax in filter line 2')


Filter: Budget
   Active: Yes
   Default Access: None
   Read: @IDESCENDANTS("Scenario")
   Read: Forecast
   Write: Plan
   Read: Budget00
   Read: Budget01
   Users: PL_Budget


10:52 pm est

Friday, July 4, 2008

First Blog.

I've owned the DougWare.com domain for more than 15 Years, and I've never really done anything with it except use it for email.  I'm trying to change that, and today I've decided to put the website together with some basics.

I hope get some downloads available from the numerous utilities I've created over the past years (most -- but not all -- are essbase administration tools).  I also hope to post blog entries for the Kaleidoscope conference and upcoming events.

While I've been known to go on (and on) at times, I find that blogging isn't much my style, I'm too busy sniping on the two or three forums that I haunt daily (more on that later).  So, I think this is about all for today (I have too many programs to update and an entire web site to publish, or you'll never get to see this).


-Doug.

4:15 pm est

2008.10.01 | 2008.08.01 | 2008.07.01

Link to web log's RSS file

DougWare was a name given to me by a former boss that kind of stuck.  I purchased the domain back in 1992 and have had it idle almost all the time (except for email).  At first it was because I tended to handle everything that was *not* hardware or software, and dougware was the "in-between" stuff.  Lately though, it's been software only and focussed on tools for Hyperion Essbase developers.

Ask the Expert!

For free email business advice, send your questions, comments or ideas to dougb@dougware.com. For issues that are of particular interest to the Essbase community, we may publish your questions along with our answers on this web site.  Since there are so many forums that deal with general essbase issues, I will specifically be addressing VBA/VB API issues where the code shows no overt signs of problems and needs an indepth review.

Join Our Mailing List!
By joining our mailing list, you will be the first to know about:
 
  • Breaking news about our business
  • Helpful tips
  • Exclusive special offers
 
To join, type your email address below and then click the Go button.

DougWare_Background.jpg

This site  The Web