BI Artifacts

[iinquisitivee]

Hello,

I have been asked to put togather BI artifacts for an existing BI landscape.

What are the ones that you can think of please ?

I was thinking of

1. Bus Matrix.
2. UI standards
3. semantic naming standards
4. tool selection guidelines for users.

Any ideas are appreciated !!
And would be great to have some reference documents.

Thanks for your time.

[Lynn]

It is probably helpful to identify the audience for your documents. The things you produce for developers/professional authors/IT technical people would vary quite a bit from what you might prepare for users.

Also consider the purpose and use of the information. A bus matrix, in my experience, is something generally done at the start of a warehouse project to identify fact/dimension relationships and to assist with prioritization and planning. I suppose it wouldn't hurt to have it but if you already have ER diagrams and Framework Manager model diagrams then perhaps those already provide the same information in a different format.

In addition to UI and semantic naming standards, perhaps report authoring guidelines are worth producing. The best way to ensure that these are read and followed is to create a process that requires them to be used. For example, before promoting something to production define a peer review process that requires someone else to test and review for adherence to the guidelines. This might include things like naming queries rather than leaving Query1 Query2 etc, consistent parameter naming conventions, not leaving unused items hanging around in queries, and so forth.

From a user perspective I would suggest that a good meta data dictionary is worth producing. Ideally all the query subjects and query items will have screen tips defined from which a reference guide can be produced. If not, then create these things and then load them up into the model.

[iinquisitivee]

Thanks Lynn  for the reply.

I beleive none of those (ER diagrams or framework manager models) are in place. More over in the past there have been data marts and now there is an effort to consolidate the marts and develop news one as needed. This is the reason I was thinking of the BUS matrix so new marts can know what is already there and there is no duplication of dimensions.

I also need to put to gather a BI architecture diagram, basically the high level representation of the flow from source to target, this is for the leadership team.

Maybe something  on the attached (BI.jpg attachment seen below)  lines (specific to our environment) ? ...

[bdbits]

I think your BI architecture diagram if fine for management types or high-level presentation. I think Lynn was recommending things more specific to the implementation.

Just a thought, but we generally do not tell users much if anything about the existence of the staging layer. In our environment, it often includes data from several platforms, so the users start to think it is something they can (or even should) use for queries and reporting, which is really not what we want them to think about doing. We do sometimes build a non-dimensional, 3NF-type database to capture data over time even where the source systems might not support it. (We refer to it as an ODS.) But that is kept separate from the staging areas. The great thing about having and ODS is that it becomes much easier and less impactful to re-engineer existing dimensional models, or create new ones, because you have all the source data at hand.

Consolidation can be a big, complicated project. I would definitely build a bus matrix, and try to use conformed dimensions as much as possible. Difficult, but lots of payback.

One problem you might find with including things like a bus matrix in user documentation is that some look at it as a living document. If you are OK with maintaining it then I suppose it could be, but it becomes one more thing to manually keep updated. So I would be up front about whether it is a project-phase-only document or something on-going. I personally like to generate documentation from real working models, so I lean toward database and FM diagrams when possible. If you have a full-featured design tool, you should be able to reverse engineer the database and produce reports right out of the tool. Then when you make changes, you just re-export the diagrams and/or reports and all is up-to-date.

Naming conventions and the like can save a lot of headaches down the road, so I second those recommendations.

Data dictionaries are great to have, especially for users who know their subject matter but have a hard time figuring out how it has been represented. The biggest hurdle is that I feel you absolutely must have subject-matter experts - users - building the data dictionary, and an easy way to capture and present the information. It is more difficult than it sounds, and users are sometimes unwilling to commit the time to do it right and as importantly, maintain it going forward. It has to be a long-term, living thing or people will get frustrated and it will just figuratively collect dust. You might be able to again do it with your design tools, and there are software tools out there geared toward data dictionaries and other data governance.

All that said, if you do a really good job designing your package presentation layer and use good business-oriented naming and organization, with Cognos at least the GUI can be very intuitive and easy for users to use without a need for much documentation. This is much easier said than done, of course.

[iinquisitivee]

Thanks for the reply.

Do you have examples for this one (design tool) please ? - "If you have a full-featured design tool, you should be able to reverse engineer the database and produce reports right out of the tool. Then when you make changes, you just re-export the diagrams and/or reports and all is up-to-date."

are u saying you can use diagrams from this instead of a BUS matrix ?

Thanks !!

[bdbits]

Pretty much any database design tool can reverse engineer a database as well as create new ones, and print diagrams.

We use Sybase PowerDesigner. It is most often used for database development, but can do a lot more and includes a built-in reporting tool and can of course generate all kinds of graphical output. It is not cheap, but it is very powerful (to borrow an overused sales word) and can be used to document an entire life cycle, if you want to do so.

I think bus matrices are fine and we do use them when developing new data warehouses. But along the lines of what Lynn said, you need to consider your audience for the bus matrix. They are useful for working with users, and building out your models. Once you get past the initial build, personally I do not find maintaining them to really be worth the effort. It's just simpler to keep database models up-to-date because we do all of our changes through PowerDesigner anyway, so we can just re-run any reports and diagrams when needed. You or your organization may feel differently. My point was that you need to be up-front on whether you intend to maintain them after your project goes to production. You need a process in place if you are going to maintain them, otherwise they will be out of date with your next database change, and nobody will trust them and so they will fall out of use anyway. That's all I was trying to say.

[iinquisitivee]

Thanks for the valuable input.

My reason  for maintaining the bus matrix was that there are multiple projects happening in Silos, all buidling thier own datamarts (in thier own seperate schemas)

This is creating confusion and all are developing thier own dimensions and so on.
Hence was hoping that I can start on a bus matrix and folks can keep refering to those before planing to build new dimensions