Wednesday, October 8, 2008
IT vs. Business Role in EssbaseThe 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 MethodologiesI 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 versionI 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 downloadsI 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
|