An Example of Pattern-oriented Analysis
The analysis uses a three-step process, following the steps presented in Figure 2
- Identify the architecture pattern and the open source software products required.
- Analyze the required features of the products
- 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 highhowever 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.