Some Thoughts on Real-Time Data and Innovation

First off, the news. Yes, I’m now working for Aberdeen Group. And a big shout out to my fellow analysts. J Now back to commentary.

The latest edition of MIT’s Sloan Management Review has a couple of interesting articles, one on the effects of real-time data and one on IBM’s Innovation Jam. The one on real-time data (“The Downside of Real-Time Data”, Alden Hayashi, reviewing recent research by Swaminathan and Lurie) suggests that getting new data in real time can actually be harmful – that is, decision-makers fed daily retail data instead of weekly averages tended to over-react to negative or positive news, resulting in inventory replacement orders that were actually less optimal than those of the “behind the times” managers (especially when day-to-day sales variance was high). The researchers do note that systems can compensate to some extent by ensuring that decision-makers are given some historical context on the same screen as the latest figures.

I think it’s reasonable to extrapolate to CEOs and CMOs (not necessarily CFOs; they are so tied to long-term data that it’s hard to imagine them over-reacting to the latest uptick in inventory in a rolling balance sheet). Yes, the latest craze for 360-degree view performance-management dashboards based on event processing could indeed enable CEOs who not only take a short-term view of the company’s stock price but also of the strategic levers he/she has to pull, resulting in erratic company shifts in tactics and/or strategy.

However, I think this point is entirely irrelevant to the main value-add of real-time presentation of event-type data (that is, data that represents a shift in the environment: a customer order is an event, a description of a product part is not). Each event-response loop is, or should be, part of a business process; the main idea is to speed up the response in order to satisfy customers, react to unanticipated events, or save money, not to improve decisions. The side-effect is that delaying a response often forecloses options, so that decisions are necessarily less optimal; these studies do not test that notion. In other words, in the real world, if you design speeded-up event-response loops by speeding real-time data presentation in the context of an existing business process, you will indeed include context or you won’t need it, and so 99% of the time what results is good for the organization.

Btw, the real danger, which we may run into someday, is “herd behavior” such as we have seen in the markets, in which multiple organizations “head for the exits” at the same time in immediate reaction to the same news, creating an avoidable vicious cycle. But the game is still worth the candle …

Anyway, the second article talks of how IBM did a massive “jam session” in 2006 to ask its employees to contribute ideas for turning IBM technology in its labs into products. The first phase simply collected the ideas; the second phase, after managers sifted and aggregated ideas, was to attempt to turn the ideas into clear product concepts with attractive markets. Particular examples of areas in which the Jam gave a boost that usually resulted in real-world products were green technology, health care (electronic health records), and integrated transportation management. The authors’ (Bjelland and Wood) conclusion was that this was a promising new way of doing an innovation process, with the usual tradeoffs (“powerful but ponderous”).
I think they’re missing a bet here. Has nobody noticed the similarity to open source? In other words, we’re back to the idea of world-wide but to some degree unrepresentative proxies for the customers helping to design the product. To put it another way, these designers (a) combine the technical skills and company knowledge to design products with the reactions of global customers; (b) are treated to some degree as an equal mass, not a hierarchy in which those lower down are ignored; and (c) insist on going their own way, not the way the company lays out for them.

Here I must make a confession: I participated in much the same sort of process at Prime, shortly before it melted down in 1989. The big advance in IBM’s approach, compared to that one, is that it (as far as possible) treated all ideas as equal – Prime by its DNA was unable to resist having “senior gurus” and desperate GMs take charge, with the result that the only ideas that might have saved Prime never surfaced or were ignored (my own idea was “let’s build a new kind of desktop that allows cross-filing”; I still think it was better than the senior-guru idea that was favored, “let’s build a framework and figure out what it’s a framework for as we go along”). The other major difference was that IBM in 2006 had pantloads of employees who could contribute real new ideas based on constant engagement with the world beyond IBM; Prime in 1989 had very few.

My net-net? For the favored few that are large and have that kind of employee, there should be more Innovation Jams, not less; anything to escape “not invented here.” For the rest of us, I think it just won’t work; not enough critical mass, not enough qualified participants. Instead, let’s go back to our communities. They’re a bit more reactive; but, boy, do they do a better job as proxies for the market.

