OracleBIBlog Search

Friday, September 25, 2009

BI and the Tools of Diplomacy: Summits and Treaties

In my last post I explored the importance of language & communication in diplomacy and, by extension, the BI practice. In this post I'd like to consider two more tools of diplomacy and how they can be applied to the BI practice.

The Summit

A Summit provides a forum where all sides have the opportunity to speak directly with each other in a highly focused and most importantly, face-to-face format. In today's business environment it is too easy to fall victim to the limitations of email, telephone or even video communications. Even with the best video conference, few mediums of communication replace the extraordinarily "high bandwidth" of physical presence. (As an example within BI Consulting Group's experience, read my colleague Ed Martin's recent post reporting on our company-wide Summit held last week in Minneapolis.)

But common focus is also important. Well-organized summits often have a stated purpose agreed upon by all participants before or immediately at commencement. Sometimes ground rules even require that participants not leave until specified goals are met (think the Catholic Church's "White Smoke" summit -- or Conclave -- of Cardinals that elects a new Pope).

Of course a typical run-of-the-mill business meeting is a similar exercise... But when signficant, concrete progress must be made between parties of disparate backgrounds, framing the discussion in the specific terms of a Summit can be an effective way of setting the stage for the quality of interactions that will ensue.

The Treaty

The ultimate formal goal of any diplomatic effort is the execution of an agreement between all parties that sets specific parameters for behavior. The most obvious parallels in the BI practice are requirements documents, functional specs and service level agreements. In each case, the agreement clearly specifies the "rules" under which the signatories are required to behave.

In BI of course, one of the actors is the technology itself. In a Treaty, individual countries are held accountable for the performance of their borders, regulations and tarriff; in a Service Level Agreement, the IT support staff is accountable for the timely and stable operations of servers and applications. Well-written Treaties, SLAs and really any legal contract are useful to all signatories because they clearly define the expected performance of each participant and actions to be taken when that performance is breached. But the key concept is "well-written" -- a good agreement is clear and specific but not so obtuse that a lawyer is needed to interpret it.

An important component of an effective BI "Treaty" is the data validation report. A good BI implementation will include data audit reports -- confirmed as authoritative by all parties -- that compare warehoused data against source transactional data. These audit reports serve as the arbiters of performance that determine objectively and decisively whether the warehouse (in the "Tech Nation") is holding up its end of the Treaty by correctly reflecting source data (coming from the "Business Nation").

I plan to explore more tools of diplomacy in posts to come (trying to work "the Spy" into this discussion!), but as usual, in the meantime I'd love to hear your feedback and especially any other examples of Treaties and Summits in the BI practice.

BICG Summit 2009

The BICG Summit 2009 was excellent in helping meet other BICG employees, and becoming familiar with some of processes within BICG. As a new employee the timing of the Summit was perfect. The learning break-out sessions were very informative, and will helpful in future projects. Also the team building exercises and the evening cruise was enjoyable, and helped me get more acquainted with some of the BICG employees.

I look forward to the next Summit. Hopefully we can them more often than annually.

Read more about the BICG Summit at:

Monday, September 21, 2009

Recommended Reading . . . "A Whole New Mind"

Time to share one of my favorite books of recent years. It's titled "A Whole New Mind: Why Right-Brainers Will Rule the Future" by Daniel Pink ( What does this have to do with business intelligence (BI)? Answer: it explains the benefits of combining left-brain (analytical) and right-brain (creativity) thinking in a fun, quick read.

Here's a book description from Dan's web site: "The future belongs to a very different kind of person with a very different kind of mind. The era of "left brain" dominance, and the Information Age that it engendered, are giving way to a new world in which "right brain" qualities - inventiveness, empathy, meaning - predominate."

There are so many important ideas in this book. Some are obvious . . . we live in an age of abundance and knowledge workers at lower cost are now plentiful overseas. The book offers valuable insight on how we in America can compete, differentiate ourselves and retool for the future. First and foremost, unlocking your right-brain creativity will be a deciding factor in this success.

Let me extend Mr. Pink's ideas and state that a BI professional needs to develop both sides of their brain. The most valued people are those who can understand complex analytical requirements (left-brain alert!) while empathizing with others and developing creative solutions to business problems (right-brain alert!). Sounds like the job of a BI expert to me.

For Star Trek fans, left-brain is pure logic (Mr. Spock). Right-brain is pure emotion (Scotty). Why not a combination of both (James Tiberius Kirk anyone?). Become the leader to which people gravitate. Adopt the correct mindset going in and help the corporate "Enterprise" reach its BI goals.

The author provides a very brief description in this short video (worth one minute and twelve seconds of your time):

Your comments are appreciated.

Amazon link to book:

Wednesday, September 16, 2009

BICG Hosting Two-Day Continuing Education Conference

The first-ever company conference, titled the BICG Summit, is taking place this week, September 17th and 18th in the Twin Cities Area of Minneapolis and Saint Paul. BICG staff members are participating in educational sessions on advanced topics specific to Oracle BI and EPM.

Complete details can be found here:

Monday, September 14, 2009

Essbase Is Music To My Ears

Take an informal poll of your fellow Business Intelligence (BI) associates. You may be surprised how many are also musicians. Guitarists, pianists and drummers lurk beneath their surface. I fall into this category. We can't be a Beatle, so instead we let BI applications rock our world.

Designing a successful Essbase cube is like playing a beautiful song:

  • One has an established structure to follow (verse, chorus, bridge). The other has the structure of outlines, dimensional hierarchies and load rules.
  • One has 4 beats to a measure (mostly) to create balance. The other requires its financial numbers to balance to their source.
  • One allows us to venture out a bit and improvise. The other allows for creativity such as shared member rollups, custom formulas and more efficient calc scripts.
Essbase technology advancements (aggregate storage, System 9, version 11x) mimic the tremendous advances in music recording technology (Apple's GarageBand, digital audio workstations, Auto-Tune?). We now have a lot of computing power at our fingertips. How it's used separates a great song or database from a bad one. Harmony from dissonance. Making your cube sing requires a lot of listening (to user requirements), practice (designing solutions) and a light touch.
It takes many orchestral instruments to play a score. Likewise, Essbase is one of many players in the Oracle product suite. Make these products work together in concert and we have our own little BI symphony.

Essbase brings music to my ears. How about you?

Friday, September 11, 2009

BI and the Tools of Diplomacy: Language & Communciation

In my last post I made a case for comparing the role of the Business Analyst in general technical projects to that of a diplomat carefully negotiating the interactions between the "nations" of business and technology. For this post I had planned to take that comparison to its logical next step and consider a variety of tools & techniques of traditional diplomacy and apply them to a typical Business Intelligence practice. In the interest of everyone's time I will split up this discussion among several posts, starting with what I consider the single most important tool in the practice of diplomacy: language and communication.

By far the biggest barrier between nations has nothing to do with physical separations -- political borders, distance or even geographic features like deserts, mountains, rivers and seas. For example, Australia, the UK and the United States are phsyically divided from each other by thousands of miles of open ocean, yet they are some of the best friends among the international community. I argue that the single most difficult impediment between nations is language and open communication. How can two people possibly be friends if they don't talk to each other? And what's the point of talking if they can't understand what the other is even saying?

Let's look at language first. A good example in Business Intelligence projects is financial reporting. The world of finance has a rich and well-established vocabulary of terms that have very specific and often complex meanings and implications for a business user, yet may have a completely different meaning, if any, to the technologist. Consider the two most basic of these financial terms: Debit and Credit. What these terms represent in a business context is the complex system of balance sheet accounting that is fundamental to all modern businesses but is also, well, foreign to most technologists.

The most rudimentary, bare minimum approach to crossing this barrier is the use of a simple dictionary or phrasebook - so that at the very least, the technologist will know how to find her way to the metaphorical bathroom in the business world. Of course, in the long run, a phrasebook definition of "Debit" will be of little help. The technologist will forget to multiply a "debit" by -1 when the business user expects her to, and the business user will end up the butt of a Dilbert cartoon about using or not using SOAP. A better way is to teach the whole language, not just piecemeal phrases, with the end goal of achieving a level of proficiency that will allow the technologist and the business user to have a meaningful conversation about complex issues that are important to each side.

The takeaway for your BI practice? Establish some way for each side to learn the other side's fundamental professional terminology and the concepts behind the language. Imagine the quality of conversations we would have if technologists were to learn the basics of Balance Sheet Accounting, or if the business users could learn the concepts of star schema design. When designing the instruction, remember that the detail needn't be exhaustive - the point is to encourage a meaningful conversation, so that the business user can understand the importance of conformed dimensions and the technologist knows the difference between a debit and a credit.

A good, low-impact, "Web 2.0" approach to encouraging this conversation would be to set up a company Wiki so that representatives from each side can contribute and respond to content (even by refering to existing content available elsewhere) that explains their fundamental professional terminology and the underlying concepts. Even better would be examples to illustrate how these concepts apply to their organization's operations.

Having a common language is important, but we need to use it too: Establishing active and effective paths of communication between nations is a cornerstone of a healthy relationship. Other tools of diplomacy - standards, summits, treaties, even espionage - can all be considered ways of enriching the communication between nations. I will focus on these tools in my next post.

Until then, I'd like to hear your thoughts. Do you have any other suggestions or better, good examples of successful strategies in your BI practice for breaking the barrier of language?

DAC -Prune Days Can Now Be Set By Source System

In the previous releases of DAC, prune date parameter was set at the execution plan level. In DAC, prune dates can be set at the execution plan level for the entire plan or in the execution plan parameters for specific source connections. Dates set at the source level in the parameters override the date set at the overall execution plan level. If no dates are set at the source level in the execution plan parameters, the dates default to the execution plan level.

BI for Investing?

At times we need to take a step back and ask ourselves “what got us here” or “why did we take this path”. Just the other day I asked myself this and remembered that what ultimately drove me into the Business Intelligence realm was my passion for investing. I realized that in today’s investing there is so much data available that it can often overwhelm an active investor to the point that they cannot make a whole lot out of any of this data. Behind all this data there are so many data points of interest to the investor. We have measures such as moving averages, 52 week high, 52 week low, Golden Cross, Death Cross, these and many more can be used for determining whether or not to invest in a stock at a given time. Not only are there plenty of measures to track, but there are also many dimensions that an investor would like to have built around these facts. Outside of the obvious being time, we have stocks, options, portfolios, sectors, industries, competitors and even ETFs and Funds. So to help keep my BI passion rolling and to expand my BI horizons, I am setting out to use Business Intelligence for Investing. Stay tune as I will occasionally blog about my BI building experiences and share any tips and tricks that I encounter along the way and maybe I will give you an idea of what may be a good investment. For example, do you really think the price of natural gas is going to go much lower this Fall with what lies ahead? However, just remember that in investing there is nothing and no one (including Mr. Buffett) that is accurate 100% of the time, but if you make the right investments, you only need to be right more than you are wrong to have a positive return.

Thursday, September 10, 2009

It Has Been Decided!

BI Consulting Group will be hosting their inaugural Insight Award Happy Hour event at the Ponzu Lounge located in the Serrano Hotel downtown San Francisco, just blocks from the Moscone Center. Happy Hour event is scheduled to take place on the evening of Monday, October 12th from 7-9pm. BICG will be honoring their Insight Award winners and welcomes friends of BICG to stop by. Beverages and hors d'oeuvres will be provided, in addition to a small presentation to honor the Insight Award winners.

To check out information on the host location, go to:

If you plan to be in San Francisco for Oracle OpenWorld, stop by the BICG booth in Moscone South, Booth 2201 - located in the front row to the right!

Oracle EPM Maintenance Release

Oracle recently put out a maintenance release for Oracle EPM products. Version is a maintenance release for Release,, or It looks to mainly include tighter integration of Crystal Ball into the EPM product suite (which includes Essbase).

You can download the EPM products from Oracle eDelivery ( From the "Media Pack Search" window, select the product pack “Oracle Enterprise Performance Management System” and Platform (ie Windows). There are a lot of product packs available so be sure to select the correct one.

Note that each time a new version or maintenance release is made available, the file part numbers you download will change. The latest Essbase EPM files are shown below:

Refer to a previous post for more EPM installation guidance:

Here is a link for further information on specifics for

Tuesday, September 8, 2009

The United Nations of Business Intelligence

I find many aspects of my work very fulfilling and many ways I am proud of my job. However, one of the least pleasant is the industry-standard title ascribed to the role I typically play in a BI implementation: "Business Analyst." It's probably one of the most understated job titles of all time and worse, the ultimate cocktail party conversation non-starter. Who invented the term anyway? It's stupid and I'm tired of it.

Of course the natural response would be: "You may have a point but what else would you call it?" Indeed, how else would you name this role, which by its nature has no traditional "profession" of its own but instead straddles a kind of no-man's-land between professions -- that of clients (who need the assistance of technologists to achieve business objectives) and of technologists (who perform the work required by the client)? And how to come up with something sexy to boot?

Meeting with an old college friend years ago, I tried laboriously to explain the nature of my work in the glow of a second glass of Zinfandel (or was it a third?). My friend asked me an intriguing question: Did my professional endeavor in IT have any relationship to my undergraduate experience? At the time I was over ten years out of college and a bachelor's degree in Foreign Service (aka International Relations) -- and 9/11 was still raw in my mind, so I was bemoaning the fact that I chose to pursue opportunities in software development rather than diplomacy. But, perhaps thanks to that same glow from the wine, I took a look at my job from a different angle and saw something very interesting: The IT roles that I had performed often involved a certain degree of, shall we say, mediation. Thinking it through, I realized something more fundamental: while performing various IT roles, I often perceived an acute need for mediation between the "suits" and "geeks" and I found myself drawn into fulfilling that need, partly because I liked doing it but largely because my skills were well-suited to that role.

From that point on I began to see more clearly the importance of the mediator in successful IT endeavors. Over time I have also come to believe that this role has much in common with the practice of diplomacy -- particularly within the specific discipline of Business Intelligence, where interactions between clients and technologists become uniquely more intense than in a typical IT project.

What I'd like to do first is explain the parallels I see between diplomacy and the role of the classic IT Business Analyst. Then I will take the next logical step: to explore what lessons from traditional diplomacy we can apply to the practice of Business Intelligence in particular. Hopefully I'll shine a fresh light on this important role and perhaps even inspire somoene to devise a job title that's far more sexy than "Business Analyst."

Traditional Diplomacy and the Traditional Business Analyst

In traditional diplomacy, the diplomat mediates between what I'll call "physical" nations: the US and China, for instance. A BA does essentially the same thing - but between "metaphorical" nations: the client (aka "The Business") and the technologists (aka "IT" or "Tech"). Let's consider some hypothetical characteristics of physical nations and their parallel among metaphorical nations: [Please understand that my examples are sometimes oversimplified generalities intended purely to illustrate the point and not pass value judgements on any country or group of people]

Goals / interests / agendaUS: Increase industrial production; decrease cost of healthcare; decrease energy demand; promoting the global spread of democracy

China: Increase industrial production; increase citizen wealth; increase energy supply; promoting the harmony of Chinese society

Tech: Work with cutting-edge technology and phase out old technology; build resumes

Business: Increase [revenue / profit], decrease costs, build resumes

LanguageUS: English

China: Mandarin

Tech: SQL, Java, HTTP, SOA, "geek speak"

Business: Quarterly financial statements, Balance sheet accounting, "corporate speak"

Natural resourcesUS: Wheat, coal, consumers, Hollywood

China: Cheap and abundant labor, cash
Tech: CPUs, RAM, computational thinking, technical skills, hard work, creativity

Business: Money, market-oriented thinking, business skills, hard work, creativity
Cultural valuesUS: Individualism

China: Collectivism
Tech: Collaboration

Business: Competition
CurrencyUS: Dollar

China: Yuan
Tech: Game rooms, private office space, logo wear, money

Business: Titles, adminstrative assistants, corner offices, money
FashionUS: T-shirt & jeans, Little Black Dress

China: Mao suit, qipao
Tech: Logowear, boardshorts, Tevas

Business: Business casual, suits

Despite the oversimplifications, the parallels are compelling.

Given this common concept of a "nation," let's consider the professional challenge of the traditional diplomat:

How to foster a trusting and productive relationship between his employer's nation and other nations (at least, those that his employer considers important)...
So that his employer's nation can effectively apply its unique natural resources to pursue & fulfill its own agenda...
And the citizens of his employer's nation can be happy and prosperous.

In comparison, the challenge of the Business Analyst is basically the same but with notable differences:

How to foster a trusting and productive relationship between ALL nations...
So that ALL nations can effectively apply their unique natural resources to pursue & fulfill their agendas...
And the citizens of ALL nations can be happy and prosperous

The Business Analyst is in the unique position of being required to ensure that the interests of all nations are being satisfied. This mission is more akin to that of the United Nations Secretary General -- which is also not an easy job but I'm sure Ban Ki-Moon has an easier time at cocktail parties. And the chauffeur would be nice too.

In my experience this perspective has proven to be a useful way to understand and manage the dynamics of interactions between IT and "The Business." For my next post I will consider some specific tools and techniques of traditional diplomacy and how to apply them to a Business Intelligence practice.

Tuesday, September 1, 2009

Essbase and Use of Duplicate Members

I just returned from a client that was using a relatively new Essbase feature called "duplicate members". The business use of duplicate members is that it provides unique cube data when people use the same name to mean different things. You say "tomato" and I say "tomato", that sort of thing. Now a tomato can be either a fruit or a vegetable. Pretty cool!

This feature became available beginning with Essbase System 9 and continues on in 11x. Do not confuse this with "shared member rollups", which share the same data value in a different part of the outline. Duplicate members allow the use of the same member name in an outline, but the values are unique, not shared.

Here is an example of duplicate members. A user defines "New York" as both a state and a city in the outline but each has a unique value because they reference two different things.

--- State
------- New York
------- Pennsylvania
------- ...
--- City
------- New York
------- Philadelphia
------- ...

You must enable the duplicate members option in the outline to use this feature. Then create a qualified member name in the outline. A qualified member name consists of the duplicate member or alias name and all ancestors up to and including the dimension name. To create uniqueness, each name must be enclosed in square brackets([]) and separated by a period (.).

For instance, the qualified outline member names would be:
[State].[New York].
[City].[New York].

This is a brief introduction to this valuable feature. Refer to the Essbase Database Administrators Guide for specific details on how to create duplicate members. Here is the link:

BICG at Oracle OpenWorld

Check out the BI Consulting Group exhibit at this year's Oracle OpenWorld. Located in Moscone South, Booth 2201. You will have the opportunity to meet with the BICG management team and get firsthand insight on how their in-depth experience can better serve your company.

Oracle OpenWorld runs from October 11-15, dates and exhibit hours below.

Monday, October 12th: 10:30am - 6:30pm
Tuesday, October 13th: 10:30am - 6:30pm
Wednesday, October 14th: 9:15am - 5:15pm

BICG will host their inaugural Insight Award winner event on the evening of Monday, October 12th. Event details yet to come!