OBIEE - (IT Lead to Business Lead) Process related issues

Question

Hello All

As BI is drastically moving from IT led to Business led there are few demands from the business for this.

User are now asking developer rights to make change to the dashboards directly as the cycle time of any change is too big.

We have an OBI system where in we have several dashboards and report which the IT team/developer have developed using the typical waterfall lifecycle.

Couple of option Users asking for

Option 1)

Direct change they will do on the production dashboard reports. Later IT team will sync the QA and Dev environments

Option 2)

User will make the change first in QA and then Archive/Unarchive the objects in Prod on the same path multiple times (replacing the prod with Prod), Later IT team will sync the Dev environments (may be multiple times).

I see a risk involved in both the above approaches.

a. The users may corrupt the complete Prod Code if unarchive not done correctly, permissions may overwrite.

b. The users changes may overwrite the changes the normal developers are doing in DEV.

c. Overheads involved in keeping the environments in sync.

Possible option:

I think we from IT should provide an extra dashboard (staging) in Prod itself for all their work.

Let them add their own dashboard/pages/reports etc and share validate with other users.

If all sounds good IT team will move the objects to the main read only dashboard.

Still in this approach as well there will be an overhead of keeping QA and Dev in Sync.

Can someone suggest what ideally should be a solution to such a situation, where the changes are Business Lead and sanctity of the environments are also kept in check.

Thnx

Dev

[Deleted User] · Answer

You owe me a new laptop and a coke.

Thomas Dodds · Answer

On this episode of mythbusters....

* As BI is drastically moving from IT led to Business led there are few demands from the business for this.* BI has never been an IT led initiative when it is successful

* User are now asking developer rights to make change to the dashboards directly as the cycle time of any change is too big.* This is a direct result of IT-led BI -- IT cannot deliver at the speed of business

* We have an OBI system where in we have several dashboards and report which the IT team/developer have developed using the typical waterfall lifecycle.* IT forced its hand on the business ... pitting waterfall versus agile isn't going to fix the issue -- in fact experience has shown me that a hybrid is needed

As @Robert Angel said: There is a reason for it taking time, it is called Quality. You can have it good or you can have it now, but you can rarely have it both.

also, The alternative is exposing your business to the risk of incorrect information and loss of user confidence in the solution.

So your organization has to find the sweet spot -- that comes with a serious effort in Enterprise Data Management (Data Governance, Data Quality, etc).  Data is an asset - use it wisely.

You are finding that the roof is collapsing - this information architect is pointing at your foundation...

Robert Angel · Answer

Hi,

Standard change control, users develop in environment 'X' (call it pre-dev if you like, whatever!) you QA the environ when they tell you that it is ready to be promoted, they fix any issues you have with it before a final QA and then its content is migrated to your DEV environment from where it is properly tested and escalated through the environs.

If you don't have the luxury of a spare sandpit environment they could also develop in their own folder area and you could operate similar controls before corporate release.

There is a reason for it taking time, it is called Quality. You can have it good or you can have it now, but you can rarely have it both.

The alternative is exposing your business to the risk of incorrect information and loss of user confidence in the solution.