There’s a battle brewing in the Cloud Computing marketplace analogous to the SOA platform war fought over the last few years. Just as platform vendors like IBM and Oracle sought to co-opt the SOA story to sell more middleware, leading to customer disillusionment and the “SOA is dead” meme, the battle today is over Platform-as-a-Service (PaaS) offerings. PaaS is essentially the delivery of a computing platform and/or solution stack as a service. “We make our money on traditional systems integration,” say the platform vendors, “so let’s move traditional systems integration to the cloud!” After all, you’d think with all the hullabaloo surrounding Cloud Computing, that platform vendors would be jumping into this new area of opportunity with two feet. And in spite of Larry Ellison’s initial resistance, it does seem that the platform players are all over this market. If there’s an opportunity to sell new stuff to their existing enterprise client base, what’s not for a platform vendor to love?

The reality, as so often happens, is far more complex. The platform vendors are running scared. They were caught by surprise by the SOA debacle, and now they see the same writing on the Cloud Computing wall. As their customers started figuring out that SOA success didn’t depend on buying new software after all, but rather was a better way to organize existing IT assets, now Cloud Computing may replace the need to own those assets altogether. Imagine a world where enterprises no longer purchase software at all! Why bother, when they can rent it on the Cloud, pay as they go, and never have to worry about maintaining or upgrading the big packages that have kept the vendors’ stock prices up for so long?

So, how are the platform vendors dealing with this threat? Basically, by trying to turn lemons into lemonade. There are two primary ways these software companies can leverage Cloud Computing to their advantage. First, they can provide software to the Cloud providers themselves. There’s definitely money to be made there, but once the dust settles, there will only be so many Cloud providers in the world, and thus that addressable market is limited. The big opportunity for the big vendors is in PaaS. If the middleware vendors become Cloud providers themselves, where they are offering “middleware for rent” in the Cloud, then they will have turned the Cloud risk to their advantage.

At least, that’s what they are thinking. Unfortunately for these vendors, the PaaS strategy is inherently flawed, in a surprising parallel to the “software-first SOA” debacle of a few years ago. Fortunately, just as we did last time, ZapThink is here to raise the alarm. Here, then, is why you should be very careful when you consider PaaS, because placing a bet on this dead-end market could be a very bad mistake.

Learning the Important Lessons of SOA

Hopefully, enterprise practitioners who were either burned by the ESB-first SOA fiasco, or who were smart enough to dodge that bullet and tackle architecture first for that matter, will avoid this mistake this time. Compounding this challenge, however, is the lure of Cloud Computing. Since the essence of the Cloud is virtualizing IT resources, don’t we get the business agility benefits of complex systems engineering automatically by moving to PaaS? Unfortunately, the answer is a resounding NO.

ZapThink has been following what’s now called PaaS since we worked with Grand Central Communications several years ago. In many ways, their “integration as a Service” offering was ahead of its time. But in other ways, there are flaws with this model that are well worth examining. If you take a “connecting things,” traditional systems approach to enterprise IT and extend it to the Cloud, you end up connecting things via Cloud-based capabilities, which we are now calling PaaS. What you end up with, however, is still a traditional system, which means that it won’t exhibit business agility. You may have shifted some capital expense to operational expense, and you may be able to take advantage of the economic benefits of dynamic provisioning, but don’t expect PaaS to help you respond to shifting, unpredictable business demands.

To achieve such business agility, SOA turns integration on its head. Instead of hooking up our infrastructure ahead of time, we’re building Services that are ready to be integrated. Essentially, the business need not know or care where the Service implementations are physically located. What matters is that they are discoverable, consumable, and composable. As a result, Services and their underlying implementations are component systems of the complex system that is the overall SOA implementation.

From the technology perspective, there are two key enablers of this “ready to be integrated” agile characteristic of Services. First, there’s the intermediary pattern that ZapThink has often discussed, offering routing and transformation capabilities that support the business Service abstraction. However, the intermediary pattern is not the whole story, as traditional middleware can also perform routing and transformation operations, and furthermore, there are plenty of examples of successful SOA implementations that have leveraged middleware for just such purposes. So what’s so special about the no-platform SOA approach?

