I'm Not Wrong

  • Intelligent Solutions

    I'll try to write up more this coming week in a series of articles on Business Intelligence and my thoughts after spending last week at the Microsoft 2007 Business Intelligence Conference up in Seattle. I did think it was a productive week and it seemed that many of the people attending, technical and non-technical, thought it was a good conference.

    Let me give you the good news first, other than the fact that I've been right all along . Business Intelligence is very cool and it seems that it's got a great ROI for those that actually spend the time to implement it. The ability of business people, analysts, executives, even first level managers, to drill down into data and search out patterns or even see anomalies they were not aware of is huge. I listened to two CIOs respond to a question about the ROI. The main idea of their thoughts:

    If even there's a 1% increase in better or more informed decisions, it makes it a no-brainer to implement this stuff.

    Granted these CIOs are not implementing BI in the OLAP or Data Mining sense for the first time in their careers, but they easily see the value. In a line of business or department that has $1-2M in revenue, 1% is $10,000-$20,000 and they both said that with Microsoft BI products, the investment is so much less. They also thought that the newer tools of the last 3-4 years, MS and non-MS, make it easier to more rapidly build, prototype, and deploy solutions.

    That sounds cool, but the overwhelming message that I got from many sources is that you need a strong buy-in from the executives and that they have to be willing to work at this for some time. It's not a 3 month project, it's a multi-year project that you keep plugging away at and realize the value of the investment by having both business people and IT people learning and gaining experience.

    Sound at all like OOP or other methodologies? It does, but that doesn't make it or those ideas wrong. It means to me that the world of BI is still a niche, slow-growth area because there are not enough believers willing to make those investments.

    Plus you need a great data warehouse (or mart) to start with. Companies have enough time with those trying to build a single version of the truth.

    If you're interested in what some others thinks:

    Katmai

    The other big news this week was information on Katmai. We actually saw a short demo on Thursday last week at the keynote with an insert and select or spatial data. We saw a polygon of mapping data inserted in a new "shape" data type and then used to power a map. At least they said it was, never saw any code. They may have shown more in Friday's keynote, but as a member of the press, I got kicked out

    Katmai is due to release next year, sometime between Jan 1 and Nov 5. At least that's my guess with Nov 5 being 3 years since SQL Server 2005. The timeline for new versions of SQL Server was given by a few Microsoft managers as 24-36 months between versions and so I'd plan on that.

    Steve's Pick of the Week : Katmai Datasheet

    I know it seems like SQL Server 2005 was just released, but it's been out for 18 months and in a year or thereabouts, the next version will be coming. Which means if you haven't upgraded, you'll want to start thinking upgrade sometime between now and next July to get off SQL Server 7 or 2000.

  • I think "business intelligence" is a bit of an oxy-moron when it comes to management... if you can't get them to invest in intelligent/skilled people to run and protect their databases, why do they think any BI product is going to save them?

    Databases seem to have become a dumping ground for GUI programmers that need some common place to store their data... those are the wrong people to run and protect a database.  Get people who have good solid database intelligence and the business intelligence will be a natural fit.  Otherwise, it'll just be a desparate attempt to make some sense from data that doesn't.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I think you are wrong, 1% of $1,000,000 is $10,000.

  • Ditto.  But if we use Steve's math it sure does make that 3% - 4% raise look a lot better.

  • I was going to jump in on the arithmetic error but others got to me.

    But there's a more serious error: the old "one version of the truth" mishegahs. There is no such thing in any area of life, save the religious sphere, and even there...

    For example: which way does a clock turn, clockwise or counterclockwise? I'm guessing you said clockwise. I say counterclockwise.

    You are right. And so am I. I'm looking at the clock from the back.

    The other aspect of BI BS is that well-constructed data warehouse. Those are incredibly difficult and expensive to build, in money, aggravation, and emotional terms. Those sizzling displays of charts, stoplights, etc. don't give a clue how expensive the steak is.

  • Typo, fixed now. The $10-20k they see as a investment (for technology, not people), makes it easy to decide to do. Of course they already believed in having a good Data Warehouse, so that makes sense.

    For most companies I've worked for, a central DW was a dream, not a reality, and there's a huge investment in getting something like that going.

  • You are right, an enterprise DW (central DW - as Ralph Kimball's DW approach) is very hard to accomplish.  Most companies jus do data marts for certain departments and projects (Bill Inmon's approach).

    BI can still work on data marts.  The problem was not the technology, one problem was the company willing to spend the money, the other problem (which I think it was much bigger) was there was not enough skilled people to do the job.

  • Not sure, and don't really want to get into a religous data warehouse discussion, but I think you have the data warehouse approaches flipped.  Kimball talks about a Data Bus while Inmon's is the Corporate Information Factory.  The data marts of the CIF are fed from a central data warehouse.

  • I don't want to argue but just want to make sure the fact.

    This is the website explaining the difference between Kimball and Inmon approach.

    http://www.1keydata.com/datawarehousing/inmon-kimball.html

    Bill Inmon's paradigm: Data warehouse is one part of the overall business intelligence system. An enterprise has one data warehouse, and data marts source their information from the data warehouse. In the data warehouse, information is stored in 3rd normal form.

    Ralph Kimball's paradigm: Data warehouse is the conglomerate of all data marts within the enterprise. Information is always stored in the dimensional model.

    Kimball's approach is creating an enterprise data warehouse while Inmon approach is creating different data marts.

     

  • I had the pleasure of meeting Steve at the Microsoft BI Conference in Seattle. We had a nice long talk in the middle of our booth, which was hopping both exhibit days due to a lot - as in a LOT - of interest in our Analyzer front-end tool for Analysis Services.

    As Steve has noted, the show indicated a high level of interest in BI. One poster mentioned he thought there were 1500 attendees. Actually there were 2600 - quite a good number for any first-time conference.

    Steve has made a number of positive comments about BI, but also has some honest questions:

    As for the need for executive buy-in, that is nothing new for IT projects. If I had a nickel for every time I have read about the importance of executive buy-in.....

    Regarding many BI projects taking 3 months or longer, that too is nothing new, at least for cross-departmental IT projects, and even many departmental ones.

    As for the complexity of BI projects, I agree there is complexity involved, but also agree with another poster who said the complexity is probably not more than that of many technologies featured on this site. I think because it is a "new" (in some ways) and unfamiliar technology to some it can seem more complex than it is. Also, the complexity of any technology can be greatly reduced with the right tools. Frankly, that's why we had so much activity at our booth - once you have your cubes (we don't do that part) Analyzer makes it verrry easy to access them and build, deploy, modify, and securely distribute those reports using Internet Explorer. 100% zero-footprint. Simple.

    Older technologies like RDBMS have had more time to accumulate a set of tools to reduce the underlying complexity. This is starting to happen with BI, in particular Analysis Services. For example, Analysis Services 2005 provides some nice designers and wizards which greatly simplify the process of building cubes. And there are other 3rd-party tools that also are very good at reducing the time it takes to build well-designed OLAP cubes from your underlying source data.

    Is there too much hype surrounding BI? Sure. There is always too much hype surrounding any market. But that doesn't tell us anything about the BI market except it is like other markets in this respect.

    As always, it falls to a company's business and IT people to cut through the hype and decide if this technology is going to help them be more successful in the marketplace. If so, then they should pursue it. If not, they shouldn't. Their competitors will be making the same kinds of decisions. The ones who make the better choices, in general, will do better than the ones who don't.

    Some things never change.

  • Once you have your cube, all you need is Excel.

    Oracle has added a CUBE subclause to the GROUP BY clause. Does SQL have something similar?

  • Yep... check Books Online... SQL Server has had it for a while now.  It also has ROLLUP which is like CUBE but without all the extra subtotals.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 13 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic. Login to reply