Framework Manager roles in IT or within the business

[sonicwu]

I have a quick question.  For those of you that are working in framework manager, does your role reside in IT or does your role reside within the business (i.e. marketing, sales, operations, etc)? 

I'm in a company that is trying to launch BI and we have purchased Cognos.  As we are developing the roles within our organization, there are thoughts of putting the framework manager role outside of IT (i.e. one in finance, one in marketing, etc.).  I thought the general best practice was to have the report developers, framework managers, dbas, etc all reside in IT to support the business.  Currently they are also putting the report builders outside of IT.

Let me know what you guys think and also from your experience where do these roles reside?  Thanks.

Scott

[JeroenWork]

The answer depends on a lot of factors; organization type, company size, skills etc...

So for my situation (big intl company, project organization):

All devellopment for framework manager and report studio are done by IT, both products are not easy and need IT skills. There is a lot that developers can do wrong, don't forget they (can) access the corporate databases. Normal business users will only get access to query studio / analysis studio / powerplay. When we migrate to C10 we will give the users mainly "Insight".

Things also to consider are:
- needed support, do you have the IT resources to support the business users getting stuck with framework manager?
- version control; do you trust the users to take care of their shop?
- security; who governs access (SOX compliance etc..)
- can you guarantee the business a "one version of the truth" if you do not develop yourself?
- etc....

Did you talk to IBM about this?

Good luck,

Jeroen

[sonicwu]

Thanks for the quick and detailed response.

I am currently working in a service provider, we have about 3000 employees and our annual revenue is around $1 billion.

Unfortunately our BI program was not initially launched as an enterprise BI program.  Our finance department purchased the Cognos tool for their own use and has now proposed making it the enterprise tool (which is the direction we would like to move into).  They currently have report developers working with report studio and are now proposing to create a developer role to work with framework manager within their department as well.  They have an outside consulting company supporting them.  I wanted to get a pulse from the forum to see how others have implemented this within their organization.

We would like to move the technical roles for BI into IT and create a BI governance team and have that sponsored by and reside in Finance.  Trying to see if that is how others have implemented.  I am currently talking to IBM as well, they want to bring in a consulting team to do an assessment.

Scott

[jive]

In the project I work we do thing based on role define in Cognos and our security provider. All the administrative role are set to ldap group. In the ldap group we have only insert IT people. For authorind tools that's depend on what is your need. In some department they have the possibility to produced report but the possibility to publish those reports are in IT. That way we can kept control on the number and appearance of report publish for large distribution.
Our rule of thumb is :
-all administrative task, portal , cognos server, publishing, adding or removing folder are in IT
-Author can be people inside department, IT for development of specifics task.
- all the development done by IT are done in a development package reserve to IT only.

I hope this will help

Regards Jacques

[Lynn]

I have yet to meet a business user I would entrust Framework Manager modeling to. Truth be told there are some developers I've met that I wouldn't entrust the modeling role to! There are some exceptionally smart and technical business users I've encountered over the years but even so I don't think this role belongs there.

In addition to the good points already made I'd suggest that having subject area modelers on the business side rather than within IT could potentially create silos that may impede enterprise wide reporting. This depends to a large degree on the data sources -- if not data marts from a well architected enterprise data warehouse.

I think establishing a talented and technical liaison on the business side to work closely with IT on requirements, review, testing, etc. of the model can add a lot of value and keeps people working on things that make the most sense for their focus and skillset.

As for authoring, I'd start with the user studios for business authors. A well built model should allow these to satisfy a majority of reporting requirements. For cases where they hit a functionality wall, a professional author can pick up in RS where they left off. A business user with the inclination to use RS doesn't seem out of the realm, but I would always ask myself first why they can't do what they need with the user studios. If there are deficiencies in the model that prevent satisfying requirements (and not just a one-off oddity), then I'd consider model revisions over putting RS out to users.

[jleyba]

Excellent points made here. As expected in a forum frequented by (I imagine) mostly IT people, the responses so far seem to favor the IT-centric model.

There are pros and cons to both approaches.

Many organizations do follow the model of having not only report builders but even modelers report into the business units instead of IT.

Typically the main reason they do this is to make sure BI reflects the needs of the business unit rather than IT or the enterprise as a whole; or BI was adopted first by a business unit, then spread to the rest of the organization.

There may also have some concern about BI resources in a "shared services" environment not being as responsive to rapidly changing business unit requirements.

I've seen this type of environment work best when the following conditions are true:

1) The modeler(s) and report builder(s) are experienced and communicative technical resources who have transitioned over to the business side and work 100% dedicated to that business unit and have had the time to absorb how the business unit does "business";

2) There is a firm commitment to maintaining enterprise data governance standards, change management processes, etc. usually managed by a central group (e.g. BI competency center);

3) Licensing and resource costs are not a major concern (FM and PA licenses cost a lot of $$$).

As the enterprise increases its BI maturity level or economic conditions change this approach frequently gets abandoned for the IT-centric BI approach. Which also has pros and cons.

As someone pointed out earlier, your best best is to analyze your organization's needs, resources and culture to identify which approach works best for you.

[sonicwu]

Thank you everyone for your comments.  It has helped me out a lot.

[cognostechie]

There are some compaies who do have a dedicated BI department that resides outside of IT. What that means is - They form a team of Developers who do Report Development, Model Development (FM) and Cube Development. This department reports to the business and are not to IT. This department has it's own BI Managers too. The developers are selected by their qualifications and some of them were originally from IT background. Some of them are purely business analysts and learn the basics of Cognos but can use Cognos only upto it's basics. They work with IT because IT is the one that creates Data Sources, administers Content Store, security, Data Marts/EDWs and Source systems.

So this BI department can do all of the development but does not have administrative rights so they cannot modify the ETL processes, Table structures or even administer Cognos. The upgrades to BI software is done by the IT, not by BI.

This being the case, the responsibility of screwing up the FM Models, Cubes is of BI, not IT. IT handles the change management and migrates content from Test to Prod with a request from BI. If anything does not work well, BI has to take care of it. IT handles the Audit package though.

Wanted to add this - Needless to say that it does involve friction betwen IT and the BI

[Arsenal]

cognostechie, the model you're describing is more like an EBIS/Production Support team-IT model where both would be considered part of IT but EBIS/Prod Support owns the environment and does the migrations/patches/fixes/downtime etc. but the BI team within IT does the actual development.

This model is especially applicable where organizations run their own offshore units (EBIS/Prod Support) who do migrations etc. during night time here in the US as well as health monitoring.

[cognostechie]

Your exposure is different than mine resulting in a different conclusion.

What I described is that the EBI is outside of IT and reports to the Business. EBI does the full-scale development either themselves or gets it done by offshore team. IT only handles the administration part (upgrades, patches, fixes, downtime, security etc). Production support is also done by EBI.