Question

I have a BI project to be carried out using SQL Server 2008 and Cognos 8. Client seems to be using legendary adhoc/home grown applications. Where as some reports have been using an older version of Cognos. Client has no plan or what so ever as of now but in a real hurry to migrate all older version of Cognos reports to Cognos 8 (which they consider as the brand new version). Going forward Client also want to make reports available on Sharepoint with presently migrating .Net platform.

Given past exposure, I think, looking at all the underlying data/data sources required by the business users/their reports would be a better place to start, then followed by ETL, Data Warehousing to settle Database layer. That will give full performance management control over to BI platform. Where we can proceed with a prototype engaging meta data and presentation layers for a given business user object/department.

This is more of a brain-storming question that highly appreciates relevant ideas in terms of:

  • Better approach/better practice for planning a BI project on SQL Server/Cognos

  • Does it make sense to migrate old reports to new version of Cognos using IT resources or start on data sourcing/massaging with requirements gathering from business users? (as client is thinking out loud to integrate all other departments data/reporting into this BI platform in the future.) If latter is more inlined a successful project planning, how to convince the client?

  • Or should I share with the client that SQL Server 2008, specially 2012 MS BI is competent in BI, so wouldn't it be a huge cost cutting to use SQL Server/MS BI package totally instaed of mixing it with Cognos? (Client had not disclose any reason why they want to use Cognos at all)

  • Anyone who had used Cognos/SQL Server combo for BI, please provide with suggestions/tips/watch-outs/software-barriers(limits)/tips../2cents :)

Was it helpful?

Solution

Seems like a rather subjective question but here are some suggestions. Take them all with a grain of salt, as your situation and client situation is not, and cannot be fully described here.

Requirements drive technology choice, not the other way around. Consider the scalability requirements, maintainability (industry profesional availability and rates), etc. These are your "ilities" consider them carefully, and ask for clarification from the business where needed. Consider additional or hidden costs/savings. SQL Server comes with analysis services, integration services, and integrates well with SharePoint.

Start small and move out. Agile methodology can work wonders, even though it has its own pitfalls. Find a project sponsor, someone in the business whose needs you can meet in a timely fashion. Deliver a quick, capable and competent solution. Other business units and users will take note, and you'll get buy-in much quicker and easier than just trying to convince people with charts and promises. Start creating value as quickly as possible.

You really don't want to waterfall a massive upgrade, in a single swoop. It's extremely difficult and likely to end in failure, at least in some form. Look up some of the SAP implementations undertaken by massive companies and the lawsuits and losses that follow (just as example, not out to get SAP).

Don't be afraid of a multi-phase project. It's easier to move from somewhat disjointed individual projects that were all built off SQL Server, SSIS, SSRS, and competent, modern, design to a unified whole, in a year, when the business loves you, than from multiple languages, platforms, architects and the array of data issues that come with that.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top