Data Virtualization in the Real World

In a previous piece, I noted that data virtualization is (a) a logical extension of the idea of virtualization, (b) has definite benefits to IT and to the enterprise, and (c) is implementable but is not easy to implement. The basics, I noted, are an enterprise metadata repository and a “veneer” that makes multiple data sources look like one system. The end product is infrastructure software that makes data, presented as information (that is, in an understandable and usable non-physical format, such as in a database), appear as if it were in one cross-system data store. So what is out there to create a data virtualization solution today, and how does it need to be improved?

Today’s key data-virtualization technologies are Enterprise Information Integration (EII), the data warehouse, master data management (MDM), and metadata management. Each now has solutions creating value inside real-world proactive enterprises; each has its pros and cons. Let’s examine each in turn.

EII products provide a SQL/XQuery veneer for real-time database transactions crossing multiple data sources, including relational data, content, and the Web. In order to do this, they typically auto-discover data sources of these types, and store the information in a metadata repository, supplemented by the enterprise’s knowledge of data semantics, copies, and relationships. The pros for using EII as the basis for a data virtualization solution are its strengths in gathering metadata, its support for real-time transactions, and its flexibility in handling a wide range of data types. The cons are its typical use for specific projects (which means added work extending it to enterprise scope) and its lack of enforcement of corporate standards compared to MDM. Useful EII tools for data virtualization include IBM’s WebSphere Federation Server, Oracle/BEA WebLogic for Liquid Data, Sybase’s Avaki tool, Composite Software’s and Attunity’s products, Ipedo XIP (which also includes a database), and Red Hat/MetaMatrix.

Originally, data warehouses were receptacles for all corporate data replicated periodically (including data cleansing and merging) from multiple OLTP (online transaction processing) databases, with business-intelligence queries run against the days-old merged data. Recently, the lines have blurred, with data warehouses now able to query on the operational and content databases as well as the data warehouse, and to refresh in such a way that queries are on “near real-time” data. The pros of using today’s data warehouse for data virtualization are unmatched data quality and lots of available applications to use the virtualized data. The cons are that the data warehouse is getting farther and farther away from storing all of an organization’s data and therefore may not fit some data-virtualization needs, that the size of the data warehouse may slow both queries and update-type transactions against the virtualized data, and that a data warehouse typically does no auto-discovery of metadata. Useful data warehouses for data virtualization include the IBM, HP, NCR, Microsoft, Oracle, and Sybase databases.

The MDM field has gone from a gleam in vendors’ eyes to the focus of enterprise attention in about 2 years, but it’s still not a mature technology. The idea is to select key enterprise data and provide a “single view” via a transactional veneer and cross-database synchronization, typically involving a cross-database metadata repository. MDM accommodates a range of implementation architectures, from EII-like (no data moves around) to data-warehouse-like (all the data is replicated to a central repository). Moreover, MDM typically builds on top of EII, EAI (Enterprise Application Integration), and data-warehouse ETL (extract-transform-load) technologies. The pros of MDM are that it delivers virtualization of data that really matters to the organization, that the architecture is flexible and therefore can be fine-tuned for performance, and that it improves data quality in such a way that the enterprise really buys into IT’s data-virtualization effort. The cons are that it typically does not deal with some types of data virtualization (such as local data in different databases or content-heavy data), that it may not provide as extensive auto-discovery capabilities (although it is improving in that area), and that as a relatively immature technology it will typically require high service costs for vendor hand-holding. MDM tools now include IBM MDM Server, Sun’s MDM Suite, Microsoft’s Bulldog MDM project, Kalido MDM, Software AG’s webMethods Master Data Manager, and Oracle Master Data Management Suite.