In a properly architected SOA implementation, routing and transformation operations are performed as a matter of policy. Those policies are represented as metadata, and the governance infrastructure, in turn, manages those metadata. By coordinating the behavior of intermediaries via the governance tooling, we’re able to establish the loosely coupled links between systems that are so critical to implementing the complex system made up of those systems.

And that point brings us to the second technology lynchpin behind agile Services: metadata-driven Service discovery and automated governance. In the traditional systems view of SOA, middleware is the technology lynchpin of the architecture, while in the complex systems view of SOA, the governance tooling, centered on the registry/repository, is at the center. Which in turn brings us to the missing part of the PaaS story: the virtualization of automated governance in the Cloud.

Governance in the Cloud

As we’ve pointed out before, Cloud governance is one of the primary challenges of Cloud Computing, and security in particular is a deal-killer for Cloud Computing. Clearly, it is essential to govern Cloud-based resources, but that’s not the point we’re trying to make here. The larger Cloud governance story is Governance-as-a-Service, or GaaS. Instead of focusing on governance of the Cloud, GaaS focuses on governance in the Cloud.

Today’s GaaS discussions center on policy management in the Cloud (”rent a registry/repository”) or more commonly, policy enforcement in the Cloud (”rent a virtual XML appliance”). Such discussions, however, only characterize the state of the market today, but do not indicate the important role GaaS should play in the future. Essentially, the next step in the maturation of SOA requires the virtualization of this governance infrastructure. If we can move not only security-related policy management and enforcement to GaaS in the Cloud, but also abstraction-related governance, we’ve taken a bold leap toward full location independence.

In essence, taking a traditional systems “connecting things” approach to integration leads to the PaaS vision, but not to business agility. To achieve business agility, the “building composable Services” complex systems approach leads to GaaS, not to PaaS. As Cloud architectures mature, we won’t require a “platform” at all, either within the organization or in the Cloud. Instead, we’ll require metadata-driven governance on virtualized, location independent Cloud infrastructure. Just as platform-first SOA led to “SOA is dead” discussions, PaaS-first Cloud may very well lead to a “Cloud is dead” meme. Get the architecture right, however, and Cloud Computing will mature — but governance players, not platform players, will be the winning vendors in the end.

The ZapThink Take

The PaaS vendors, of course, are likely to fight this trend tooth and nail, because it means that enterprises will not only need less middleware, but they will have a diminishing need for PaaS as well. It’s still unclear which vendors will stand to benefit the most from this trend. The two leading SOA governance tooling vendors, HP and Software AG, may be too invested in selling software to work though all the implications of GaaS, but it’s their opportunity to lose. Vendors like Layer 7 Technologies and Vordel are leading GaaS discussions today, but these XML appliance vendors are perhaps focused entirely on security, which is a great strategy in the short term, as the demand for Cloud security is clearly poised to explode, but they may be too busy with security to think about the big picture of GaaS.

The bottom line, therefore, is that it’s anybody’s game at this point. Are you a startup in the Cloud space struggling to find the right PaaS niche? Perhaps betting against PaaS in favor of GaaS is the right play. Drop ZapThink a line and we’ll help you lead the way.

Download A Perspective on Emerging Industry SOA Best Practices (Executive Version)

Service-Oriented Architecture (SOA) practices are intended to create an agile, integrated information technology (IT) infrastructure that is scalable, reliable, and can rapidly respond to an organization’s changing needs by employing loosely coupled and dynamic services. An SOA approach enables business needs to drive an organization’s strategic IT decisions. As a result, SOA allows a business to become more efficient in meeting its current business needs and more agile in meeting future (and possibly unknown) business needs. It is important to note, however, that an SOA is neither a panacea nor something that can be purchased. There are challenges with employing SOA techniques effectively, some of which are explored in this paper.

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. 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 “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 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 FUD

Let’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.

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 Chaos

This 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.

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 “mishmoshed”, 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 (5) 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 Take

We 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.

The current version of the LZA course manual starting in February 2010. We expect to use this version for the next several months.

