This guest post comes courtesy of Ronald Schmelzer, senior analyst at Zapthink. By Ronald SchmelzerMost experienced practitioners in
Service-Oriented Architecture (SOA) and
Enterprise 
Architecture (EA), including ourselves, would assert that
architecture and implementation are not interdependent. That is to say that architecture expresses means for describing ways of doing things whereas implementations are specific ways of doing those things.
Doing any particular architecture doesn’t require using any particular implementation, and vice versa, implementing something a particular way doesn’t imply or require any specific architecture. As such,
any good architect should know that the best solutions are always context specific – give
the business, users, whomever the constituency is, the best solution based upon their needs rather than any particular assumption ahead of time.
Getting this truism out of the way, why is it then that so many IT organizations prematurely discard
Open Source Software (OSS) from their SOA implementations? While OSS may not be suitable for all implementations all the time, they are increasingly becoming suitable and feasible for an increasing number of SOA implementations.
For more information on virtualization and how it provides a foundation for Private Cloud, plan to attend the HP Cloud Virtual Conference taking place in March. To register for this event, go to:
Asia, Pacific, Japan - March 2
Europe Middle East and Africa - March 3
Americas - March 4
To make it absolutely clear, ZapThink is not advocating dumping all your vendor solutions in favor of an OSS stack; however, we believe that the current economic and technology environment are making OSS solutions more credible, feasible, cost-effective, and potent as the industry matures. In this ZapFlash, we’ll look at the current state of OSS for SOA and why this might be the right time to reevaluate your biases and assumptions about the “readiness” of OSS for SOA.
Open source, free software, and community development
First, it is important to get our definitions straight. As is very aptly defined in
Wikipedia, open source software is “computer software for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that meets the Open Source Definition or that is in the public domain. OSS licenses permit users to use, change, and improve the software, and to redistribute it in modified or unmodified forms.”
OSS differs from commercial software in that the ownership, maintenance, and rights to change the software are not owned by a specific company or group of companies.
The FSF defines Free and open source software (F/OSS or FOSS) as the freedom to copy and re-use the software, or in other words, “free as in free speech, not as in free beer”.
The term open source is frequently, although not always, used in conjunction with the idea of free software. In this terminology, free sometimes means that it costs nothing to acquire the license, but that’s not exactly how it’s defined by the
Free Software Foundation (FSF). The FSF defines
Free and open source software (F/OSS or FOSS) as the freedom to copy and re-use the software, or in other words, “free as in free speech, not as in free beer”. This means that FOSS licenses gives users the rights to copy, modify, share, redistribute, and otherwise contribute to the advancement of the technology, but doesn’t necessarily imply anything about total cost.
Muddying the waters is the idea of
Commercial Open Source Software (COSS). In COSS, the community has rights to certain aspects of modifying, sharing, and enhancing the software whereas others are reserved for the company. We’ve seen many instances of COSS in the SOA landscape in particular, from firms who wish to have a “
freemium” model or “Community Edition” products which are offered for free as an entry point, and commercially licensed and maintained products offered as a premium. So what’s the problem with OSS? Simply put, three big issues: Fear, Uncertainty, and Doubt (FUD).
OSS SOA FUDLet’s start with uncertainty. From a SOA perspective, the big uncertainty on OSS rests on two main issues: Are there a sufficient number of OSS offerings to cover the scope of things we need for our SOA implementations, and are those OSS projects of sufficient quality to meet our needs? If only companies did indeed start with this question, they would quickly find that there are an increasing number of widely implemented, tested OSS solutions for a wide range of SOA development, infrastructure, and management needs.
For certain, if you are looking for products that offer so-called
Enterprise Service Bus (ESB) functionality, then there are a
plethora of Open Source solutions. Companies have successfully implemented
Mule ESB,
Apache Axis2,
Apache Synapse and
Apache ServiceMix.
You can’t make the blanket statement that implementations based on OSS are less robust than vendor solutions.
For SOA development, there are a wide variety of OSS options, most notably the
Eclipse project. Not only has IBM’s OSS contribution of Eclipse made major inroads throughout IT development, it has spawned many associated development frameworks, such as the
Swordfish SOA framework and the
Equinox OSGi bundling framework.
Many open source projects are integrated or built on top of the Eclipse platform. There are now even open source SOA registry and management solutions including
Mule Galaxy,
SOPERA,
WSO2’s open source registry offering, and the
Membrane SOA Management tool. There are a wide range of OSS Business
Process Management (BPM) and
BPEL runtime engines including
ActiveBPEL,
Apache ODE,
Orchestra, and a
plethora of others.
As a sum total, these tools have had tens of million downloads and hundreds of thousands of implementations. Furthermore, individuals and companies have poured tens of thousands of hours of development time and maintenance into these tools.
Are these of the same quality as tools from vendors with decades of product development history? You can’t make the blanket statement that implementations based on OSS are less robust than vendor solutions.
Many open source tools build upon the experience of users who have previously used commercial offerings and thus aim to mimic or improve the functionality and performance of those solutions.
Furthermore, just how stable are those vendor tools anyways? After a decade implementing one vendor’s infrastructure suite, you find that that vendor got acquired not once, but two or even three times as their acquirers in turn got acquired, with the final product set “mish-moshed” amongst a dozen other acquisitions with no firm roadmap, an ill-defined integration plan from the vendor, and license and maintenance fees that make little sense.
In many ways, the simplicity and lack of confusion of the OSS suite is making more sense given the chaos of the product portfolios in the rapidly consolidating vendor marketplace right now.
Early vendor death and consolidation chaosThis brings us to the other two issues raised on OSS solutions: fear and doubt.
Brenda Michelson from Elemental Links did a very good job outlining some of the considerations for open source in the enterprise IT environment.
Many architects refuse to even consider OSS solutions out of the often unfounded fear that they are unsupported. While it is true that many good OSS solutions require paid support to achieve the response time and care necessary, we would argue that money is well spent.
With commercial companies providing support for OSS offerings you get the best of both worlds: community development, testing, and enhancement at low or no cost, and professional support whose time and value are known quantities.
Even if you chose a commercial vendor, you’re going to be paying for support anyways. In what respect are OSS solutions any worse off in this case? It is ludicrous to assert that a vendor’s solutions are of such a high quality that the need for support is less than that of OSS solutions.
In fact, we find the contrary. When you purchase commercial vendor offerings, you pay for the licenses, maintenance, and support, in addition to your integration costs, and you don’t even get the benefit of getting others’ contributions.
When you purchase commercial vendor offerings, you pay for the licenses, maintenance, and support, in addition to your integration costs, and you don’t even get the benefit of getting others’ contributions.
Much of the doubt on OSS is placed by vendors who have vested interests in making sure you continue to feed them millions of dollars of license and maintenance revenue. But given that many enterprise IT vendors are folding, getting acquired, or abandoning their product lines, we see a greater risk in towing a strictly commercial vendor line.
Without the source code and enhancements in the community, when a vendor gives up the ghost, stops developing their product, or gets “mish-moshed”, the code simply disappears. No one is there to support a dead company’s products or a dying product line.
In this regard, OSS presents less of a risk because the code is out there in the community, available for anyone to pick up. From a SOA perspective, you want to have as few dependencies as possible on your infrastructure or a single vendor’s solutions. As such, for many, OSS makes a whole lot of sense.
An OSS and SOA case study (courtesy of the SOA-C)Recently, the
SOA Consortium (SOA-C) had a case study contest to elicit the best SOA implementations and architecture design.
One of the winners was BlueStar Energy, which implemented a relatively sizable SOA implementation entirely on OSS solutions.
Some of the lessons they learned were some of the things we often espouse: incremental delivery, standards-based interface, consumer heterogeneity, loose coupling, and, composability. If you read the case study, you can see that the design principles had a decidedly non-vendor bias. They wanted control over their environment, and this meant creating a specification that required implementation neutrality.
The consequence of the way that BlueStar designed their architecture is that they found that OSS solutions best fit the bill for their needs. Their Business Integration Suite consists of open source distributed, scalable and reliable components such as enterprise service bus, business process management system and messaging fabric.
The end result is that between the adoption of SOA, open source and offshore development, the company estimates saving $24 million over the course of five years. For many of our readers, the BlueStar case study probably describes your environment as well. The case study is worthy of a close read!
ZapThink takeWe at ZapThink have no vested interest in espousing a particular position that OSS or commercial vendor offerings are inherently better than the other. As mentioned, all good architects need to consider the context for their implementations.
For some companies, a vendor approach is best (especially in mainframe-based legacy environments where OSS simply doesn’t exist). But for others, we believe that biases dominate the discussion. Enterprise architecture does not demand vendor solutions. You can choose to implement aspects of your EA entirely on your own. Or you can buy technology from a handful of vendors. Or you can grab open source solutions online. There’s no bias in the architecture – why do you have bias and why is there bias in the marketplace?
The best place to start is where BlueStar Energy started: focus on the goals and needs of the architecture first. Define your architecture in a vendor-neutral, implementation agnostic way. Then, when it does come time to consider your implementation, start with a gap analysis.
Which tools do you already have that suit the need that you don’t need to buy again? Which infrastructure and tools do you need to acquire to fill the gaps? For those gap fillers, consider OSS and vendor solutions equally and evaluate them on an equal footing. You might be surprised to find what truly fits the bill for your SOA implementation needs.
Check your FUD at the door. Make sure you aren’t losing an advantage by prematurely eliminating OSS from your SOA infrastructure mix.
This guest post comes courtesy of Ronald Schmelzer, senior analyst at Zapthink.
SOA and EA Training, Certification,
and Networking EventsIn need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.
Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.
You may also be interested in:
