Thursday, July 19, 2007

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




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.


Monday, July 16, 2007

thenagin The SOA Shrink-Wrapping Metaphor




This was Friday, January 12 of this year….my second appearance on Dana’s roundtable podcast.

At first, I found it an odd juxtaposition of discussion topics, but in retrospect I consider it quite a lovely couplet:

  • “The first is the business opportunity for vendors around SOA. How will Wall Street, the City of London, other markets, and investor organizations view SOA as a growth opportunity, and what sort of companies will benefit?”
  • “Our second topic is going to be around the recent announcement at Macworld -- and we’re talking about the week of January 8, 2007 -- by Steve Jobs and Apple Inc. of the iPhone, and what this might mean for a mobile front-end: Is it just for consumers? Is there an enterprise aspect to iPhone? And what might be some implications for SOA and composite applications?”

What I love about it is that the first question attempted to nail the relevance of something highly abstract—the SOA paradigm—whereas the second went straight to something very tangible and concrete—which, as we’ve seen, recently occasioned a hula-hoop popular hysteria that played out across all media. Also, what I love about it is that SOA is such an oceanic concept that Dana could easily anchor iPhone—and, if he wished, all kinds of incongruous stuff—to its continental shelf.

On the first question, Dana went first to panelist Trip Chowdhry, an equities analyst, who argued that SOA software suite vendors are unnecessarily complicating their packaging, productization, and go-to-market messages—the phrase he used was “trying to solve complexity with complexity”—with the unfortunate result that “CIOs are now struggling to understand.”

By the time Dana eventually swung over to me, we’d all agreed that SOA is still far too abstract and complex for a Wall Street elevator pitch. And we agreed that both the vendors and the users are still too fuzzy on SOA’s bottom line. I like what Steve Garone had to say (he came right before me): “It’s not clear that either the end users or the providers of technology are able to clearly articulate either of them or have them interoperate -- so to speak -- have them mesh into a coherent vision of what SOA actually is and what it can deliver.”

I know that I myself struggle all the time to explain SOA’s commercial potential in the fewest possible words without dumbing it down. Here is how I hacked away at it when Dana posed the issue to me that January morn:

Gardner: You would think that a global vendor like SAP would be also enjoying some growth. So, it’s too soon to tell if there is a longer-term trend here. Let’s go over to Jim Kobielus. Jim, do you think that complexity is bad for vendors, good for SIs, and can you think of any types of vendor that might be able to go to Wall Street and say, ‘We’re going to be worth twice as much in two years because of SOA?’

Kobielus: I’ve joked for many years with people that the more change you have, the more complexity you have, and the more need you have for consultants to come in and explain it all. So, there’s always going to be an opportunity for consultants and analysts to explain what things like SOA are and are not, and what their relevance is to the average business user.

”In terms of whether complexity is bad for vendors or good for vendors, and so forth, let’s take a step back here. In terms of the business opportunities in SOA or that SOA creates, first of all remember that SOA is just an architectural abstraction. How do you shrink wrap and make sexy something that’s just a three letter acronym?

”In terms of differentiating your value prop as a vendor in this market, one of the problem with SOA is that SOA essentially has an architectural approach, smashing and dissolving the ability for vendor lock-in, because everybody is implementing common standards with any-to-any interoperability. So, these SOA universes are getting so multi-vendor and heterogeneous, the complexity can be overwhelming.

”In many ways, the number-one opportunity that SOA presents for vendors are for those vendors that can reduce the complexity by providing SOA suites of software and other components, and secondarily those vendors, those service providers, who can provide SOA and integration best practices to enterprise customers.

”So, how do you shrink-wrap SOA? Well, these suites -- from the likes of SAP/NetWeaver, Oracle, IBM, Microsoft, etc. -- implement all the piece-parts of SOA, the portals, the app servers, the databases, and the UDDI registries. Next, the Accentures of the world provide the warm bodies and warm brains of professional services to crunch this complexity down into greater simplicity, and deliver end-to-end integrated solutions that leverage the largesse that an SOA universe provides.”

