thenagin The SOA Platform, Grid, Bus, Backplane, Fabric, Framework, Mesh, Matrix, Environment, and Plumbing Metaphors

All:

Then:

http://briefingsdirect.blogspot.com/2007/01/transcript-of-briefingsdirect-soa.html

Again:

Gasp! These can’t all be metaphors, can they? We all use them all the times to denote the phenomenon called SOA, and/or the various technologies, approaches, infrastructures, functions, services, tools, and components that enable SOA. I just quickly scanned the BriefingsDirect SOA Insights transcript for Friday, January 19, and extracted all of these keywords, which were tossed into the mix by Messrs. Gardner, Garone, Kobielus, McKendrick, and Ward-Dutton.

Let’s gloss over the fine distinctions among them right now….for all practical purposes, they’re synonyms in a master thesaurus that we SOA analysts--and SOA vendors/consultants/practitioners--keep in our heads and cross-substitute freely in our speech/writing in order to communicate elegantly—and not sound like brain-dead robo-geeks. They’re metaphors that, through repeated prosaic use, have acquired the illusory feel of literal descriptions. Semantically, they’re alternate keyword representations of the same concept.

Concepts are very fluid and fungible things. In my recent research, I’ve noticed that semantic search—driven by concepts, not mere keyword text strings--is the predominant commercial application of the emerging Semantic Web. Indeed, many Semantic Web vendors are primarily implementing the technology in search engines that leverage ontology-based concepts to improve search accuracy and reduce spurious hits.

However, keywords, not concepts, are what’s driving today’s commercial search industry. After all, keywords are the primary good that Google et al. are hawking. But that’s certainly going to change as semantics invade the search industry.

At lunch yesterday with the president of Pitney Bowes Group 1 Software, I was musing on the prospect of a future semantic-enabled Google selling concepts as a sort of super-premium keyword—clusters of semantically affiliated keywords—thesaurus entries hovering around taxonomy or ontology nodes. Imagine how expensive, and powerful, a Google concept will be. Imagine being able to buy the concept that represents your entire industry—e.g., “data quality software” or “location intelligence solutions”—so that any semantic search that’s anywhere in the keyword vicinity of those concepts will hit your company’s website first time every time.

How will semantic search vendors structure the user interface to enable concept-based search without obliterating the keyword-based search upon which they’ve based their entire revenue model so far? My sense is that it will be through the “search suggest” feature that both Google and Yahoo already provide (Yahoo just implemented it recently; Google’s had it for a while). In both cases, the search engine dynamically predicts the queries that users are most likely to want to see, based both on the characters that they’ve already typed into the query box, and based on the aggregate behavior of all search users. At the same time, the search engine is dynamically presenting the type-ahead completions of the likely search strings, thereby accelerating query that the user will ultimately select.

I suspect that semantic search engines will beef up this “search suggest” feature by adding algorithms that leverage formal top-down SOA Semantic Web ontologies, taxonomies, topic maps, thesauri, and other knowledge representations produced and maintained by subject matter experts (e.g., SOA industry analysts). Semantic search engines may also leverage the bottom-up ontology/taxonomies/maps/etc that emerge from wikis, social bookmarking sites, and other communities in Social Semantic Web, and/or that are extracted through text mining/analytics from the artifactual plankton (e.g., podcast transcripts) that permeates that branch of the ocean semantic.

But the podcast of January 19 wasn’t to discuss semantics, search, synonyms, metaphors, linguistics, or what have you. Rather, it was primarily about recent commercial product releases that advance SOA as a virtualization approach for cross-platform service development, execution, integration, and governance.

At the start, the call focused on TIBCO’s recent (at that time) release of its initial ActiveMatrix products, which provide a container, integration infrastructure, development tooling, and life-cycle governance framework for virtualized, cross-platform SOA and ESB (btw…”matrix” is from the Latin for “womb”). I had published a Current Analysis report on that announcement the month before, so it was still fresh in my mind at that time.

Neil Ward-Dutton began to articulate TIBCO’s ActiveMatrix SOA/ESB development and governance value prop:

“Ward-Dutton: Let’s look at it from the point of view of a development theme. What is required to help those guys get into building high-quality networks of services? There are loads of tools around to help you take existing Java code, or whatever, right-click on it, and create SOAP and WSDL bindings, and so on. But, there are other issues of quality, consistency of interface definitions, and use of schemas -- more leading-edge thinking around using policies, for example. This would involve using policies at design time, and then having those enforced in the runtime infrastructure to do things like manage security automatically and help to manage performance, availability, and so on….It seems to me that this is the angle they’re coming from, and I haven’t seen very much of that from a lot of the other players in the area.”

Steve Garone carried forward the theme of cross-platform SOA/ESB development abstraction in TIBCO ActiveMatrix:

“Garone: In my opinion, this raises that level of abstraction to eliminate a lot of the work developers have to do in terms of coding to a specific ESB or to a specific integration standard, and lets them focus on developing the code they need to make their applications work. But, I would pull back a little bit from the notion that this is purely, or at a very high percentage, a developer play. To me, this is a logical extension of what companies like TIBCO have done in the past in terms of integration and messaging. However, it does have advantages for developers who need to develop applications that use those capabilities by abstracting out some of the work that they need to do for that integration."

Joe McKendrick cited a couple of other (not-on-this-session) analysts to support TIBCO ActiveMatrix’ emphasis on the development side of SOA/ESB cross-platform virtualization, rather than on the integration (or “mediation”) side:

