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 disparate?often 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 forest?or to paraphrase in architectural terms?to 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 level?that 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 concerns?integration of software across the stack?can 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 factors?the 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.

An Example of Pattern-oriented Analysis
The analysis uses a three-step process, following the steps presented in Figure 2.

1. Identify the architecture pattern and the open source software products required.
2. Analyze the required features of the products
3. Aggregate the results for the architecture pattern.

This process provides a holistic approach for analysis of open source software intended to solve a specific business problem, rather than adopting open source in isolation.

Step 1: Identify Architecture Patterns and Products
Architecture patterns represent abstractions of real world, successful implementations of solutions. Realizing these solutions requires infrastructure (software and hardware), development processes, and tools. Because hardware is not an open source product I’ve left it out of the discussion. In addition, because development processes are mainly local to an IT environment, I’ve excluded them from the discussion as well, leaving only software as a concern.

The first two columns in Table 1 list the patterns from IBM’s e-business catalogue. To the list I have added a comprehensive but not exhaustive list of possible software. Based on your specific requirements you can add or remove software from the list. The patterns in Table 1 are intended as fast-track solution accelerators. Typically, business problems will need a combination of some or all of the patterns.

Step 2: Analyze Individual Products
To see how these patterns can be achieved with open source software requires considerable effort, because the onus of selecting and implementing the software lies entirely with the user organizations. Fortunately, that situation is changing, because many vendors have started providing support for open source software. Nevertheless, serious due diligence is needed because business problems usually require multiple architecture patterns or a combination of multiple software products.

One key factor in this analysis is to assess the viability (the combination of availability and maturity of the software) of the software products.

Among the analysis parameters you can use for this are:

• The number of years that the products have been available
• The number of production-level implementations of solutions using the software
• The activity of the open source group
• The availability of services and support (paid or otherwise)
• The awareness within the developer community. This is rated using the number of downloads registered at the respective Web sites.

You should treat these results as representative and indicative, and not necessarily conclusive, because these results are intended only as the first step in an analysis for specific requirements. The ratings are course and generalized; for example, a “High” rating indicates that the product is mature while “Low” means that it is still in its infancy. A low rating need not indicate poor product quality. Note that other analysis parameters such scalability or performance are not included with the product maturity rating; those parameters can be analyzed easily after zeroing in on a product based on the required architecture pattern. Table 2 shows a representative list of software types, implementations, and a High/Medium/Low maturity and usage rating.

Aggregating the results at the level of type product, Table 3 summarizes the results.

In summary, the overall results of this analysis show that:

• Web, Application, Security, Content management and Mail server products are mature.
• Collaboration, Database, Reporting, Portal and Search engine products are very much available for production environments, but their adoption level is low compared to the more mature products. Nevertheless, it’s worth considering a controlled adoption of these in the enterprise. Of these, the adoption of open source database server products for mission critical business data is not likely to be very high?however they’re increasingly being embedded into products from other vendors and are good candidates for handling support/temporary data.

• Workflow, OLAP, ETL and Integration software have a low maturity rating, which may stem from the fact that the domain itself is of low importance; that open source implementations in these domains (such as ETL, EAI, and OLAP) are fairly recent, and hence product adoption rates are low; or that the number of players in a given arena (for example, in workflow software) reduces the overall adoption level for any individual product.

Step 3: Analyze Results at the Architecture Pattern Level
Finally, Table 4 shows the results of aggregation at the level of architecture patterns.

From Table 4, you can see that, for example, the possibility of successfully implementing the Self Service pattern and related Access Integration pattern using available open source products is quite high, and carries a low risk of the products or technology becoming obsolete in the near future. Most of the patterns require the non-functional and runtime patterns as well for implementation. For example, for high availability you need load balancing and clustering software, which are implemented in ways such as:

• Clustering software provided by the app server provider
• OS-level clustering to take care of OS failures
• Hot standby or SAN infrastructure for databases

Note that basic implementations of open source software do not always address this problem. Even though solutions are often available as a premium extension to the open source software, you may need to subscribe to the premium version of the software or obtain such software from third-party traditional software vendors. The decision depends on the nature of the IT ecosystem; for example, if you already use load balancing software you probably won’t need a different one.

Though open source frameworks and pre-built utilities are not discussed here, it’s generally accepted that frameworks such as Struts, Hibernate, etc., are suitably mature for use in a mission-critical environment. Thus, implementing the self service pattern using open source at all three levels shown in Figure 1 is very much possible today without taking undue risks.

The patterns of Collaboration, Extended Enterprise, Electronic Commerce, E-Market place, and Portals each have open source products that are widely used, but at adoption levels less than that of the Self Service pattern. This does not mean that they are poor candidates for enterprises. Rather, their usage can and should be adopted in a controlled manner, keeping local requirements in mind. In these cases, you may need to use proprietary software along with open source software. For example, to achieve the Electronic Commerce pattern you would need to integrate various other systems such as inventory, order management, shipping, etc, which requires robust application integration capabilities, including message transformation and routing. Open source implementations for these have not yet reached a high level of maturity; therefore you might need to use proprietary integration software to completely implement the pattern.

Finally, Table 4 shows that open source products for achieving the Application Integration, Information Aggregation, and Account Access patterns are not yet suitable. In particular, Account Access requires both Integration and Information aggregation in addition to Metadata management.

It is obvious that in reality a business problem solution may require more than one pattern and hence that it may require multiple open source products. This adds to the user burden; absent an open source integrator, the challenges of integrating the various products, doing upgrades and making sure that the risks of obsolescence in under check need to be addressed by the enterprise. As part of an open source adoption strategy, the enterprise might create an open source competency center, which addresses various integration challenges and tracks emerging market trends. Alternatively the competency center may delegate the challenge of integrating various open source products and support for the product to vendors who offer these services. Support for individual products at a nominal yearly subscription is also available from numerous vendors, which considerably reduces the maintenance risk, although it slightly increases the complexity because of the need to manage multiple vendors. With this model, enterprises can realize almost all e-business patterns except Application Integration, Account Access, and Information Aggregation.

In this article you’ve seen how to use architecture patterns effectively to clear up some of the confusion surrounding open source enterprise adoption. Implementing open source software is fundamentally more complex than traditional software, because it transfers the burden of integration and maintenance to the enterprise. Analyzing the problem using a pattern-oriented approach can provide a strategic direction and a clear vision of the types of problems open source can address. The results in this article are indicative only, but you can adopt this approach to do more specific analysis given your specific requirements. The increasing availability of vendors who support a large number of open source software is quite reassuring, because it means that open source can reach beyond the already large numbers of stand-alone and technical applications to mainstream business applications.