That is very interesting/somewhat surprising to see - thanks for posting, David. I know of a former TM1 partner that has been doing a fair bit of Performance Point work - maybe they were one of the only ones, and it's possible they were more focused on the reporting components and Sharepoint, less on the planning/other components of Performance Point. I guess this saves me the trouble of installing and trying out Performance Point - that's certainly one way to knock things off a to-do list.

Has anyone come across any other Performance Point-like products that sit on top of the Microsoft "BI stack" (SQL Server, Analysis Services, etc)? I know from implementing OutlookSoft long ago that it once qualified, but since it's been swallowed by SAP I'd be inclined to think even less highly of it . Just curious if anyone's come across Microsoft-based OLAP much beyond IT "cubing" some user data with Analysis Services.

Surprise: having panicked the whole industry into precipitous consolidation, it turns out that PerformancePoint was just a boogeyman. The consolidation has accelerated certain industry trends and virtually cemented an important outcome. Just as Microsoft has ceded large financial analytical applications, at the same time the "winners" have walked away from general purpose scalable OLAP.

We are approaching a turning point: in a few years tens of millions of Excel power users will have full-featured OLAP at their fingertips. The transformative impact on the workplace and the industry is hard to overstate. The mid-market will be overwhelmed from the bottom up when domain experts have no need for OLAP experts, and the high-end will become the narrow province of big-iron and increasingly specialized applications.

TM1 is well positioned to compete as a high-end player. It was once positioned to lead the larger revolution, but this is not to be. It will be Microsoft's Gemini, or something like it. IBM is no more competent to operate in the mass market than was Microsoft in its misguided venture at the other end of the spectrum.

We are approaching a turning point: in a few years tens of millions of Excel power users will have full-featured OLAP at their fingertips. The transformative impact on the workplace and the industry is hard to overstate.The mid-market will be overwhelmed from the bottom up when domain experts have no need for OLAP experts, and the high-end will become the narrow province of big-iron and increasingly specialized applications.

Hmm not sure about that, I think it will be very easy to over state, having worked with Excel users for many years most have recieved no training and are expected to figure things out as they go, it's an end-user productivity tool don't you know! Most struggle to grasp what is going on with pivot tables (pivot what?). I can't see them all becoming expert OLAP developers just because a tool is available in Excel.
I think OLAP experts will still be required though more maybe working in Excel.

Is there much detail in the public domain yet on what the features of Excel OLAP will be? It seems strange to be expecting big things from an additional piece of Excel functionality when the same company could not make a comercially viable stand alone product even with the name and pockets of M$ behind it.

Still I guess this is all crystal ball stuff, who really knows?
Cheers,

I agree about typical Excel users. Sometimes I think they would need help tying their shoes were it not for the invention of Velcro. I am thinking of "power users" who are only a fraction of all users but are still legion. When I show TM1 to Excel power users the majority take to it like fish to water. (Not, however, rule based applications, where most hit the wall fast and hard.) The most frequently asked question after "What does TM1 stand for?" is "Why doesn't everybody use this?"

Yes, I am engaging in crystalballery, and could be biased by my frustration with the (obvious) answer to this question.

Of course there will still be a need for experts, a growing need, but I anticipate an explosion of productivity from non-experts. I think that if people familiar with basic OLAP concepts are not yet at critical mass for going exponential then they are very close to it. All that is lacking is convenient access to useable tools at a mass-market price, and this seems imminent. Unlike the market for their standalone, this is where Microsoft knows a thing or two. I do not expect their offering to be particularly good. It doesn't need to be as long as it is usable and cheap, or bundled. My future frustration could be with a relatively poor product dominating the mass-market and being leveraged through IT channels to carve up the mid-market.

But, I must admit, if my crystal ball were really any good I would not have been with a company specializing in homebuilding finance at the very moment when homebuilding burst a bubble and finance had a meltdown of historic proportions. Expect the unexpected.

Mike L wrote:I agree about typical Excel users. Sometimes I think they would need help tying their shoes were it not for the invention of Velcro. I am thinking of "power users" who are only a fraction of all users but are still legion. When I show TM1 to Excel power users the majority take to it like fish to water. (Not, however, rule based applications, where most hit the wall fast and hard.) The most frequently asked question after "What does TM1 stand for?" is "Why doesn't everybody use this?"

