Quiet Christmas

I had a few emails, texts and calls today from people who are available for work. Good Siebel Analytics / OBIEE consultants who may be having an extended xmas holiday!

If you have a need for someone for short or long term please get in touch and I'll forward their details on.

You may have noticed me being busy on LinkedIn recently. I have managed to build a good network of OBIEE consultants, and even started a group specifically for Oracle Business Intelligence consultants. This should benefit us all when it comes to project requirements.
Go to http://www.linkedin.com/e/gis/43109/526A0219C124 and I'll add you in (I only add in OBI consultants and related workers).

I have also been busy on the Oracle OBIEE forum, reading the issues that people have. It annoys me when someone clearly hasn't read the manual or even tried to find the answer to something before posting a request.

Each day I always check out Venkats postings on his blog. He has a great job - he just gets to play with OBIEE all day and write about the new stuff.

Talking of new stuff, the new functionality in 10.1.3.3.xyz, which allows you to call Oracle functions will be a greta boost for the product. Up until now I have seriously wondered by you need a BLOB in an Analytics but now we get to put pictures from a database in you reports.

I was sceptical about the time series functions, particularly as they were causing some people problems, but I have now converted over completely and so far so good. Let me know what you think.

Have you noticed that when you use the functions editor you now get something more useful when you add the function - it actually now tells you what arguments it requires instead of <>. I tended to copy the contents of the edit box into TextPad but may start using the editor more now.

I notice there are more and more companies that are offering OBIEE and Siebel Analytics consultancy. Those of us that were using the product over 4 years ago are seeing others trying to muscle in. All I can say is How much do you really know?? There are so many stories at conference from clients that say their implementation failed due to the integrator not having the right skills. We ALL need to make sure the product is not undermined by consultants who frankly do not have a clue. If you are in a pitch to a client sell your real experience and don't let beginners run your project.

I am still building the OBIEE information website, if you would like to have a listing just let me know.

That's all for now Folks!

New Version of OBIEE

Version 10.1.3.3.3.1..3.1.1.2..3.1..3. of OBI Enterprise Edition is now released.

It's got some new stuff in.

How exciting!

Documentation, It's MAD!

Let's face it, there's not many people who like documentation, except a good BA of course, but every single project needs it.

Now if the title and first sentence haven't put you off I'm going to let you into a few secrets.

1. A good set of design docs will save your project money
2. Post project documentation (actual designs, architecture maps, etc) will rarely, if ever, get read
3. Your documentation will be instantly out-of-date with release x.1

Still with me? OK, they're not really secrets, but they are issues we have to contend with. The motivation to write something detailed that will never get read and will be obsolete in 5 minutes, without the proper tools is pretty low. Especially if you have just had the go-live party the night before :)

So a typical Analytics (Oracle BI EE for the late comers) will need the following

a. Design of Datawarehouse - This includes Tables, fields, indices, schemas, tablespaces, parameters, views, Materialized views, etc
b. Design of DAC - EP's, Subjects, Table Groups, Tables, Indices (again!), Tasks
c. Design of ETL
d. Design of Analytics Repository (Oracle BI Repository)
e. Design of Webcat
f. Integration designs
g. Technical Architecture Map
h. Support Guide - What to do if.... scenarios

what did I miss?

(We are going to assume Analytics with Informatica ETL for this example)

Here's the catch. You have a reference to a physical table in at least four places - Db, DAC, Informatica, Physical layer. In your design you want to ensure referential integrity, i.e. don't refer to a table in the DAC that does not actually exist in the Db!. Another example where you have this is with tasks in the DAC that refer to Informatica Workflows.

My prefered approach is to create all these documents up front, i.e. in the design phase (say that last bit slowly with a deep voice), then update the documents at the end for what actually got built.

What tools do you have?

Most project sites that I go to will have MS Office, but you really need the professional version for Access and Visio Professional. You could try to publish the designs in Word or HTML, and you could even use Analytics to present the design!!
The Word vesion is probably the easiest (least technical) but requires most work, the Analytics version will need a place to be set up, with Webserver, db and Analytics server licence.


What do I use?

Glad you asked that because we have developed the MAD - Majendi Analytics Designer, system. This is a semi automated system that can document an existing Analytics aplication, from DB to Webcat. It produces MS Word documents which details all of the items in a) to e) above. I supplement this with Visio diagrams for star schemas (This also uses the design repository for the source tables).
As well as the Word documents templates being populated we also have a miniture Analytics system which details the meta data. The heart of the system is a set of Access databases which import metadata from txt files or directly using ADO (so it can work on any database) to conect to the databases. A side benefit is that building the system teaches you all the underlying data structures in the ETL and DAC.

How do you get the information you need?

You can query the repositories directly in the Oracle/SQL database.
You can use the documentation utilities of Analytics and the Web catalog manager
I also use the UDML file that you can get from Analytics, and parse this into an Access Db.

(If you want to know about UDML files I'll be posting a short note on that later).

The beauty about the MAD system is that I can document a whole complex system in a couple of days, even better is the ability to analyse an existing application to help with an upgrade, or with new releases - your documents can very quickly reflect the underlying new system.

So there you have it, Documentation may be boring but you can make it interesteing by using your technolgy skills to reduce the problem down to automated tasks, just like we did. :)