Oops…I forgot to explicitly close the loop by echoing-then-answering Dana’s question before he sequed to Joe McKendrick…I almost got there…thenagin…’s me now doing so:

“Kobielus [july 16 2007]: To answer your question, Dana, the companies that are going to be worth twice as much in two years because of SOA are those that succeed in shrink-wrapping the SOA abstraction through a) comprehensive SOA-enabling software suites, b) prebuilt applications, business rules, data models, integration patterns, etc . that encapsulate horizontal and vertical business processes/content and deep domain expertise, and leverage the underlying SOA suites, and c) the professional services firms that possess the deep domain expertise, have tight relationships with customers, and with SOA suite/tool vendors, so that they can drive the development prebuilt models and apps that deliver on SOA’s promise?”

Yeah…nothing like 20-20 hindsight…or the wisdom of the “I shoulda said that” post-session hallway walk. Also, that’s still far too wordy….I gotta work harder on my SOA elevator pitch.

Or course, selling something as tangible as the iPhone is a snap…especially for a marketing/zeitgeist wizard like Steve Jobs. For him, this yet-to-be-delivered gadget was just a magic wand that he waved brilliantly over our slumbering New Year brains….and look what Jobs hath wrought. In the first weeks of January, the never-seen-or-held iPhone was just as much of an abstraction as SOA—just images on a big screen projected behind him at a tech conference—and thence throughout the planet—and suddenly it became excruciatingly fetishistically tangible in the minds of everybody who worships and perhaps fondles their iPods.

And now it’s quite real. Quite shrink-wrapped. And its elevator pitch is simply the product name itself—a mantra—an abstract, concocted word that functions like concrete poetry--states nothing, implies everything, sketches the object it embodies.

Which reminds me. This triple-haiku from me from several years ago (2002-2003?):



Big bold and sweeping

statements about the weather

sustain our careers.

Overstuffed inbox

ponderings on the latest

shrink-wrapped abstractions.

Disembodied voices

powerpointing plans for

soft world domination.


No, in the Jan 12 2007 podcast I wasn’t able to tease out any SOA-relevance surrounding this futures topic called iPhone on that particular morning. Or now, for that matter. I like to keep mobile/client-side discussions out of the SOA sphere, which I see as more of a development and integration topic than an access/distribution/delivery topic. SOA is so amoebic it gives me dysentery at times, trying to digest its many….[gross metaphor extension stamped out just in the nick of time]….But you might be interested in knowing how Dana rephrased the iPhone issue when it came to me, and how I responded:

Gardner: Jim Kobielus, do you see this as taking a step toward that notion of a mobile device that’s closer to a PC but does voice and other things that the enterprise could make good use of?

Kobielus: Oh yeah, for sure. But I don’t see anything terribly revolutionary in the iPhone, other than the fact that it comes from the Steve Jobs godhead. There’s no doubt that Apple does great design, does a great marketing, and does a great zeitgeist. They made a splash with the Newton and look what happened there. What in the iPhone is not already being used in corporate environments in a major way? People are carrying their iPods into the office and using them to listen to podcasts, or using their cell phones. They’ve already got mobile messaging and mobile browsers in a variety of devices that they’re using.

Gardner: They use iPods as a mobile storage device, too.

Kobielus: It's a nice design. I don’t want to sound to flip and cynical about it, but it's one of those things where Apple does a very good job, just like Microsoft does, of getting the average person on the street aware of the fact that we are reaching some sort of a tipping point in terms of putting these things in the hands of the average individual and the average office worker. Quite frankly, I’d like to wait another six to 12 months to see if this gets any traction in the enterprise arena. It probably will, but I don’t think there is anything strongly differentiating this particular client device.”

Then again, there’s never been anything strongly differentiating Coke from Pepsi. Except their relative mind and market shares. That all counts for something, I suppose.