This may be bias from my own perspective, but I believe that another limiting factor is that a stand-alone, Excel-driven OLAP product will not allow one big thing which drives TM1 usage; collaboration. In our case, the ability of the sales and production sites to collaboratively input into a TM1 model to generate costings, or the ability of diverse business units to input budgets and forecasts independently which can then be pulled together by a central planning department to get a corporate "big picture".

There's also the fact that summarised data can be pulled from transactional systems. If this is done into centralised, shared cubes it's far more efficient than doing it on a desktop-by-desktop basis.

Unless they screw up the early releases, shared data and write-through will follow on later. I would be very surprised to see it get stuck in the well-understood "spreadsheet hell" trap. While the idea of running a substantial BPM/planning application on the Microsoft stack makes my skin crawl, it will be very appealing to mid-market IT droids when the swelling ranks of OLAP-aware desktop users demand collaboration features.

Don't get me wrong: the market for tools better suited to large or sophisticated applications will only grow. Ceding the low-end market was not a bad strategy (My crystal ball tells me that commoditization at the low-end is inevitable.) and sacrificing a good chunk of the mid-market just goes with the territory.

My crystal ball tells me that commoditization at the low-end is inevitable

If commoditisation is

the movement of a market from differentiated to undifferentiated price competition, from monopolistic to perfect competition.

then you don't need a crystal ball it's here already with the advent of open source tools like Palo and Jaspersoft which are exposing the licence and support models of the big boys to some scrutiny already.

The existence of "mid-market editions" and other ploys, which are the software equivalent of selling ex-demonstrator cars to preserve top end brand image, show that the big boys are taking this threat seriously and that they are already reacting to the inevitable erosion of their previously comfortable margins.

http://cobb.typepad.com/cubegeek/2009/0 ... -dead.html
It's worth quoting in full here - with some highlights (of mine)
Disappointment indeed. It's now official. I can say with finality that I wasted a year in my career. In fact, a lot of good people that I know personally wasted a year and even longer chasing the rainbow that was Microsoft Performance Point Server. It's a damned shame because some very smart people worked very hard and some hard earned money turned out to be a bad investment. I personally know people who went halfway around the world trying to make Microsoft PPS do what it was supposed to do. It's not just the clients of Madoff who are pissed these days.
I was fortunate to get hit over the head with a brick almost exactly a year ago when my boss made the judicious decision to trim his sails and begin cutting his losses in an ambitious project to corner the consulting market on PPS. We were the consulting vendor of choice. We proved that we could do things with that product that almost nobody else could and we survived on hope, skill and the kind of gallows humor dedication of the dogfaced GI.

There were several occasions when I had to stop and scratch my head wondering if it was just me or were we pushing ropes. But I'm no quitter. If there was a way to make that stuff work, we were going to do it. Now what I remember of the story can be told.

First of all, PPS was a decent product. It had particular strengths and weaknesses that you might expect from a version one launch, but in my revised opinion - the kind of opinion I could afford to develop after I left the team, there were certain things that simply doomed it. Only one of them had to do with the technology.

The first and foremost thing that doomed PPS was that it was a Microsoft product and what I learned was that Microsoft, certainly as far as PPS was concerned and probably in general is a technology company, not a product company. That is to say that Microsoft is the kind of company that is well suited to marshal its resources on a global scale with a large existing installed base of interlocking technologies but that ability doesn't scale down. Microsoft is incapable of profiting from small products with small markets, and from a Microsoft perspective PPS was tiny.

Secondly PPS itself belonged to nobody. Not that there were 'nobodies' in charge of it. In fact there were multiple big somebodies in charge of various parts of it. There lies the problem; there simply was not one integrated product organization that could make decisions in support of the product and then stand behind those decisions internally to Microsoft or externally to consultants and customers. PPS primarily belonged to 'OBA', the guys responsible for Microsoft Office. Now I know BPM people are saying what!?. I did too, but that's the way it went. PPS also depended on Excel, which was another group. PPS also depended on SharePoint which was another group. And of course it depended on SQL Server & Analysis Services, yet another group. So who coordinated all of those development efforts? Effectively nobody.