Finally, enterprise metadata management (EMM) tools are the most immature of all of the data virtualization technologies. Here, the focus is on creating a repository of metadata for all (or most) enterprise data, with less focus on supplying tools for using that repository. The pros of EMM tools appear to be their strengths in auto-discovery and their savvy in representing metadata at the business level. The cons are the immaturity of the technology and the lack of tools for transactional use of the repository. While there are a few smaller-vendor products that have been out for a while from the likes of Adaptive Repository, the larger vendors’ products (e.g., IBM, CA, and Oracle/BEA’s AquaLogic Enterprise Repository) are pretty new to the market.

The point of this survey is that while it is hard to cite a product in the market that is specifically aimed at data virtualization, there is plenty of choice for users who want to repurpose an EII, MDM, data warehouse, or EMM product for data virtualization, and plenty of related real-world experience to draw on. Rather, the key barrier to data-virtualization success is rethinking the enterprise’s information architecture in terms of virtualization. Just as storage virtualization has allowed users to rethink their storage in terms of what can be grouped together, and thus has saved storage administration costs, data virtualization is best used to rethink how data stores can be grouped together. Then, by picking the product that is easiest and cheapest to repurpose for data virtualization, users can deliver its benefits immediately, and cost-effectively.

Data Virtualization: It Grows on You

When I first heard the term “data virtualization” from Composite Software, I admit, I was skeptical. Let’s face it, virtualization is one of the all-inclusive marketing terms of our time; it seems like everything is being labeled as virtualized these days. But when I sat down and tried to make sense of all of the “virtual” technologies I knew, data virtualization fit in neatly. In fact, it’s a logical extension of virtualization technology. And therefore, like other virtualization technologies, it has definite and distinct benefits to the user.

Let’s start with my definition. A “virtual” technology is one that detaches the logical scope of a system from its physical scope. More concretely, virtual memory, the virtual machine, virtual storage, etc. all make a subset or a superset of a physical system/resource like a computer, appear like one system/resource. Virtualization is the process of changing from the old physical way of seeing and handling a system to the “virtual” way.

Now note that all virtual technologies can either split up a single system or combine multiple systems, and that they can involve data or processes. For example, the virtual-machine meaning of virtualization (now its most common meaning) splits up the processes on a single machine into multiple virtual machines. The virtual-memory meaning of virtualization pretends that a small main memory (data) is really a large storage device. The storage virtualization meaning treats multiple systems (really data systems attached to multiple computer systems) as if they were one huge storage device. In fact, clustering and network file systems (really another form of virtualization) allow you to treat multiple systems (processes) as if they were one computer.
Here’s a neat little Table that captures how all the forms of virtualization that are being talked about these days fit into a nice neat framework (all right, it’s not really that neat in real life, but it’s a very good starting point).

,,,,,,,,Split Single System ,,,,,,,,,,,,,,,,,,, Combine Multiple Systems

Data: V. memory, V. disk ,,,,,,,,,,,,,,,,,, Storage virtualization, Data virtualization


Process: V. machine, app/desktop/profile v. ,,, Clustering, network file systems

Note that application, desktop, and profile virtualization may involve putting the virtual environment on another computer; but it’s still representing a part of a computer, not the whole thing.

Now all forms of virtualization share a common benefit of flexibility to users, but each category has specific benefits of its own. The benefit of single-system virtualization is a very good tradeoff of performance for cost (single-system); for much less cost and for a small decrease in performance, you can substitute disk for main memory (virtual memory, typically operating at 90% of the performance of an equivalent all-main-memory machine), or consolidate all your applications on one machine (virtual-machine virtualization).

The benefits of multiple-system virtualization still tend to be performance vs. cost, in a more complicated fashion. Storage virtualization makes administration easier, and administrators cost money. Clustering simplifies the programmer’s and system administrator’s life, as well as allowing failover that makes systems more robust; the tradeoff is less scalable performance (generally somewhere between 60% and 80% increase in single-system-equivalent performance per system added, vs. up to 100% per processor added in symmetric multiprocessing for up to 30 or more processors). Meanwhile, virtualization of processes, single-system or multiple-system, delivers flexibility to the system administrator to allocate resources and manage workloads; while virtualization of data makes the programmer’s job easier as well as easing the storage or database administrator’s burden.