“McKendrick: [Anne Thomas Manes of Burton Group) doesn’t see ESB as a solution that a company should ultimately depend on or focus on as mediation. She does seem to lean toward the notion of an ESB on the development side as a platform-versus-mediation system. I've also been watching the work of Todd Biske, he is over at MometnumSI [blogger note: Biske joined the Gardner Gang in later podcasts and is now a regular; Manes was invited but hasn’t yet responded]. Todd also questions whether ESBs can take on such multiple roles in the enterprise as an application platform versus a mediation platform. He questions whether you can divide it up that way and sell it to very two distinct markets and groups of professionals within the enterprise.”

Then Dana asked me for my thoughts. As you can see in the following extract, I don’t agree with Manes’ notion that ESB, as an architectural concept, should be limited just to a development platform. I’m very much of the notion that that ESB should be viewed as the [Platform, Grid, Bus, Backplane, Fabric, Framework, Mesh, Matrix, Environment, and Plumbing] upon which [Development, Integration/Mediation, and Governance of] SOA [as a practical paradigm for maximizing reuse, sharing, and interoperability of distributed resources] must be implemented (hey….how’s that for throwing a thesaurus/topic map at the problem?....but you get my drift….this is a complex sprawling oceanic topic…you can’t manage a huge body of water by damming it up in one place….it’ll gush forth elsewhere). Here’s specifically the exchange between SOA moderator Dana and SOA modeler Jim:

“Gardner: How about you, Jim Kobielus? Do you see the role of ESB getting too watered down? Or, do you see this notion of directing logic to the ESB as a way of managing complexity amid many other parts and services, regardless of their origins, as the proper new direction and definition of ESB?

“Kobielus: First of all, this term came into use a few years back, popularized by Gartner and, of course, by Progress Software as a grand unification acronym for a lot of legacy and new and emerging integration approaches. I step back and look at ESB as simply referring to a level backplane that virtualizes the various platform dependencies. It provides an extremely flexible integration fabric that can support any number of integration messaging patterns, and so forth.

“That said, looking at what TIBCO has actually done with ActiveMatrix Service Grid, it's very much to the virtualization side of what an ESB is all about, in the sense that you can take any integration logic that you want, develop it to any language, for any container, and then run it in this virtualized service grid.

“One of the great things about the ActiveMatrix service grid is that TIBCO is saying you don’t necessarily have to write it in a particular language like Java or C++, but rather you can compose it to the JBI and Service Component Architecture (SCA) specifications. Then, through the magic of ActiveMatrix service grid, it can get compiled down to the various implementation languages. It can then get automatically deployed out to be executed in a very flexible end-to-end ESB fabric provided by TIBCO. That’s an exciting vision. I haven’t seen it demonstrated, but from what they’ve explained, it’s something that sounds like it’s exactly what enterprises are looking for.

“It’s a virtualized development environment. It’s a virtualized integration environment. And, really, it’s a virtualized policy management environment for end-to-end ESB lifecycle governance. So, yeah, it is very much an approach for overcoming and taming the server complexity of an SOA in this level backplane. It sounds like it’s the way to go. Essentially, it sounds very similar to what Sonic Software has been doing for some time. But TIBCO is notable, because they’re playing according to open standards that they have helped to catalyze -- especially the SCA specifications.”

Then we discussed other vendor approaches in the same general ballpark: webMethods with Fabric, BEA with Liquid, and so forth, and brought model-driven development, UML, BPMN, and so forth into the chat. It got back to the issue from the previous week of SOA’s complexity, and how it can be reduced or controlled or managed. Here were my fresh thoughts on the topic, responding to a remark that Neil Ward-Dutton had just made:

“Kobielus: Neil nailed it on the head here. Everybody thinks of simplicity in terms of, "Well, rather than write low-level code, people will draw high-level pictures of the actual business process, not that technical plumbing." And, voila! the infrastructure will make it happen, and will be beautiful and the business analysts will drive it.

“Neil alluded to the fact that these high-level business processes, though they can be drawn and developed in BPMN, or using flow charting and all kinds of visual tools, are still ferociously complex. Business process logic is quite complex in it’s own right, and it doesn’t simply get written by the business analyst. Rather, it gets written by teams of business and IT analysts, working hand in hand, in an iterative, painful process to iron out the kinks and then to govern or control changes, over time, to various iterations of these business processes.

“This isn’t getting any simpler. In fact, the whole SOA governance -- the development side of the governance process -- is just an ongoing committee exercise of the IT geeks and the business analyst geeks getting together regularly and fighting it out, defining and redefining these complex flow charts.”

A few minutes later, Dana transitioned to other topical topics, such as recent IBM and Microsoft financials, and also to happenings in the business intelligence (BI), master data management (MDM), and data warehousing spaces—which, being right up my Current Analysis alley—I was also poised to respond to.

Which reminds me, tomorrow (Friday, July 20, 2007) they’ll be discussing recent doings in the DBMS space—specifically, Oracle’s launch of its 11g database—and data integration—specifically, IBM’s acquisition of DataMirror. I’ve just published Current Analysis reports on both happenings. Unfortunately, I won’t be able to join the podcast tomorrow—flying back from the Pitney Bowes Group 1 Software User Conference in Boston. Good stuff—a lot of focus on location intelligence and business geographics and data quality—you’ll see these themes permeate this blog increasingly (with an SOA slant).

Anyway, re the Gardner gang tomorrow, from the pre-podcast email back-and-forth among the likely participants, it looks like they’ll have a lively discussion. Wish I could join--then again, I've already said my piece on all that--let others speak. I’ll have to check out the playback or transcript, like everybody else.

Jim