Thirdly PPS had no product roadmap. The product roadmap for PPS was basically a function of sales. We throw it out there to 50,000 customers, we expect an adaptation rate of 3% at a price of X per pop, there's your revenue stream. Completely absent from that was a feedback loop. Microsoft didn't care a hoot about what customers and developers might have to say about the product's features or shortcomings. It was as if a mighty focus group or marketing exec had spoken and that was the end of it. So when things went wrong, and believe me a lot of things went wrong, there was no recourse. So nobody inside or outside of Microsoft, situated to support the product knew if, for example, there would be a published API for the product. Nobody knew if there was actually going to be a next release or what the priofities might be in that release. For all the things we knew that worked or didn't work internally to the product, we would be stuck telling our customers - well we don't really know when Microsoft is going to address that. In fact, we didn't even know IF Microsoft was going to address that.

Fourth. PPS just didn't perform. I had guys working the guts of this product and one of the things that was entirely too clever about it was that it had a kind of code generator that would determine whether or not it would use MDX or T-SQL to execute its functions. I don't recall what people have said about how well optimized Microsoft compilers are, but obviously none of those geniuses worked on optimizing PPS. PPS would generate a meta-language that was basically full of crap. Our guys were hand-coding all of the internals and forcing the product to use SQL instead of MDX, period. It was the only way to get it performing worth beans.

I recall a famous meeting I had up in Redmond with some really sharp guys that Microsoft had redeployed from FRX to get on the PPS bandwagon. I didn't like it because it meant that Microsoft was hedging on us as a consulting vendor, but we all figured that the market would eventually take care of us all so we played nice. One of the top three PPS architects in the world was there explaining and demonstrating one of the few successful internal implementations. As we went through the demo the architect did a drilldown in Excel. You know me, I counted seconds for response time. ..6..7..8..9..10. After about 12 seconds we got about 50 rows of data. Let me make that clear, 50 rows with 12 columns, 600 freaking cells. This, I know because I asked, was coming off of a 64bit server. Anybody with any experience in OLAP knows that kind of performance was unacceptable back in 1992. At the time of this meeting, there was only one person who actually had any experience doing any back-end tuning behind PPS. All I could say was, well, FRX has done well in the mid-market, so maybe this isn't so bad. But I knew from that moment on that it would be a cold day in hell before we could beat Oracle, Cognos or even Outlooksoft for Enterprise customers.

And yet Microsoft people had the nerve to believe that their entry into the market - their purchase of ProClarity was this fearsome move that *prompted* Oracle to buy Hyperion and IBM to buy Cognos. Unbelievable.

I have to say in retrospect, that PPS was the crappiest product I've ever had to work with for its market. ProClarity was 3 times better by itself. ProClarity as a company may have been destroyed here, but there's an object lesson that the brains behind ProClarity and the organization was much better suited to manage that product than Microsoft. I've come to terms with my frustration with Microsoft. I don't hate them, but I understand why people hate them. I have never, in my entire career, had customers so furious at me for a failure to deliver on promises implicit in a product. I have never seen smart consultants so frustrated by a product's complexity and poor performance. I have never seen businessmen have to tapdance so fiercely to keep everybody on the same page.

I've learned a great deal about Microsoft, people and myself through my experience with PPS. I can say this. When it comes to delivering products and services to the enterprise, Microsoft is better to have as an enemy than as a partner.

To all my friends and associates in Redmond and Century City, to all of my customers and partners in Washginton, Arizona, Oregon and Hong Kong, you know I have great respect and admiration for your courage under fire. I'm sorry to have failed you. I did all that I could, but now you know that Microsoft just didn't back us up.

That's quite a story David and a very interesting and well explained analysis.

That is to say that Microsoft is the kind of company that is well suited to marshal its resources on a global scale with a large existing installed base of interlocking technologies but that ability doesn't scale down. Microsoft is incapable of profiting from small products with small markets, and from a Microsoft perspective PPS was tiny.

Why does this sentence set alarm bells off with regard to another product that we all know and love?