Viewed in this way, the definition of data virtualization is straightforward: it is the implementation of a multiple-system data-source veneer that lets programmers, administrators, and users all view multiple data sources as one. And, likewise, the benefits of data virtualization flow from its being virtualization and its being multiple-system/data-oriented. That is, there may be a decrease in query performance (but maybe not; some IBM studies show that a tuned Enterprise Information Integration [EII] engine can actually deliver better performance on cross-database queries, by load balancing effectively). However, you will also give the administrator a simpler view of the “data archipelagoes” typical within an enterprise; you will give the programmer “one transactional interface to choke”, just as SOAs give the programmer “one application interface”; and you will give users, ultimately, a broader access to data. Ultimately, that adds up to more flexibility and less cost.

Like other forms of virtualization, data virtualization is not a pipe dream; but it’s not easy to get there, either. The basics are an enterprise metadata repository and a “veneer” that makes multiple data sources look like one system. In various forms, EII, the data warehouse, master data management (MDM), and repository products give you these basics; but it is extraordinarily hard to get the solution’s hands around all the data in the system and its copies and its relationships, much less semi-automatically adjusting to all the new types of data that are coming in and the important data outside the enterprise on the semantic Web.
However, just as the other forms of virtualization are useful even though they are not implemented company-wide, so is data virtualization. Within a data center, within a line of business, or just applied to the company’s most important data (as in master data management), data virtualization can deliver its benefits in a targeted fashion – as EII and MDM have already shown.

So yes, data virtualization may be marketing hype, but it also represents an important new body of products with important benefits to IT and to the business as a whole. Later, I hope to get down to the details.

Where are the EII Tools of Yesteryear?

All in all, it seems bizarre to me to realize that the old “pure” EII (Enterprise Information Integration) vendors are no longer thick on the ground. It was only 6 years ago that I first discovered EII tools and issued my first report – an extremely short half-life for a technology. And yet, of the existing or nascent EII tools then, Metamatrix has gone to Red Hat, Avaki to Sybase, Venetica to IBM, and another whose name I no longer recall was folded into BEA as Liquid Data and is now being re-folded into Oracle. Meanwhile, IBM has renamed Information Integrator as Federation Server, and rarely mentions EII. Of the oldies, only Composite Software and Attunity remain proudly independent.

And yet, the picture is not as bleak as it appears at first glance. Composite Software and Attunity are still small (under $100M in revenues), but continue to survive and even thrive. Ipedo and Denodo, newer entrants with interesting differentiators (Ipedo with its XML database, Denodo with its Web-search capabilities), are likewise out there. In fact, Stylus Studio with its EII support for programmers and Silver Creek Systems with its “missing link for EII” appear to have entered the fray recently.

Just as important, many of the infrastructure-software companies that have acquired EII vendors have come to realize that EII is a positive thing to customers and should be kept as a distinct product, not treated as another component to fold into a product or hide under the umbrella of an overall strategy. Sybase, especially, has been unusually active in positioning their EII solution as a “key component” of their key data-integration product suite.

However, it is also fair to say that EII’s marketing is not all it should be. A Google search turned up very few of these tools, and in the advertising on the right-hand side, several of the companies were not in EII at all (SAS? I don’t think so) and Sybase’s webcast on the subject was no longer available.

What’s going on? I would suggest that one of the key reasons for EII’s mixed picture of success is that vendors have begun doing what they should have done three years ago: leverage EII tools’ metadata repositories as separate products/value-add. Metadata management is now In, to the point that even Microsoft and EMC are now talking about enterprise-wide metadata repositories (and realizing just how tough the job is). In other words, some of the revenue and visibility that are derived from EII products are now showing up under the heading of master data management and composite apps (along the lines of Denodo’s “data mashups”) instead of being credited to EII.

