But What About Project Management, Quality Control and Technology Roadmaps?

In my last post, I made the bold assertion that the Enterprise Software Model (ESM) would be displaced by Open Source Software (OSS) solutions by the year 2015. I painted (or at least implied) a Utopian vision where all software was free, functional, bug-free, scalable, supportable and easy-to-use. Well, some of you certainly chose to disagree!

The principal point of dissension revolved around the value-add in terms of stability and consistency that ESM vendors bring to the table. ESM vendors tend to invest heavily in activities like software architecture, project management, business modeling, business analysis, life cycle management, expectation management, documentation, quality control and technology roadmaps. When well implemented, these activities do bring stability and consistency, uniform look-and-feel and a common design paradigm.

When well implemented.

The key here is that the ESM model does not guarantee any of these activities, let alone guarantee that they are well implemented. I am sure that we can all very quickly create a list of vendors and/or product releases which failed miserably in stability, consistency, uniform look-and-feel and/or a common design paradigm. This is especially true where vendors have grown their product portfolios by acquisition and adopted a “Frankenstein” approach to architecture and integration.

Conversely, OSS does not necessitate a lack of the activities which yield stability, consistency, uniformity and commonality. In fact, the best OSS efforts have rather significant project management processes guided by well-defined technology roadmaps (LINUX and Apache being perhaps the best examples). Studies are even suggestive of the fact that OSS is more stable and less “buggy” than ESM competitors, in fact, a Forrester study found that OSS is already the “hidden backbone” of IT in many European corporations.

Another point of dissension had to do with interoperability and the challenges of working with complex architectures which resist full objectification and true modularization. It is true that these are especially challenging problems many of which can only be tackled with sustained and focused efforts. I admit that OSS does fall short here, but to be fair, I only advocated the demise of the ESM, not of for-profit software all together. There will still be plenty of areas where code can be written at significant profit, and perhaps even sold under the ESM. These opportunities will exist in areas where the for-profit software can meet an unanticipated consumer need, as well as in areas where the consumer need is not yet fully understood. However the profitability window will be limited. Once these unanticipated, ill-defined or highly complicated needs are fully understood, OSS versions will be able to follow. For-profit software, and government sponsored research projects, will still be the principal engines of innovation. The risks of trail-blazing require real incentives and tangible rewards.

ESM vendors often point to the lability, fits-and-starts and fickleness of the OSS marketplace. After all, hardware architectures change, programming standards change, user expectations change, surely only a stable entity with a long-term vision and the resources to adapt to these changes is worth betting on for your enterprise software needs. Yes and no. While Oracle, Microsoft, IBM, SAP and their ilk will be around for a long time, what about Business Objects, Cognos, Golden Gate Software, Crystal Reports, BEA Systems, Data Mirror, Sunopsis, SPSS, Proclarity, Peoplesoft, Sun Systems, Siebel Systems, RETEK, Epiphany, Datallegro and so many others? All were notable ESM players in their space (Sun Systems and Datallegro being slight exceptions), touted their stability and were snatched up by a larger, richer entity. The integration of these acquirees into their acquirers is sometimes successful and oftimes a frustrating, painful, and confusing process for existing and prospective customers of the acquiree. Sometimes ESM vendors simply cease to exist (LucidEra being a recent example, Holos being an older one). Instability exists in both the ESM and the OSS marketplaces. At least with OSS the customers have complete or near-complete access to the source code and can choose whether or not to continue their investment and deployment independent of the vagaries of the ESM market.

It was also pointed out that Gartner found ESM-style license fees to only account for about 10% of total project costs (sorry, I don’t have the link to support this, although I do have this one). A frightening statistic for anyone considering a license purchase! OSS therefore does not give you a “free” project. Very true but, without knowing the details of this Gartner report, I suspect that the activities and efforts behind this 90% portion of total project costs are roughly the same activities and efforts that are required for a project based on mature FOSS. The key word here is mature. It is unfair to put up a mature ESM solution with hundreds, thousands or millions of deployments against a young OSS solution with orders of magnitude fewer installations. In such a comparison, the young OSS solution will almost always cost more to implement, just as a young ESM solution would. MySQL, however, with somewhere between 6 million and 11 million installations can easily go head-to-head in matched feature competitions with Oracle, DB2, and SQL Server. The market has even validated the economics of this comparison via the success and widespread adoption of the LAMP software bundle.

I do believe that there is one area where the OSS model is seriously lacking and the ESM provides a real value. This is the area of what I call “zero-tolerance” applications. Examples would be the software that guides missiles, lands the space shuttle or keeps ICU patients alive. These types of applications require stewardship and a responsible party. With OSS, because everyone owns the responsibility for quality checking, maintaining and improving the software, no one owns the responsibility for quality checking, maintaining and improving the software. With OSS bugs must be “shaken out in the wild”, an admittedly hidden cost of OSS in zero-tolerance applications. The ESM in contrast places responsibility squarely on the shoulders and in the pocketbooks of the vendor

So, after all of this, if you were to hand me a multi-million dollar budget and ask me to implement a mission-critical (but not zero-tolerance) application scheduled to go into production within the next 2-3 years, what would I do? Well, to be honest, I wouldn’t a priori go whole hog into OSS and I would probably deploy mostly via ESM vendors - MySQL aside, most enterprise OSS is too young. I would however do two things.

First, I would very carefully assess technical, functional and business requirements and be sure to include at least one OSS solution in each of my vendor evaluations. This pressures the ESM vendors on price and service and I just might find out that there is a mature-enough OSS solution which meets the technical, functional and business requirements.

Second, I would write a roadmap with 3, 5 and 10 year milestones laying out guiding architectural principles and sound best practices (such as loose-coupling; conceptual, logical and physical modeling; training and staffing plans; threshold criteria for adoption; among many others) to insure a smooth migration in the inevitable transition from ESM to OSS applications.