Service-Oriented Architecture (SOA) presents a challenge to software marketing people like none other in recent history. On the one hand, SOA has been the top enterprise software bandwagon to jump on for the last four years or so, but on the other hand, many vendors have struggled to tell the proper SOA story for their products in a way that leads to increased sales and happy customers. The reason SOA presents such a formidable challenge is at once both subtle and obvious. After all, SOA is architecture -- it is a set of best practices enterprises follow to organize their IT resources to meet the needs of the business. SOA, however, is not, and never will be, a set of product features. And therein lies the rub. How do you position your product as a SOA product when SOA consists of best practices, not product features?
SOA and the Tin Woodman
For both product management (what features should our products have?) and product marketing (how do we differentiate our products' value propositions in the marketplace?), the focus has always been on product features. Product management meets with customers to elicit requirements, which start with business problems they'd like the product to solve, but invariably end up with a discussion of desirable features. Product management then takes those requirements to engineering, who adds them to the product. Product marketing then takes over, figuring out how best to position the features of the product to gain the attention of prospects, differentiate their products from their competition, and then convince prospects to purchase the products.
This traditional product cycle breaks down, however, when SOA is a leading customer driver. Organizations want SOA, but they're not clear on what features they need from software to achieve their SOA goals. Product management ends up crafting a list of features (like Web Services standards support, for example) that should facilitate SOA at their customers. They feed these features into their product cycle, and eventually they end up with a "SOA product" of some sort.
This pattern is an example of what ZapThink likes to refer to as the Tin Woodman pattern. The Tin Woodman wanted a heart, so he went to the Wizard of Oz, who gave him a clock. The clock was clearly not a heart, but it had one relevant feature, namely it ticked. Compare that story to an enterprise who wanted SOA, so they went to their vendor of choice, who gave them a product with Web Services support. Web Services are clearly not SOA, but they offer standards support, the relevant feature.
The Tin Woodman pattern is virtually ubiquitous in the SOA marketplace today. For example, the term "SOA Middleware" is now gaining some currency, as an umbrella term that includes Enterprise Service Buses (ESBs), Service intermediaries, and other infrastructure software. Well, what does "SOA Middleware" really mean? Does it mean that if you buy it, you'll get SOA? That's about as likely as the Tin Woodman getting a real heart from the Wizard. Instead, what vendors mean by "SOA Middleware" is traditional middleware that offers a set of features that can potentially help their customers implement SOA. But no, you don't get SOA with your SOA Middleware.
Rethinking SOA Product Management and Product Marketing
As the SOA marketplace continues to mature, the SOA marketing paradox is developing an interesting wrinkle. Vendors continue to improve their products, adding increasingly powerful capabilities to their list of features. But as with any tool, the more powerful it is, the more dangerous it becomes in the hands of someone who doesn't fully understand how to use the tool. In other words, if the enterprise customer doesn't have the proper SOA best practices in place, then the more powerful the software they buy becomes, the less likely they'll be able to use it successfully in their SOA implementation. Adding features, therefore, can actually make the situation worse!
The solution to this paradox is actually rather obvious once you see it. For organizations to be successful with SOA, they need best practices, so vendors should give them best practices for the use of their software. In other words, vendors must understand how their product fits into SOA best practices. For example, building loosely coupled Services is a SOA best practice (or more accurately, a set of best practices) -- but it's easier said than done. It requires specific best practices related to Service contract creation and management, content based routing and transformations, SOA governance, quality, management (GQM), and more. Product marketing should therefore provide specific instructions to their customers as to how to achieve the benefits of loose coupling by leveraging their products.
This advice drives product marketing into new territory. Product marketers' comfort zones center on features and benefits, and we're recommending putting those features and benefits on the back burner, and instead focusing on creating architectural methodology artifacts that instruct customers on achieving specific SOA best practices. Most product marketers don't have the skills to create such artifacts, so they must seek assistance elsewhere, but the fact remains that best practices are not product features. Simply saying "our SOA Middleware product offers loose coupling" as though loose coupling were a feature is misleading at best, and entirely meaningless at worst. Instead, the vendor should say, "here is specific advice on what to do to achieve loose coupling, and here's how our product helps."
The Twilight of the Platform Play
ZapThink has long espoused that products cannot give you SOA, because SOA is something you do, not something you buy. Enterprises must start with SOA best practices, and let those practices drive product selection, not the other way around. Resolving the SOA marketing paradox, however, takes this argument one step further, because we're shifting the responsibility for linking best practices and software products to the vendors of those products.
For vendors with SOA-specific point solutions, like many of the GQM vendors in this space, beginning with SOA best practices and fitting their products into them is straightforward, albeit difficult. For the larger SOA platform vendors, however, this advice goes contrary to the whole notion of a SOA platform. Because these larger vendors are seeking to assemble soup-to-nuts suites of software that give their customers everything they need to implement SOA, they believe that SOA best practices must necessarily derive from their platform features, not the other way around. In other words, if you buy into a platform vendor's SOA story, you'll need to do SOA their way.
The problem is, most of the platform vendors are heading in the wrong direction. They want to be a better Wizard of Oz, so they're adding more and more features to their clocks. Now the Tin Woodman gets two alarms, a nightlight, and who knows what else with his clock -- but of course, he's no closer to getting a heart than if his clock did nothing more than tick. From the enterprise perspective, SOA best practices involve leveraging heterogeneity to provide business agility. Vendors with point SOA solutions can tell this story -- "here are best practices for leveraging heterogeneity, and here's how our products help," but the platform vendors cannot. Instead, they must say, " here are our platform's SOA features, and here's how to use them." As a result, if you look closely at the platform vendor's "SOA" case studies, you'll see that most (or all) of them are not SOA stories at all, but rather examples of how customers implemented the vendor's software.
The ZapThink Take
SOA is at a crossroads. If the platform vendors have their way, history will regard SOA as a promising architectural approach that ended up being little more than a set of software features -- what ZapThink calls "The Great SOA Boondoggle." And yet, it doesn't have to be that way. More and more enterprises are coming to understand the true nature of SOA, and for those architects that do see the light, they aren't falling for the "SOA as product features" line. Furthermore, an increasing number of vendors are seeing the light as well, and are positioning their products as helping implement SOA best practices.
The moral of The Wizard of Oz, of course, is that the Tin Woodman and his companions possessed what they desired all along. The Tin Woodman didn't need anything from the Wizard at all, and while a clock gave him the ticking, the device was neither necessary nor sufficient for having a heart. Just so with SOA. Organizations who get the architecture right don't need the vendors to give them best practices, because best practices are essentially forms of human behavior independent of the technology. Once you have those best practices, the products you purchase can help you implement them, but the products will never be the source of the best practices themselves. The Tin Woodman was happy with his clock. Are you?
Learn more at one of our upcoming Licensed ZapThink Architect Bootcamps or SOA & Cloud Governance courses.
There are a variety of applications that supp...
Subscribe to SOA World Magazine Email News Alerts
Subscribe via RSS