All LZAs as well as students in current LZA Boot Camps are entitled to download this file. Are you an LZA from a previous course and need access? Please email us at info@zapthink.com and we’ll upgrade your account.

You need to be a Licensed ZapThink Architect to Access this Document. Sign up today!

For all Licensed ZapThink Architects who took the LZA course before February 1, 2010. This online course renews your LZA credential for either one year after you complete the course, or one year after your credential expires, whichever is later. So don’t wait! Feel free to renew your credential even if it expires later in 2010.

To renew your credential, click here and register. Cost is $495. Group discounts are available, please email us at info@zapthink.com for more information.

Ever since ZapThink published our Business Agility as an Emergent Property of SOA ZapFlash, we’ve been explaining in our Licensed ZapThink Architect course how SOA implementations must be complex systems in order to deliver on emergent properties like business agility. Yet, even though we’ve expanded our treatment of Complex Systems Engineering (CSE) in the latest version of the course, the reaction of most of our students is typically one of perplexity.

Not that we’re really surprised, however. Breaking away from the Traditional Systems Engineering (TSE) way of thinking is a huge leap for most technologists, as it shakes to the foundation how they think about architecture, not just SOA in particular, but even more fundamentally, the role IT plays in the enterprise.

Complex Systems: Order from Chaos in Nature
Complex systems theory is especially fascinating because it describes how many natural phenomena occur. Whenever there is an emergent property in nature — that is, a property of a system as a whole that the elements of the system do not exhibit — then that system is a complex system. Everything from the human mind to the motion of galaxies are emergent properties of their respective systems. Fair enough, but those are all natural complex systems, and we’re charged with implenting an artificial, human-made complex system. How we take the lessons from nature and apply them in the IT shop is a question that engenders the perplexity we see on our students’ faces.

There is a fundamental flaw in this distinction, however. Making such a distinction between natural and artificial systems is basically a TSE way of thinking because it separates people from their tools. In a traditional IT system, people are the “users,” but not inherently part of the system. In many complex systems, however, people aren’t just part of the system, they are the system.

In fact, any large group of people behaves as a complex system. For example, take a stadium full of people doing the wave. Each individual in the crowd decides whether or not to participate based upon the behavior of other people, but the wave itself has “a mind of its own” — in other words, the wave behavior is an emergent property of the crowd. Another example would be a traffic jam. An accident in opposing traffic will slow down your side of the freeway every time, even though each individual knows that slowing down to look will cause a jam. You and hundreds of people like you can decide not to slow down to look in order to avoid creating a jam, but the jam forms nevertheless.

In the wave example, no technology of any kind takes a role, while in the traffic example, vehicles affect the behavior of the system to a certain extent. In fact, changing the technology can have a dramatic impact on the behavior of the system: if the traffic consisted of trains instead of automobiles, your train might not slow down at all for a problem on a neighboring track. But regardless of whether it’s made up of trains or automobiles, the system includes individual people making individual decisions based upon their personal point of view within the system, and emergent properties result, just as they do in a natural system with no people involved at all.

The Enterprise as a Complex System
Any human organization is, in fact, a complex system, including those unwieldy beasts we refer to as enterprises. Enterprises all have policies and managers and lines of control, but the overall behavior of the enterprise emerges from the individual behaviors of the participants in it. Furthermore, the emergent behaviors of corporations and governments may depend entirely on the people who belong to such enterprises, independent of technology. But when we do include technology in our enterprises, we can dramatically affect the emergent behavior of those systems, just as switching from cars to trains changes how traffic behaves.

So, what do you get when you take traffic and subtract the people? A parking lot! Without the people, what was a complex system is now little more than a collection of individual, traditional systems, namely the cars themselves. Each auto is a traditional system in the sense that the properties it exhibits are the properties its manufacturer designed into it. The best you can expect with TSE, after all, is to deliver a system that does what it’s supposed to do.