This is not to say that EII is the only source of an enterprise metadata repository; EAI (Enterprise Application Integration) tools like IBM’s Ascential, data-search tools like EMC’s Tablus, and “pure” repository plays like Syspedia are other tools that can be used as the foundation of an enterprise-metadata-repository product. Still, I would argue that EII tools have virtues that none of the others share, or at least to the same extent. Specifically, creating a good repository is key to the success of a good EII implementation; such repositories are often used for querying apps, so optimizing query performance should be considered; and EII tools do both automatic discovery of a wide variety of automated data sources and support for hand-definition of data relationships and data with different names but the same meaning (“customer ID” or “buyer name”). Contrast this with EAI, which is usually restricted to a narrower range of structured data, is often handed the metadata rather than discovering it, does not have to consider real-time performance in queries, and often doesn’t provide support for the kind of data reconciliation involved in master data management. I was reminded of this recently, when I talked to Composite Software about a new Composite Discovery product whose foundation is an innovative way of discovering “probable” relationships between data items/records across data sources.

So the EII market is doing quite well, thank you, even if many of its pioneers have been folded into larger companies. However, EII remains under-utilized by large infrastructure-software vendors, not because their users don’t appreciate their EII implementations, but because vendors aren’t giving visibility to their EII technology’s usefulness in larger projects such as master data management and composite-application development. Where are the EII tools of yesteryear? Doing well; but not visibly enough.

EDAs: What About SaaS?

Over the last year and a half, I have been following with interest the rise of user and vendor interest in EDAs (event-driven architectures). My own take on EDAs: there’s some real value-add there.

Now, from a database programmer’s point of view, business-event handling is older than dirt. The basics of events, triggers, business rules, and stored procedures were there in the 1970s if not before; and a network-management specialist would probably tell you the same about distributed monitoring and alerting. What’s new over the last few years is the idea of an SOA (service-oriented architecture) that spans an enterprise network using standardized software interfaces. The basis of a SOA is often an ESB, or enterprise service bus, that acts to route calls from Web service consumer code, such as a Web browser, to Web service provider code, such as an enterprise app. This means that the ESB can now see all the events already flying back and forth from systems management, database transactions, and specific apps for specific types of events (such as quant apps handling stock arbitraging in milliseconds), filter them, report them, and act on them. So an event processing engine over/in the ESB – the event-driven architecture -- is a great way to handle existing event processing (such as systems management) across the enterprise.

Moreover, such an EDA moves event processing out of hard-coded existing stored procedures and apps to the enterprise-network level, where the developer can write enterprise-spanning apps. Hence the ideas of “business activity monitoring” (figuring out what’s happening in the enterprise by monitoring events on the enterprise network), “the 360-degree view” (adding monitoring the enterprise’s environment via RSS feeds, Web searches, and the like), and “the just-in-time enterprise” (semi-automated rapid responses to business events). No wonder vendors ranging from IBM and Sun to Progress Software and users like Orbitz are talking about EDAs.

So the obvious question is, why aren’t folks talking about applying EDAs to SaaS (software as a service)? When I google EDA and SaaS, there is a mention or two of the notion of supplying a CEP (complex event processing) engine as a service, but nothing really on the idea of SaaS providers offering an EDA on top of their SOA for added user benefits.

And yet, if I were a SaaS user, I would find an EDA offered by my provider quite intriguing. I might do business activity monitoring on top of my ERP app, or react quickly to customer-relationship problems identified by SugarCRM. As a boutique investment firm, I’d love the chance to create arbitraging code at lower cost.

And if I were a SaaS provider, I’d be interested not only in attracting customers by offering an EDA interface, but also in using an EDA to fine-tune hard-coded security and administration software for each multi-tenancy user. In fact, I think EDA would give me a great new tool for metering and charging users on the basis of business transactions rather than per-CPU.

So why isn’t there more interest in EDAs applied to SaaS? Inquiring analysts want to know …

HP + EDS Software: Hey, It's Insinking!

When you think about the HP EDS acquisition, don’t just think about its short-term effect on revenues. Think about the leverage this gives HP to do some long-term software investment -- for excellent profit improvements.