Saturday, July 14, 2007

thenagin The SOA Fungus Metaphor




It’s (sometimes, often, not always) nice to have an exact transcript of my words on a particular occasion. And also good to have the precise words of whoever came immediately before me, and who set me up. Because in retrospect we all tend (or maybe just I tend) to maintain a self-centric memory of an occasion, abstracting away the inconvenient fact that other people were there and that they, not me, were the more important players in that little vignette.

Evidence Dana Gardner of Interarbor Solutions, who so graciously invited me right after New Year’s Day this year to be a regular panelist in his SOA Insights podcasts involving leading SOA analysts from various firms. I had barely known Dana at that point (I believe we met in an airport in 2006, coming back from some IT show somewhere—can’t remember the particulars of that occasion—airports cities and shows tend to blur).

My first SOA Insights was on Friday, January 5 of this year. It was with Dana, Steve Garone, Joe McKendrick, and Tony Baer (none of whom I knew before then, but all of whom impressed me with being more deserving of the “leading SOA analyst” title than myself….no, not false modesty….I’m an SOA analyst, all right, but my coverage area has shifted since my Burton Group years away from the application infrastructure focus of most of these folks toward data management…under which SOA is an important theme, but which takes me in different directions from the others…such as Semantic Web…which explains in why I felt inclined to throw that topic into the panel in April…and, of course, explains that just-finished ten-week blogthread).

Anyway, back to the podcast on January 5. Dana usually, a day or two before the event, e-mails the participants a sketchy list of possible topics he’ll bring up, and he did that week. His number one topic was the “ROI of SOA”—a first-podcast topic that, fortunately for me, was like lobbing a clean fastball through the sweet spot of my strike zone—I had published an article on that very topic in Network World in October 2005, and I had my print-out of the original manuscript, including a symbolic SOA mesh-like drawing I was inordinately proud of, in front of me as I spoke to the world that January morning.

I already had my remarks mapped out in my head when Dana turned virtually toward me to set me up. In the following excerpt from the transcript of that podcast, notice that Dana lead in with a “root system” metaphor, which I wasn’t expecting. Notice how I then, in a eureka moment of which I’m also inordinately proud, morphed Dana’s metaphor into another metaphor—SOA as fungus--that has since that time struck a responsive chord with a bunch of folks across cyberspace (as gleaned through my daily reading and occasional self-Googling):


Gardner: I’ve spoken to HP and IBM as well, and they’re really undergoing IT transformation, probably business transformation, and there are many constituent parts to that, of which SOA is one. But SOA is one that has, I suppose, a lot of interdependencies and effects across many of these other activities, whether it’s server consolidation, application modernization, IT shared services, virtualization and what have you.

”Let’s go over to Jim. Jim, if SOA is important, almost like a root system that cuts across a number of different trees that are growing, is it even worthwhile measuring it, or should people just be smart enough to recognize that this is the right thing to do?

Kobielus: That’s an interesting metaphor there -- SOA as a root system. My visual image of SOA is a very complex hyper-mesh. In other words, like a root system, where you have tendrils going hither and yon, the tendrils being simply interactions among services and client.

”It’s very worthwhile to measure the ROI of SOA as a paradigm or an approach for enabling and for maximizing the sharing and reuse and interoperability of distributed resources across your network. You make an investment as an organization, as an enterprise, and in this approach you want to know whether you’re investing your funds and your resources wisely. When I think of SOA’s ROI, I think of two numbers, and those numbers are 100 and zero.

”As we know, SOA focuses on how you maximize the sharing and reuse of services, of application functionality and resources. In other words, how do you enable a 100 percent reuse as a nirvana? We’ll never get there, but in any given organization, 100 percent reuse, service reuse, first and foremost is a consolidation topic. What that means is, if you do SOA right, you’re doing much more with much less.