Too often in the enterprise, people confuse complex systems with collections of traditional systems, which is just as big a mistake as confusing a parking lot full of empty cars with a traffic jam. In fact, architects are often the first to make this mistake. Of course, it’s certainly true that some architects are too focused on the technology, leaving people out of the equation altogether, but even for those architects who include people in the architecture, they often do so from a TSE perspective rather than a CSE approach. But no matter how hard you try, designing better steering wheels and leather seats and the like won’t prevent traffic jams!

Complex Systems Thinking and SOA
In traditional systems thinking, then, we have systems and users of those systems, where the users have requirements for the systems. If the systems meet those requirements then everybody’s happy. In complex systems thinking, we have systems made up of technology and people, where the people make decisions and perform actions based upon their own individual circumstances. They interact with the technology in their environments as appropriate, and the technology responds to those interactions based upon the requirements for the complex system as a whole. In many cases, the technology provides a feedback loop that helps the people achieve their individual requirements, just as brake lights in a traffic jam help reduce the chance of collisions.

Such complex systems thinking has been a common theme in many of ZapThink’s articles for several years now. Here are some examples:

• In Best Effort SOA and the SOA Quality Star, we discuss how the business agility requirement complicates the SOA quality challenge. Because agility is an emergent property, we have to establish continuous quality policies that ensure that the delivered system is sufficiently agile. As a result, there’s always a tradeoff between agility and quality we call “Best Effort SOA.”

• In The Buckaroo Banzai Effect: Location Independence, Service-Oriented Architecture, and the Cloud, we explore the “Next Big Thing” as SOA, Cloud Computing, Web 2.0, and mobile presence converge. Our conclusion? “The Next Big Thing isn’t a cloud in the sense of abstracted data centers full of technology; it’s a cloud of people, communicating, creating, and conducting business, where the technology is hidden in the mist.”

• In Resilience: The Missing Word in the SOA Conversation, we discuss how SOA implementations must be resilient, that is, they must have self-righting tendencies that help them recover from adverse forces in their environment. Resilience is a property of the component systems in a SOA implementation that allows the overall system to exhibit the emergent property of business agility.

• Finally, in the more recent The Christmas Day Bomber, Moore’s Law, and Enterprise IT, we introduce the concept of a “metapolicy feedback loop” that explicitly describes the relationship between humans tackling governance in the enterprise and the governance technology they leverage for the task. Only by taking a complex systems approach to the problem of governance do organizations have any chance of dealing with the explosion in the quantity and complexity of information in the enterprise over time.

The common elements to all of these arguments are the feedback loops between people and technology at the component level that enables the overall system to continue to meet requirements as those requirements change — the essence of business agility.

The ZapThink Take
If you still find yourself perplexed by this whole complex systems story, it might help to point out that complex systems aren’t necessarily complicated. In fact, in a fundamental way they are really quite simple. Traffic jams may be difficult to understand, but individuals driving cars are not. Best practices like Metadata-driven governance, the Business Service abstraction, and infrastructure and implementation variability, to name a few, are well within reach of today’s SOA initiatives. And the great thing about complex systems is that if you take care of the nuts and bolts, the big picture ends up taking care of itself.

For organizations who don’t take a complex systems approach to SOA, however, the risks are enormous. As traditional systems scale, they become less agile. Ask any architect who’s attempted to hardwire several disparate pieces of middleware together in a large enterprise — yes, maybe you can get such a rat’s nest to work, but it will be expensive and inflexible. If you want to scale your SOA implementation so that it continues to deliver business agility even on the enterprise scale, then the complex systems approach is absolutely essential.

“On most SOA implementations, no one piece of middleware is in control,” said Jason Bloomberg, managing partner at ZapThink, LLC. “As a result AmberPoint has these agents distributed throughout the network, which is a key point of their technology.”

Jason Bloomberg, managing partner with Zapthink LLC said that AmberPoint’s software’s ability to monitor distributed business transactions was likely a key in Oracle’s decision to buy.

“That’s always been a strength of AmberPoint technology,” said Jason Bloomberg, managing partner with Zapthink LLC. “With distributed agents they can monitor transactions that touch multiple pieces of middleware.”

Read more at http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1380941,00.html?track=NL-110&ad=743388&asrc=EM_NLN_10847068&uid=1097634