Skip to content Skip to navigation

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

Printer-friendly version

Why We Pay for the Enterprise Software Model

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.

Why We Pay for the Enterprise Software Model   In my last post, I made the bold assertion that the Enterprise Software Model (ESM) would be

Pages

Comments

Marc,

I enjoyed this post very much! You certainly pulled together a lot of dimensions of how software licensing models relate to solutions. And, you concluded within extreme pragmatism. Nice touch.

Can you relate how SOA fits in to all this? Are we more likely to see great OSS on lower layers of a technology stack (the LAMP parts) and less on the higher layers (business logic) and presentation layers, as we see with, for example, Apple's OS X (currently Snow Leopard)?

Pages