”You’re able to consolidate redundant silos of application functionality and data throughout the organization. You’re able to consolidate fewer software licenses and servers, with the associated translation and cost savings and capital on operating budgets, fewer redundant software components and so forth. The need for fewer programming groups, as we can consolidate that as well.

”So 100 percent reuse is the nirvana. The zero comes in the sense that, if you’re doing SOA right, the marginal cost of billing the next application drops pretty close to zero. You’re able to reuse everything that’s already been built. You do not have to reinvent the wheel. So, basically, a 100 percent reuse means zero marginal cost of building the next application. Of course, as I said, you enable that vision through consolidation, both in software and hardware, and in programming teams, and so forth.

”So, once again, getting back to your root-system-and-tree metaphor, SOA becomes this ubiquitous root system from which new sprigs can pop up, without needing to lay down their own root system. Rather they are simply branches on a huge underground system. In [the] northern [part of the state of] Michigan, where I’m from [btw, I'm originally from southern Michigan...born in Jackson...grew up in Livonia...a suburb of Detroit....left there a quarter-century ago], scientists have discovered the world’s largest organism as a mushroom or a fungus of some sort that spans 30, 40, or 50 square miles. They determined though DNA analysis that it's the exact same individual and has got the largest biomass in the world. In essence -- and it’s all underground pretty much. That’s what SOA is all about, essentially all the services in an SOA sort of share a common DNA.

Gardner: Well, there’s the message we need to take to the CEOs and the CFOs. Let’s make our IT like a fungus.

Kobielus: I think they probably already believe that!”


Boy, am I glad we didn’t deep-end on that metaphor: it can quickly lead to some disparaging, distracting, downright dirty connotations. Later on in that session, we all morphed together into an SOA-as-movie-studio metaphor (by way of Dana morphing fungus to amoeba, and then amoeba to plumbing, and then plumbing to architecture, and then architecture to soundstage, and then soundstage to movie studio—I’m too impatient to get to the point of this new blogpost—does anybody care enough to go back to the transcript and double-check the sequence of images? don’t?...don’t worry…hold on, gotta give Tony Baer credit for taking it to the movie studio metaphor, which is where I picked up developing it further then, and will do so “again” presently).

First, here’s me “then”:


Kobielus: I’m going to take this movie industry metaphor out of the realm of metaphor into the actuality of, teams becoming very SOA-focused in terms of the actual production ... A mashup is reusing existing components of service -- content -- whatever into new vehicles or new compositions. If you look at the content that’s being developed out there in the IT world, more of it's getting built through various types of mashups, which is very much an instantiation of the SOA paradigm into a different world -- not the software world so much as the normal cultural world that we all inhabit.”


Now, me now:

This feeds nicely into how I approach SOA as the principal analyst for data management at Current Analysis. Fundamentally, as I’ve told many people on many occasions over the past few years:

  • SOA is a paradigm for maximizing the reuse, sharing, and interoperability of precious resources over distributed fabrics.
  • For any organization, one of the most precious resources is the master data—the official, single-version-of-truth, recordkeeping data--on which they run the business.
  • Consequently, the life-cycle governance of that master data—and of the distributed services for extracting, transforming, and loading; for profiling, cleansing, and enhancing; for consolidating, controlling, and versioning; for accessing, distributing, delivering, and mashing up that master data—is one of the most critical applications of SOA in the corporate world.
  • Hence, master data management (MDM) is SOA in the sphere of data management—lifecycle governance of that sprawling fungus, amoeba, aquifer, grotto, or whatever called SOA—governance of the master data, of all of the myriad, sundry, and sordid means by which it all gets mashed up—and acquires meaning, either at the source through careful composition—or in the intermediate re-interpretations or recontextualizations—or the emergent process by which meaning blurs, distorts, or opaques through progressive deconstruction or regressive decomposition somewhere across that universal producinogenic fungus….
  • For that’s what fungi do, here on this earth….

They decompose and consume every last sentient thing.


Thursday, July 12, 2007

imho Ocean Semantic.............._


Ah, coast sweet coast.

Hey, the coast is clear for me. I think I'm clear on what Semantic Web, semantic interoperability, ontologies, taxonomies, folksonomies, and all that are all about, and why they're important. But not everybody is clear on the concept of concept-based data modeling, search, integration, etc.

And the people who still don't see the point of it all are in the vast majority of the IT world. They're not stupid, of course, but are justifiably skeptical of a semantic wave that's been taking far too long to cross the SOA ocean.

Case in point: Bill Inmon, the guy who continues to be the father figure and best-practices prophet for the data warehousing universe. Check out what Bill said last month: "I admit it. When it comes to semantics, I don’t just get it. You can call me misguided, an old fuddy duddy, or just plain dumb. In one way or another, perhaps all of those names fit. But at the end of the day, I just don’t understand semantics."

Let's be clear on what Bill was saying. It's not that he doesn't understand what semantics is or is not--it's just that he fails to see what value-added the "Semantic Web" adds over and above traditional approaches to semantic integration. Inmon at length:

"One branch of semantics I looked into with great interest was ontologies. Having done some cursory work in the field in my own software development, I thought that surely here was a value proposition. But no. At least, I couldn’t find it.

"Then I looked at semantic logic. Now semantic logic is quite interesting. It reminds me of a really good crossword puzzle – the kind I like to take on flights between Europe and the U.S. But while semantic logic is interesting, how it applies to any business problem is beyond me. No luck here.

"Then I looked at linguistics. This was perhaps the biggest disappointment of all. Linguistics has been around for years. There have been countless hours of research and countless government grants in the field of linguistics for a long time now (at least 30 years). And where is the business problem that is being addressed by linguistics? Certainly it is nowhere on a large scale. It is true that there are some small startup efforts that make use of linguistic technology. But after thirty years of research, you would think that there would be a lot more technology on the table – a lot more proof in the pudding."

I quote Inmon at length not to agree with him so much as to point out the degree of intellectual fatigue implicit in his comments. Immersing yourself in this sometimes shiny, often briny, occasionally nonspecific ocean of academic and technologic goodies can be suffocating. I chose to test the waters simply because I realized that Semantic Web is slowly inundating the coastline in EII, ECM, BI, DQ, MDM, ESB, and other of my core coverage areas. Also, further investigation of this space has been one of my back-burner personal/professional/intellectual to-dos since 2004 when, in another professional context, I was actively discouraged from going there. Had to go there. 'Twas quite good, this time around, that my podcast colleagues (Dana Gardner, Dave Linthicum, Tony Baer, Joe McKendrick, et al.) at were quite agreeable, amenable, and ideational on this topic, and chose to go there with me. Linthicum, in particular, is an expert himself on the matter, and was a major inspiration and launching point for my random-swim through this specific sea these past two months.

From a blogfodder standpoint, one of things I like about Semantic Web is that one can pretty much connect it to anything one wishes on a philosophic, ontologic, metaphysic, technologic, or sociologic level. What a wonderful context, all this semantic, for this old boy to wax pedantic. I almost wanted to truck into it all a meditation on Immanuel Kant's Critique of Pure Reason, the distinction between "things in themselves" (i.e., true ontology--the study of the objective ground of reality and being) and "things as they appear" (i.e., phenomenology--the study of the subjective apprehension of reality and being)--and to note that Semantic Web "ontologies" are in fact simply an "a posteriori" analytic practical prescriptive institutional instrumental consensus on "things (e.g., subjects, predicates, objects, entities, instances, classes, groups, relationships, attributes) as they appear" to a semantic governance authority within some semantic domain--not actually the sort of "a priori" synthetic metaphysic revelation apprehension of the ineffable root of things that Kant said he had no problem accepting as a possible article of faith but saw as essentially a futile field of unverifiable undecidable propositions outside the sphere of pure reason, which Kant essentially aligned with scientific process of progressive societal construction of an interlinking system of empirically verifiable statements through the building and testing of interpretive frameworks through controlled observations--almost wanted to note that the linguistic concept of "semantics" is a subset, not the sum total of "meaning," since language is an instrument of human intention and any statement can be understood as much in terms of its "pragmatics" (e.g., the explicit or implicit, interior or ulterior motives and objectives that shape and direct it) as it is in terms of its "semantics," which concern the role of language as depicting objects in the objective/real and/or subjective/imaginary world as worthy of our contemplation, and of course, this same language can also be understood as conveying meaning on the level of "poetics," which doesn't so much mean you have to get into William Carlos Williams or Wallace Stevens but rather have to realize that language is itself an object worthy of our contemplation, and that language, this object-in-itself, is memorable only to the degree that the concocter of said bonmots has consciously or otherwise wielded all the communicative devices of good composition, parallelism, grammar, wordchoice, alliteration, tintinnabulation, emotion, tone, guided imagery, etc to make the language itself, and hopefully the semantic objects and pragmatic objectives contained therein compelling and worth our while dwelling therein and upon--but that would be pedantic.

Hey, check out the work of the W3C Emotion Incubator Group ("a general-purpose emotion annotation and representation language). And consider the growing text-analytics-industry implementation of semantic "voice" (e.g., "Voice of the Customer"--see what Attensity, Clarabridge, and others are doing in this sphere) , which is essentially something capable of being extracted as a component of the human "sentiments," moods intentions and propensities, that lie latent in unstructured colloquial text.

In the Social Semantic Web, meaning may be measured in the meandering moods of masses meditating on mashups.

All for now.


Sunday, July 08, 2007

imho Ocean Semantic..............


Recently, I came across the "2007 Semantic Web Challenge" at the O'Reilly XML Blog ( They're asking for "cool" applications of ontologies etc. to "illustrate to society what the Semantic Web can provide."

For a Semantic Web "killer app" that pretty much everybody understands intuitively, the judges of this contest should focus on semantic search. As noted earlier, semantic search already accounts for a large share of the commercial implementations of ontologies, RDF/OWL, text analytics, and so forth. It searches by concepts, not mere text strings, leveraging ontologies to speed searches, make them more accurate, and weed out spurious hits. It points to a future where Googling delivers you to the exact, correct, complete answer to your natural-language questions with each and every query. "I'm Feeling Lucky"? Hah, that's so Web 1.0!

To a great extent, search is the killer app for both the SOA Semantic Web (see previous paragraph, and post of June 6, 2007 in this thread) and the Social Semantic Web (see following paragraphs, and that same June 6 post).

As regards the Social Semantic Web, this term primarily refers to "social networking," "social bookmarking," and "folksonomy" initiatives such as, Digg, and Reddit. These and brethren/sustren "Web 2.0" phenomena are online communities within which users may collectively link, tag, classify, and comment on Web content originated elsewhere (however, usually without reference to W3C SOA Semantic Web specifications such as RDF/OWL etc). The key difference between the SOA Semantic Web and these Social Semantic Web efforts is that the former relies primarily on professional developers to create and maintain standards-based ontologies, whereas the latter relies on end users to create informal, non-standard collections of descriptive tags that apply to content they find while surfing the Web.

Fundamentally, though, the entire Social Semantic Web universe is a big, distributed, human-powered search engine. The core features of any search engine are to crawl, correlate, and rate content originated elsewhere. Traditional search engines do this with spiders, whereas Social Semantic Web communities accomplish the same end through surfers (or possibly, it's a "botts" vs. "butts" distinction, but I digress). Just as no single spider-powered engine can crawl everything in the universe all the time and place it all in every conceivable context for every potential searcher, no single "social bookmarking" community can be a be-all boddhisatva of semantic salvation.

Choose your ontological oracle, so you can search and surf the ocean semantic, always in clear sight of some comfortable contextual coastline.

One to come.