Why am I focusing on software? After all, in a quick scan of press releases and articles on HP’s announcement of its proposed acquisition of EDS, I find little if any mention of the acquisition’s effect on HP software. That’s scarcely surprising: by some calculations software is still less than 4% of HP’s revenues pre-EDS, although the software business is growing briskly. And that will still be true post-EDS. In fact, if you treat their software and hardware revenues and profits as part of one big pot, there’s some basis for saying that the key differences between IBM and HP post-acquisition go something like this:

HP + EDS revenues = IBM revenues – IBM business consulting revenues + HP PC/printer revenues

HP + EDS profits = IBM profits – (HP lower PC margins)

But I think there’s more to the software angle than that. Let me explain.

Way back when I was at Yankee Group, I was so tired of hearing about the glories of outsourcing that I wrote a spoof called “Insinking: The Future Lies Ahead.” The idea was that, since outsourcing was the use of outside companies to carry out an enterprise’s tasks, insinking was the consumption of a company’s products by the company itself. (The source in outsourcing is outside the firm, the sink or consumer in insinking is inside, get it?) Naturally, this lent itself to all sorts of mock-predictions (sample: “Competition will become cutthroat. The resulting bloodbath will leave the competitors red and sticky-looking”).

Well, what was farce now looks like reality. In particular, IBM has now created a structure where software and hardware to some extent compete for the services group’s business against other inside and outside vendors. And the result is, by and large, beneficial; the services group provides an addition to the software/hardware market, while outside competition continues to force long-run improvements in IBM software/hardware’s competitiveness.

To put it another way, as a Sloan Management Review article a while ago noted, there has been a long-run tendency, in high tech companies as elsewhere, to move from vertical integration to autonomous business functions that are more often parts of different companies. Insinking, or whatever you want to call it, says that if the function is autonomous and competitive, it may actually be better to include it in the company, as the cost advantages within the company of the in-house function lead more business for the function, which in turn leads to economies of scale, which leads to greater competitiveness outside the company.

Spoiler note: let’s not take this idea too far. The reason insinking lent itself to farce was that the logical endpoint of insinking’s logic is the consumption of all of a company’s products by the company itself. Such a company would operate at a perpetual loss. It’s a bit like saying that, because reducing taxes a little may actually increase government tax revenues in the long run, we should reduce taxes to zero.

How does this relate to HP software? Well, in the short run, probably very little. HP doesn’t have nearly enough infrastructure or app software to supply EDS’ needs. Insinking may very well be good for HP hardware; but it will, in the short run, not make much of a dent in the relative size of software revenues in HP.

In the long run, however, HP has an opportunity – if it wants to seize it. Insinking for HP software would definitely add software revenues. Since software is well-known for improving profit margins versus hardware and services, any additional software that HP acquires for its software arm will probably be worth more because of its additional sales to EDS in-house and its positive margin effect. So by focusing on growing software’s share of the business, HP would have an unusually strong and good effect on revenues and profits.

Do the Old Analysis Rules Still Apply?

I was going through some old papers the other day, and I found the presentation I used to give to newbies at Aberdeen Group on how to see past marketing hype – or, as we called it then, the Bull#*! Detector. One of the best ways, I suggested, was to “Drag Out Some Old Rules” about what would and would not succeed in the marketplace. Looking at that presentation today, I was curious as to how well those Old Rules held up, 11-12 years later.

Here are the three rules I wrote down:

Emulation rarely works. By that I meant, suppose someone came to you and said, “I have a great new platform designed to run Linux. And, if you need Windows, it emulates Windows, too; you’ll never tell the difference.” But you would be able to tell the difference: fewer Windows apps supported, slower performance, bunches of additional bugs, and slowness to adopt the latest Windows rev. And that difference, although you might not be able to articulate it, would lead the bulk of users to choose a Wintel platform for Windows over the Linux one.

