Here at my current position, we’ve been discussing our future demo requirements that will be used to showcase our BI Featureset (WEBI & Dashboards mostly) to potential clients and it appears that there are a few different schools of thought.
The ‘best case’ goal would be to let our sales people have access to a Demo login Id that would only see demo based data, but would utilize all of our existing reports and dashboards with all of thier functionality. Our demo would be a truely ‘live’ system simply with bogus data underneath. (Some items would be masked or modified as needed of course)
Our big question at the moment is: Where do we store Demo Data?
So far we’ve come up with two main routes we can take:
All Demo data should be stored separately in a unique Database. This mimics other systems/processes today within the company. However this data does not interact with those systems so it isn’t absolutely necessary.
vs.
Data should be contained within the production/test databases designated by a particular Key Field. (In our case we have individual client ID’s, so we’d assign one as a “Demo Client”)
The VP’s are pushing for seperate databases. I and some of the developers are pushing for a single database.
The problems I see with seperate databases, are that we’d need two universes so handle the multiple connection strings. (We do not have Data Federator currently.) And then with two universes we also therefore need two copies of all reports/dashboards/QAAWS etc…
I’m having a hard time convincing them why putting the demo data in our Prod/Test databases is actually a good thing. They seem to have the feeling that demo data will ‘taint’ the production data somehow. They feel that extra work is ok to maintain that seperation. I feel that seperation is unnecessary.
So my question to those of you reading this, is how does your current environment handle demo’s both in terms of where your data is stored as well as document/dashboard maintenance. Is your current method what you’d choose if you had the ability to ‘do it all over’?
The only good thing I have going for me is we are creating this from scratch so we CAN do whatever we want… we’re not locked into any particular method.
Use separate databases with a connection override to repoint the universe. That way you don’t have separate copies of the reports or universe but don’t taint your production data with demo data.
I agree with that concern, by the way. It only takes one mistake, as in forgetting to eliminate the demo data from a production report to call out the dangers of that approach. I would definitely want to have my demo data separate from the production data.
One drawback to separate databases… when changes are made, they will have to be made twice. Suppose you add a new field to a table. This change is put into DEV and tested in TEST and migrated to PROD. During the migration, there will probaly be a script to first add the new field and then a second script to populate it. The same process would have to be run on the demo database.
Is this a new feature of XIR3? I’ve never heard of a connection override before? It sounds like what Data Federator was use for no?
All of our reporting is based off a particular ClientID anyway… so they’d have to specify the Demo ID to mix up the data. Users can only see thier client IDs as well so it would never show up in a LOV. There is no data that ever gets aggregated across ClientID’s, otherwise I’d agree with you in that data potentially can get incorrectly aggregated.
EDIT: Actually I searched and found the overriding… never even knew that existed! Silly me! For others looking for similar features here’s the post:
I think this is the approach we’ll take then since it will give the VPs piece of mind and us developers the single source for modifications… best of both worlds!
Connection overrides have been around since 4.x. Federator allows you to combine multiple sources into one universe. Overrides allow you to “repoint” an existing universe to a different database, as long as it shares the same structure.
That way you don’t have separate copies of the reports or universe but don’t taint your production data with demo data.
(BOB member since 2002-06-06)