Microsoft Office 2004: A Product Vision Study
One way to think about MS Office is that it is software that is intended to be the editor and reader software for the majority of all information people look at on computers. This is particularly true if you include Internet Explorer in the mix. What does this imply for the context of corporate enterprise computing? The term "enterprise" is often overused and Microsoft has already claimed it simply to mean the biggest, most complete, most expensive version of a product. What I mean by it here is what is meant in the context of true enterprise software. You know, ERP, MRP, CRM, and so on. The applications that used to run primarily on mainframes that are now hosted on large UNIX boxes, and increasingly on NT servers.
Let's fast forward for a minute. Computers have been doubling their power roughly every 18 months in accordance with Moore's Law. However, these enterprise applications scale roughly according to the nation's gross national product, which is a very far cry from Moore's Law. They do this because that's how fast the number of transactions a Fortune 500 company must process grow. Simply put, the size, and therefore the cost, of computer needed to manage the corporate data and to automate whatever manual processes remain is falling fast. This is bad news for the big iron crowd. IBM's growth was stunted first by the PC phenomenon. The minicomputer companies abruptly vanished, having been caught in a no-man's land between mainframe and micro. And today, the Sun/Oracle/UNIX Hegemony represents the sole survivors. But this Moore's Law business hasn't ended by any means. The smaller machines keep ratcheting up their power. I'm typing this, in the year 2002, on a personal computer equipped with 120GB of hard disk and 1 GB of RAM. It cost less than $2000 and is more powerful than most of the mainframes in use when I was in graduate school during the 80's.
What all of this means is that the Wintel behemoth will continue capturing territory, driven on the insatiable flames of the Moore's Law rocket ship. Sun and its ilk will move into decline, if they haven't already. This will not happen next year. Or the next. Perhaps it will not be evident for as much as 5 years. Some of this newfound computing power will be used up providing new functionality--a task that eats cycles faster than the GNP grows, but not fast enough. It is therefore inevitable that Wintel must eventually win the race. Meanwhile, Microsoft is not really on top of this phenomenon, except perhaps within the SQL Server and related groups. What am I worried about? I just "proved" Wintel must win. What more must Microsoft do? My message is simple:
Microsoft must prepare itself for the eventual dominance of the Wintel architecture by making sure it hasn't ceded too much of the valuable Enterprise mindshare to players that were more relevant during the UNIX/Oracle period.
One of the ways it can do this is by enabling MS Office to play a fuller role in the Enterprise world. Let's take my own company's software as an example. I work for Callidus Software. We produce a package called TrueComp. Basically, it is used to manage incentive plans for extremely large workforces. It begins to be interesting at about 200 heads or more on a comp plan. It replaces work that had been done in very laborious and error-prone fashion with Excel. Many large companies have large groups of compensation analysts toiling away calculating bonus checks for sales forces and the like with Excel. With our software, this can largely be automated, freeing those resources to add value to the corporation in other ways. It's class Business Process Automation, and it works very well. The problem, from Microsoft's perspective, is that we take people, data, and value-added that had been entirely associated with Excel, and move it into other software, virtually none of which is Microsoft's unless the customer runs on NT machines with SQL Server.
Does this mean Microsoft sells fewer copies of Excel? Not exactly. But it does mean these folks spend a lot less time with Excel and that they need not push the envelope with Excel as much since the big models for compensation are now in our software. I submit that the implication is that these users are becoming less demanding of Excel, and therefore far less likely to upgrade. Ah, I see I now have Microsoft's undivided attention. What can we do about this problem?
I suppose someone, somewhere, would argue that if only Excel had this feature and that feature that these customers might not need to switch to Callidus TrueComp, or other Business Process Automation software that enhances productivity. I think this is a tremendous oversimplification. Excel is a virtually domain-free tool. That is its greatest strength and its greatest weakness. It is generic, except that it deals with numbers. The strength of these enterprise software packages is that they are domain-specific. They understand what you're trying to use them for, and a lot of your work has been done for you by the creators of the package. If you understand the difference between domain-free and domain-specific in this sense, you can see why adding features to Excel to replace these packages is not the solution. We must dig deeper.
A closer look at these packages reveals that they rely on a lot of third party technology. Who wants to reinvent the wheel anyway? Let's look at what's in Callidus TrueComp, for example. There is a rules engine from Blaze. Basically, this is a piece of technology that plugs in so we can evaluate formulas. Hmmm. Does that sound like something Excel is able to do? There is a report generator from Actuate. This is a tool that we can point at a database in order to produce tabular results suitable for printing or reading. Again, tabular results? Doesn't Excel do this?
Long ago, in a galaxy far away, people used to dream of building block integration. The old idea of a monolithic application was supposed to disappear. We could pick and choose our building blocks in an infinitely extensible, just enough to get the job done, no more bloatware kind of way. This goes back as far as the late 70's and early 80's when a company called Ovation spawned a demo and then disappeared, unable to back it up with real technology. It's probably even older, as the original concepts for the web were of much more interesting building blocks than just text and formatting. Microsoft, for its part in this play, produced two technologies aimed at building block automation. One was called DDE, and the other OLE. They were never really very successful as more than demoware. Today, machines are finally powerful enough that you can embed objects in documents, but it is cumbersome and barely tolerable. Today, there is a new initiative on the horizon. We hear talk of web services, and something called .NET. We've come full circle, but we still aren't doing it right!
What? .NET is not yet even fully hatched from the minds of Microsoft and we aren't doing it right? Well, perhaps .NET is right for some purposes, but not for this one. The problem we have here is that despite all marketing hype to the contrary, MS Office is a collection of monolithic apps. Never mind the years of object oriented programming talk. This is a problem both psychological and technological. The folks who write these applications can't imagine anything in the world that shouldn't be viewed as an appendage of their magnificent work. They want their code in control and at the top of the organizational pyramid. It may occasionally consult some lesser collection of bytes about some insignificant detail, but by and large they run the show.
Microsoft needs to overcome this limitation. Given the age of these code bases, and the years of intransigence, it is likely that a whole new development initiative will be required to accomplish this goal. What finally must be accomplished is the separation of engine, user interface, and features into component parts. Excel, in this incarnation, would consist of an engine entirely bereft of user interface, and incapable of doing much more than basic arithmetic. An extensive collection of objects could be used in conjunction with the engine to assemble the full product. Conversely, companies could license the engine and add their own custom parts to remake Excel into the formula engine at the heart of Callidus TrueComp, to name one example.
The Excel display engine should be really good at grid displays. It should be possible to re-purpose it to any grid display imaginable, and by adding or deleting appropriate other objects, to wind up with something that works exactly like Excel, or like anything else you choose.
Microsoft will want to require some guidelines that further its causes. Perhaps users will be required to follow the user interface of the MS Office applications where possible. This will do no great harm, but is likely unnecessary. Smart companies will adopt these conventions anyway, because their users are already trained on MS Office and don't want to learn an entirely new way of computing.
From a practical standpoint, producing this Enterprise Component Computing vision will require multiple releases and years of effort. It starts with an entirely fresh sheet for implementing this architecture. It will grow slowly. Having this power available at reasonable cost will be strategically invaluable to Microsoft over the years. MS Office can provide all the impetus needed to drive users to the other Microsoft offerings, helping to ensure software runs on some flavor of Windows and is developed with Microsoft tools.
What more could Microsoft want?
Miscellaneous Office Nits
It's very common in PowerPoint to have a print run screw up halfway through. Perhaps your inkjet printer runs out of ink or something. I'd like to be able to type in a range of slides to be reprinted. No problem, I can do that. But I have to know exactly how many slides are in the system because if I ask for slide 23-<really big number>, PowerPoint is going to insist that the <really big number> is not a valid slide. How helpful is this? Why doesn't it just print all the rest of the slides? Some idiot programmer wasn't thinking.
All material © 2001-2006, Robert W. Warfield.