I’m no longer sure that this rule will hold up; but it may. The key test case is businesses allowing employees to use Macs at work. An article in last week’s Business Week suggested that there was a big trend towards using the Mac at work, and large businesses were beginning to allow it, as long as they could run their Windows apps on those Macs. But if this rule holds up, the bulk of large businesses are never going to switch to the Mac; neither IT nor the employees will accept a solution that’s more of a pain in the neck, no matter what Microsoft does with Vista.

Open and standards means slower development of new products and less performance; proprietary means lock-in. The logic to this one was simple: if you’re going to be open, one of your main foci is adhering to standards; and standards tend to lag the technology, while preventing your programmers from fine-tuning to achieve the last ounce of performance (I don’t think anyone argues with the idea that proprietary fine-tuned products lock users into a vendor).

I don’t think this one has been disproved so much as it has become irrelevant. Most if not all software created today is mostly or all open, and in many cases not open source. And there are so many other variables going into software development and software performance today, like the effective use and reuse of components and the use of REST instead of SOAP, that the inability to fine-tune instead of using standardized code is at best a rounding error.

If it’s Wintel it’s a de-facto standard; if it’s anything else it’s not. To put it another way, Microsoft was the only vendor that had the power to produce software that was immediately broadly accepted in the market, and used as the basis for other apps (like Office, SOAP, and Windows).

I would argue that, despite appearances, this rule still holds to some extent. Sun had a big success with Java, and IBM with Eclipse; but those were not imposed on the market, but rather made available to a rapidly-growing non-Microsoft community that chose to accept them rather than other non-Microsoft alternatives. Meanwhile, despite all we might say about Vista, a massive community of programmers and lots of end users still look first to Microsoft rather than the Linux/Java/open source community for guidance and solutions.

Here’s a couple of Rules that I didn’t put down because it was politically incorrect at Aberdeen back then:

Automated speech recognition/language translation/artificial intelligence will never really take off. Despite the wonderful work being done then, and still being done, in these areas, I felt that the underlying problem to be solved was “too hard.” To put it another way, one of the great insights of computer science has been that some classes of problems are intrinsically complex, and no amount of brilliance or hard work is going to make them good enough for what the market would really like to use them for. The above three, I thought, fall into that category.

I note that periodically, Apple or IBM or someone will announce with great fanfare speech recognition capabilities in their software as a key differentiator. After a while, this marketing pitch fades into the background. Naturally Speaking has not taken over cell phones, most language translation at Web sites is not great, and there is not widespread use of robots able to reason like humans. I believe this Rule has held up just fine, and I might add “pen computing” to the list. Jury’s still out as to whether electronic books will fall in this category, although Paul Krugman is now giving Kindle an excellent review in his blog.

Network computing, under whatever guise, will always be a niche. Many folks (like, I think, Larry Ellison) still believe that a dumbed-down PC that has its tasks taken over by a central server or by the Web will crowd out those pesky PCs. My logic, then and now, is that a network computer was always going to be, price-wise, between a dumb terminal (read: a cell phone) and the PC – and products that are midways in price and not dominant in the market will inevitably get squeezed from both sides.

Now, I know that many IT shops would love to go to network computing because of the PC’s security vulnerabilities, and many Web vendors hope that most end users will eventually trust all of their apps and data to the Internet exclusively, rather than having Web and PC copies. I say, ain’t gonna happen soon. This Rule still seems to be holding up just fine.

Finally, here’s a couple of Rules I have thought up since then:

Open-sourcing a product means it never goes away, but never dominates a market. That is, open-sourcing something is an excellent defensive move; but it closes off any offensive that will take over that market. Thus, open-sourcing, say, Netscape Communicator or CA-Ingres has meant that a loyal following will keep it fresh and growing, and you’ll attract new folks like the open-source community. However, it has also meant that others now view them as not offering key differentiable technology that would be worth a look for use in new apps.

The test case for this one today is MySQL. Over the last 4 years, MySQL has probably amassed more than 10 million users, but those are mostly new users in the open-source/Linux community, not converts from big Oracle or IBM shops. Look at Oracle’s revenues from Oracle Database in the last few years, and you’ll see that open-source databases have not had the impact on revenues nor on pricing that has been expected. My Rule says that will continue to be so.

