BI on the Mind…

From a student:

From: William BoebelSent: Thu 2/9/2006 10:30 PMTo: Russell MicklerSubject: RE: Individual Project – Last Assignment MIS370-0601A-01

Attached is my assignment. Thank you.

By the way…

In live chat you mentioned business intelligence as a primary part of your company’s business. I was curious what your opinion was on SQL Server 2005 from a business intelligence perspective.

I am interested in the closer integration of SQL Server with C# and VB.NET for stored proc’s, but I hear hype about the business intelligence aspect of the newer version. It seems to me that BI comes from the development of applications that process database data and provide information to users. So shouldn’t an RDBMS system stay out of that area, and just be real efficient at managing data? Let the IT staff or consultants be concerned with developing BI solutions since they will be very specific based on organizations anyway?

Billy

***

Hey Bill -

I’d have to suggest my experience with 2005 is nill; I’ve very familiar with SQL Server 2000, of course, but I think its ETL tools (Extract, Transform, and Load) are more comprehensive in 2005 than 2000. I think, like any _platform_, SQL Server’s use as a BI tool would be limited to the orchestration of its architecture (the schema development) and its reporting development (strong systems analysts who understand the business, its products, and its services). Out of the box, SQL 2005 may offer stock reports, but like anything, they’ll only be useful from the perspective that the data being populated conforms to the expectations of a “standardized” business model. And, in my experience, these tools must be customized to deviate from a preconception of “standard” business practices to meet the unique needs of any business to be really useful. So out of the box, SQL 2005 is probably a great platform to launch a BI initiative, but success utilimately depends on schema design and analytical prioritization in reporting.

And this touches on your conclusion that value of BI will come from the applications and customization of the platform to meet the user’s needs. I’d completely agree. Where SQL 2005 might offer stronger tools by which to develop and create these solutions, BI isn’t automatically “installed” with the upgrade to SQL 2005 as a product. If anything it introduces more risk for an indeterminant benefit that cannot be easily quantified (example: what _IS_ the ROI for upgrading to SQL 2005 if I’m unsure what BI benefits can be achieved from it? Am I prepared to risk a migration that could disrupt the existing business system for an undefined benefit?). I’d ask your developers/consultants, point blank:

1. Articulate the tools in the SQL 2005 platform that are not available on the SQL 2000 platform that would be beneficial to your constructing applications or reports that’ll improve my BI.

2. Give me an example of how those tools will be applied (give me an idea of the report, data, information, DSS, query, whatever).

This should allow you, as a manger, to weigh cost, risk, and benefit. Is the benefit of the example tool really worth the cost and risk of upgrading the platform? In other words, is there _really_ a benefit to the upgrade? Further, how does this balance out to the other IT priorities of your organization? Is there a demand from your internal or external customer base? Is it relevant to current business problems? Is there enough budget to accomplish what they want, or, is your team just “dreaming” about possible uses? I mean, let’s not upgrade because it’s fun… they should justify the risk for you.

Personall, I’d be concerned about a SOA (Service Oriented Architecture) and capitalizing on self-service functions. I’d be questioning the overall architecture of the BI layer in conjunction with the MIS layer. Are there opportunities to push reporting to the end-consumer of the data without having to draw on IT resources (like, can we have users use a DSS or reporting tool on their own to build BI… on their own… without us)?

Eh, my two cents. Good luck!
R