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.