And here’s a Rule that’s for the Ages:

There’ll always be Some Rules for analysts to Drag Out to detect marketing hype. From my observation, all of us are guilty at one time or other of over-enthusiasm for a technology. But I would say that the good long-term analyst is one who can occasionally use his or her Rules to buck the common wisdom – correctly.

The Development Philosophy: Bottom Rail On Top This Time

There’s a wonderful story told (I believe) in Bruce Catton’s “Never Call Retreat” and other Civil War histories. An ex-slave with the Union armies happens upon his former master, now a prisoner of war toiling away at some task. “Hey, master,” the ex-slave says, “Bottom rail on top this time.”

I was reminded of this story when I reviewed my latest copy of Sloan Management Review. In it, there’s an excellent article by Keith McFarland about his consulting firm’s application of software-development techniques – particularly agile programming – to a company’s process of strategy formulation.

Today’s software development philosophy has in some cases moved from an inflexible “waterfall” process of developing software, often with attendant highly formalized governance, to a “spiral” process emphasizing frequent, flexible, incremental changes narrowing in on a solution, and involving both developers and “end users.” Keith’s insight has been that the same approach can be used to improve other processes, such as strategy formulation and modification. His experience has been that this approach leads to benefits to the company similar to those of agile development to the development organization: faster time-to-value, greater buy-in by users/the company as a whole, and easier, more frequent modification of strategies in response to new opportunities and challenges.

Now, all this sounds like another example of cross-fertilization from one area of the business to another, all part of the current mantra “innovation is great.” But as a long-time programmer and then observer of the business development scene, I can tell you that I can’t recall ever seeing an idea come from development to business strategy. Quite the reverse, in fact.

To put it another way, much of the history of development methodologies and philosophies is one of strained analogies with something else. There was the time in the 1970s when it was assumed that development was something vaguely like writing, and therefore anyone with a background in English or history could do it. More recently, and up to the present day, programmers were supposed to be like engineers, with a cookbook of mathematical kludges to apply to any situation (remember Computer-Aided Software Engineering?). As someone who worked with electrical engineers at my first job, I have always thought this was a pernicious misunderstanding of programming skills, leading to “software and the software process would be simple if they were just engineered properly.” And then there’s “development is like manufacturing,”, leading to Cusumano’s hailing Japanese software factories as the wave of the future and Brad Cox hoping that developers would simply build software like Lego blocks, not to mention the hope that Indian outsourcers with a set of requirements as their supply chain could handle all new-application development tasks.

It is only in the 2000s that we have finally seen some significant flow from software ideas to the rest of the business. In particular, today’s cross-project management tools (folks are realizing) are well ahead of legacy New Product Development and Product Portfolio Management software and techniques, and therefore you can do better if you’re Schlumberger by using PPM to enhance your product development tools. And companies are paying lots more attention to software development, too, because for more and more businesses, from investment banking to gaming to Google, continuing development of competitive-advantage software is key to company success.

But applying agile development to business strategy development is a step further. Agile development, remember, is one of the first “home-grown” development philosophies, done by developers with full appreciation for the drawbacks of previous analogies and aiming to leverage the very characteristics that make the developer unique: mastery of massive amounts of detail, mathematical and creative skills, usefulness of the individual and of self-generated “hacking” (in the old, good sense) as well as rapid prototyping. This is a process that first took off in software development, not anywhere else.

So the real story of this article is that maybe development is beginning to be not a millstone around management’s neck (as in, “why can’t I get the support for the business I need out of IT?”), nor a mysterious cabal within the organization, with its own language and norms, but a pattern of getting things done that can serve as an example elsewhere, or a harbinger of successful organizational practices to come. Why can’t the budgeting/planning/forecasting process be more flexible? How about the event-driven organization, ready to react semi-automatically to certain events on the outside? Could we open-source performance reviews? All right, maybe the last one was a little over the top.

Software development, done right, as a model for the organization! Bottom rail on top this time, indeed.