pen source software is gaining increased attention and is clearly making its mark in the IT portfolio of many small and medium businesses. The increased usage of Linux, the availability of production quality Web software, and the widespread adoption of open source development tools such as Eclipse by the developer community provide an impetus for open source adoption. However, the penetration seems to be arbitrary, and is often used mainly to solve tactical problems. The adoption level is lower in larger and more traditional enterprises, because justifying and introducing new technologies typically takes longer. Coupled with this are vague but valid concerns such as quality of the software, and the availability of support.
Successfully adopting open source software for business applications requires a clear strategy, because implementation and maintenance of open source software systems differ from traditional software systems. Many enterprises still have a long way to go to clearly formulate such a strategy.
Some of the complexities are:
- Open source software is delivered in many cases in an "as-is" basis, often demanding a high level of competency to understand and use.
- The pace of software releases and upgrades does not necessarily follow the needs of the business, because business adoption of their software has a lower priority for open source creators than for commercial software vendors.
- There is no "pre sales" or "account management" role for the open source software. This means that enterprises must shoulder the increased responsibilities of handling the adoption and integrating it with the existing IT portfolio.
- Open source projects are fundamentally disparateoften developed as stand alone products. But many practical situations require an integrated suite of software. Although open source integrators are increasing, they've been missing until recently.
Addressing these concerns is the function of enterprise architecture, yet enterprise architects need new tools and techniques to analyze the suitability of open source software for specific IT ecosystems. Analyses need to cover multiple dimensions such as cost, risks, etc., but these analyses can be carried out only software is mature, and if a more critical analysis of the viability of a particular solution is possible. After all, if a solution is not viable there's no point in carrying out an advanced analysis of other factors.
You can carry out such a viability analysis using architecture patterns to arrive at a measure of the maturity of various open source software. Interested users can apply the elements of the approach presented here for their specific requirements.
Two Analysis Principles
When considered at the enterprise level, open source means many things for many people. Managers and business users may associate open source with freeware, Unix and Utilities, Java, Desktop Linux; developers may associate it with servlet engines, XML Parsers, the Eclipse IDE, or build and deployment tools; while architects, who are in a position to influence decisions, raise questions such as:
- Does it really work?
- Is it stable?
- Do I have competent people to learn and apply the new software?
- What kind of security issues do I need to address?
The disparity in how various groups see open source software is compounded by the increasing number, popularity, and availability of open source products, and the realization that these products cannot just be ignored.
Much of the confusion, I believe, stems from a tendency to examine the trees and branches while losing sight of the forestor to paraphrase in architectural termsto concentrate on the building plan while losing sight of the city plan. In many instances, when open source is discussed, the discussions either circle around a narrow band of products or APIs such as Linux, XML parsers, controller frameworks, or the features of a particular open source application server or database. The discussions rarely reach a higher levelthat is, a discussion of the class
of problems that the software will address.
To avoid this confusion and set a basis for structured analysis of the problem, I propose the following two principles.
Principle 1: Use a Software Stack Approach
As a first step, analysis of the problems and solutions should be carried out using a software stack approach, based upon these three stacks of software: Operating System software, Software Platforms, and Utilities and Applications (see Figure 1).
|Figure 1. Three Stacks of Open Source Software: The figure shows the relationship of the three primary areas of open source software: operating systems, platforms, and utilities and applications.|
In more detail, the three stacks are:
- Open source operating systems such as Linux or Free BSD. This is the foundation on which enterprises run their IT systems, and includes both desktops and servers. This stack provides the maximum value because their reach is vast.
- Open source software platforms such as the Apache Web server, Tomcat, MySQL or PostgreSQL, the openCMS content management system, development tools such as Eclipse, etc. Essentially this is an application software tier, required to create and run business applications. This stack provides the next highest benefit because the cost of software licenses is considerably lower than proprietary solutions.
- Open source applications, utilities and frameworks such as Struts, Velocity, Hibernate, etc. These are tools for building applications. This stack has the least financial impact, providing savings mainly during development. Pre-built open source applications such as ERP do not seem to have any significant impact here, although their number and use is rising.
The concerns that should be addressed for the three types of open source software are clearly different; therefore, their analysis is best carried out independently, which helps focus the analysis on the problems under consideration. After doing this, analysis of cross-cutting concernsintegration of software across the stackcan be carried out easily. This approach is optimal for for choosing the best-of-breed software in a given stack as well as for ensuring that it integrates well with software in other stacks.
Principle 2: Use Architecture Patterns
The second critical factor in deciding on open source adoption is a thorough understanding of the class of problems that a software system is expected to solve, and the availability and maturity of products in the market to address those problems. Architecturally, the solution to a class of problems is much more readily represented by patterns.
Architectural patterns are proven solutions for specific types of problems and hence can be used as a context for analyzing open source adoption. Figure 2 depicts this model.
|Figure 2. Pattern-oriented Analysis: The figure shows a pattern-oriented approach for analyzing the suitability of open source software.|
Applying both principles simultaneously helps you avoid much of the confusion involved in open source adoption, and provides a framework for carrying out a well structured analysis. In the remainder of this article, I'll illustrate these principles by carrying out an analysis of one of the key risk factorsthe maturity of the open source software platform. Analysis based on other factors can be carried out in similar manner.
For the analysis of architecture patterns, I have used IBM's e-business patterns catalogue as the base set of architecture patterns, because it's one of the most popular publicly available sets. However, the analysis technique is not limited to this set nor to the class of problems represented herein; you can use any architecture patterns specific to your needs.