thenagin The SOA Multilateral Treaty Organization Metaphor

All:

Then:

http://briefingsdirect.blogspot.com/2007/04/briefingsdirect-soa-insights-analysts.html

Again:

OK, OK, nobody actually raised this particular metaphor during this particular podcast, which was recorded on Friday Feb. 16 of this year. It actually came up two weeks before, in the podcast that I last wrote up under “SOA Avionics Engineering Metaphor”…but who says you can’t have a two-metaphor podcast….or an SOA metaphor that gets developed over the course of two podcasts….which, as I’ll show in just a sec, is what I did, implicitly, by suggesting that the Feb. 16 session focus on the realization of SOA governance through “governance risk and compliance” tools in SOA suites.

First, back to Feb. 2, which I linked-to in that last from-the-airport posting of mine. After the SOA project failure/tailspin/avionics theme had run its course, we moved onto the SOA federation theme….Dana made a nice “let’s move along” conceptual connective remark, and we all put in some interesting comments from various angles. I was more than happy to bring federation into my discussion of SOA….federation has been a core organizing theme for me for several years, as anybody can plainly see from my published output….for the record (I know this definition is somewhere in the long train of my blog, but here it is again):

Kobielus [again, now, Aug. 20 2007, for the umpteenth]: “Federation is a governance structure under which autonomous domains agree to honor each other’s decisions and accept each other’s assertions in some sphere of human endeavor, subject to business contracts, trust relationships, interoperability agreements, and local policies.”

With that as context, here’s how, on Feb. 2, 2007, I phrased my take on SOA governance/federation, and then started to raise the analogy/metaphor with multilateral treaty organizations, such as the United Nations and NATO:

“Kobielus: An SOA initiative is a success if it gives you the ability to adapt the SOA governance structure to your actual business governance structure. As you’re saying, your business governance structure will evolve over time. All business models change. So the extent to which your SOA initiative and your SOA governance are totally centralized and totally rigid -- but your business environment and the challenges and threats and so forth are constantly changing -- then your SOA failure will ultimately become a business failure, a failure to adapt….”

”Kobielus: We talk about political governance in terms of the world community. There is no one right governance model within a state or among the various states of the world. But clearly, history has been marked by individual states or groups of states playing and towing with, if you can use the word, various governance models ranging from absolute dictatorships and empires down to sort of laissez-faire, no centralized government.

But governance is an abstract concept, and you don’t necessarily want to dictate one governance model that’s applicable or should be applicable to all organizations and industries. Everybody has their own pressures, market pressures and so forth. In terms of SOA governance, there are radically centralized models in a given organization. It could be a radically centralized governance model within a given industry sector in the sense that basically one monopoly company controls an entire sector of the economy and they then dictate all the SOA policies and practices for all of their tributaries, as it were.

In the world, you have 230-something countries that are sovereign states ostensibly, and they establish various bilateral treaty relationships and also participate in various multi-lateral treaty organizations like the United Nations and NATO and so forth. Any given country is probably, involved in various international governance schemes as it were -- but also internally, from generation to generation, from revolution to revolution it’s going from centralized to decentralized. One size doesn’t fit all generations of governance….”

”Kobielus: Think of this notion of where companies in the most post-modern age are going to get their governance structures from. I think a lot of the governance risk and compliance (GRC) management vendors -- it’s a new market space; companies like SAP and OpenPages and MEGA International and BWise, and others, are building up platforms that have both verticalized and horizontalized governance templates, rules and workflows, and so forth. Increasingly companies or enterprises will standardize on a dominant GRC management vendor for their organizations, and then use whatever templates they choose. And their SIs will modify them to suit their own needs going forward.

Bringing this back to the whole notion of where nations get their governance charters. I just read a book, a really good one, called "Declarations of Independence," and it shows that the first actual declaration of independence ever created to found a nation was our Declaration of Independence in 1776. You wouldn’t believe how many other countries have actually plagiarized or borrowed language and whole concepts from it, including Vietnam. The declaration of independence for Vietnam in 1945 [Kobielus now-note: authored by Ho Chi Minh] directly quotes from our Declaration of Independence, which I found highly ironic.”

Notice how, on Feb. 2, I shifted the topic of SOA governance away from its typical focus on best practices, registries, and so forth, toward a discussion of a new SOA product niche: GRC. In my work at Current Analysis, I’ve been speaking with many GRC vendors, have written a fair number of reports on this market, and am developing a GRC reference framework and maturity model. So, having run the GRC topic up this preliminary flagpole, I proposed it outright for the Feb. 16 podcast. Dana and the crew accepted it, and we had a great discussion developing it further on that latter date. Essentially, GRC tools are IT/SOA means for putting “teeth” in business governance policies, practices, mandates, etc.

Here’s how Dana framed that Feb. 16 GRC discussion upfront:

“Gardner: This week …we’re going to tackle … an important issue around governance, and whether governance is going to evolve into more of a converged activity. What we’re seeing is that SOA governance vendors are putting together policy-based approaches for managing the complexity of SOA. They're trying to automate the various resources within that environment and architecture, and to provide control for those managing the IT development deployment life cycle, as we get more toward a mixed environment of services, perhaps a variety of different sources. So, we've got SOA governance that is evolving, but with its own technology, its own metadata, its own repositories, and even its own standards. Alongside that on a parallel track are Governance, Risk and Compliance (GRC) platforms, and a number of prominent vendors such as SAP, CA, OpenPages, MEGA and others are providing this as a service for regulatory compliance, principally to CFOs in large organizations.”

Here’s how I ran with it that week:

“Kobielus: Thanks, Dana. I started being fairly cynical about a year ago over whether compliance was a market, I kept hearing about the compliance market, the Sarb-Ox market, and so forth. I was thinking it’s a concern in the same way that competitive advantage is a concern or a benefit from the appropriate and effective deployment of technology, but can you really regard compliance as a platform?

One of the things that I've seen over the past year is the growth of this new sector -- GRC: Governance, Risk, and Compliance Management -- not just as a big top under which many diverse product categories are being lumped, although to some degree it is. You see business intelligence, corporate performance and management, business process management, identity management, document management, all these things, all these existing technologies, being lumped under this GRC heading.

What I've also seen is that a growing group of vendors are building products or platforms into which they’re able to plug in, and are plugging in, various tools specifically geared toward GRC. In other words, a legitimate new niche of GRC vendors is growing up, and, Dana, you listed some of the chief ones that I've come across.

SAP about a year ago acquired a company called Virsa Systems, which made tools for continuous controls monitoring. Around the Virsa Team as a nucleus SAP has begun to roll out a GRC platform that includes a repository of policies and rules, a process modeling tool geared towards building business controls as structured workflows and also testing and monitoring those controls.

They rolled out a performance management dashboard environment under which you can roll up a unified view of your compliance and your corporate risks across all governance categories. The categories include SOA governance, IT governance, and operational business governance, and so forth. SAP is not alone in this regard.

You mentioned Computer Associates. They have their Clarity family of products, and there are some smaller but just as important like OpenPages and MEGA International, BWise, and several others that have similar product architectures and similar modular approaches to plug-ins. For example, you can plug in to most of these environments a module to do IT governance in compliance to say, CobiT, ITIL, and so forth.

One of the things I haven’t seen yet is any clear convergence between all this GRC governance, a lot of business governance and high level IT governance products, and the SOA governance world of UDDI registries and Web services management agents a la AmberPoint. I see two separate camps right now.

To some degree the GRC vendors are all pretty much SOA-enabled in the sense that they have native implementation of Web services, but I'm not yet seeing the vendors in that camp, other than SAP, with a strong SOA story or SOA partnerships. SAP has significantly SOA-enabled their entire suite of products over the last several years. So, that's the open question I wanted to bring out for group discussion: To what extent do you all see a convergence between business governance a la GRC and SOA governance?”

Neil Macehiter:

“Macehiter: ….Jim commented on it and he was somewhat cynical about that being a compliance market. I'm still quite cynical about it being a compliance market, because I think compliance and, more generally, governance is something that should be systemic. It’s not something that you sell with a particular tool or even a particular platform. It’s something that has to be systemic throughout the IT architecture, so that, for example, high-level business policies and high-level business requirements, in terms of compliance, can then cascade down through the IT solutions that actually automate and support the business processes that need to comply…..That extends across things like identity management solutions, which have also come up with their own compliance solutions focused on their particular bit of the overall IT architectures. …. It needs to become systemic, and it’s not just SOA governance that needs to be tied into this. It’s also the work that’s going on in the IT service management market around CobiT- and ITIL-based processes.”

Steve Garone:

“Garone: ….I think the over-arching issue here is that GRC platforms are taking more of an enterprise architecture approach. They're still looking at business processes, monitoring business processes, and maybe even getting to some extent into the redesign of those processes to optimize the ability to meet compliance needs. ….SOA tends more, at least right now, to focus on making business processes work more efficiently. How those services are segmented and designed functionally ideally should reflect that; whereas, for the enterprise architectural approach and the GRC approach, we're looking more at being able to meet compliance needs. The question becomes how do you develop a services-oriented approach that meets both of those needs, optimizes compliance on one end, and optimizes customer satisfaction and performance and business agility on the other hand.”

Dana (making an observation that goes to the heart of the GRC reference framework—more from me on this at the end of this post):

“Gardner: And, clearly business intelligence vendors, including SAP, have come into the fore. Reporting is the very core of business intelligence. So, first and foremost, if you want to do compliance, you have to produce reports, and if you have to produce reports on a regular basis from structured data in your operational systems, you need business intelligence (BI). That’s really the core, as it were, of any GRC platform. One of the interesting things I'm finding in the growth of these GRC über-platforms is that there’s another important user interface, other than just the reporting and dashboarding the BI stuff. There are also structured surveys that can be delivered to stakeholders in a process on a periodic basis, asking, for example, procurement agents how well various business requirements or regulatory requirements are being met, from the procurement side to be in compliance with Sarb-Ox or whatever it might be. So most of these platforms now have what I call a stakeholder interaction environment, involving not only the surveys, but other human workflows, not just GRC as a mean for pushing big rolled-up risk dashboards to the CFOs and the CEOs, but GRC as a way of regularly serving the troops as to how well processes are performing on various levels.”

Joe McKendrick (essentially underlining Dana’s point re the need for BI/reporting/dashboarding and other automated GRC tools):

“McKendrick: …. What we found in the survey is that for the most part, there’s awareness. About 40 percent of the survey group from the 400 companies we interviewed was fairly aware of GRC, what's happening, and what's required for GRC. That was higher than we expected. So they’re trying to getting their heads around what needs to be done with compliance. At this point, the tools that are being used the most to accomplish the task around GRC compliance are the Excel spreadsheets or the Word-type documents that are flying back and forth. Seven out of 10 companies are moving these processes through or doing the reporting and putting out reports for the audits with these manual tools. Only about 15 percent say they have any measure of automation.”

Me again (tying GRC back to the notion of needing to be included/integrated in SOA suites):

“Kobielus: SOA is about sharing and reusing valuable corporate resources that are networked. The GRC platforms increasingly will differentiate based on their ability to bundle a broader range of best practices accelerator with polices and works flows and roles and metadata, and forth. So, really, GRC platforms are platforms for SIs to customize the policies to meet the needs of particular clients. The accelerators themselves are the sharable, reusable SOA resource that will speed up the implementation of compliance solutions in various markets. The accelerators themselves are the most critical resource that defines a GRC platform or GRC solution.”

Neil again (offering a comment so perfectly tuned to my argument that I’m wondering if I should him for his services on that occasion):

“Macehiter: The point Jim raised about sharing and reusing is absolutely the key here. It's the one of the biggest challenges around compliance. Typically, organizations have multiple instances of processes locked away in different applications. They have 16 different versions of their customer or 14 different versions of a purchase order. If what you can do by virtue of adopting more of a service-oriented approach is have common services to actually deliver capabilities that need to be audited, logged, and monitored, or if you can have a single shared service that increases consistency and reduces the effort you need to apply for compliance, increasingly what we will see is the rationale for the business case. What underpins an SOA initiative will be either that it improves our ability to comply in a cost-effective way and increases the consistency of what we do to comply.”

Then Joe again, explaining why it’s likely that the GRC and SOA/IT governance markets will remain on slightly different wavelengths, due to different business drivers, advocates, stakeholders, users:

“McKendrick: …. The only issue is that GRC is typically led by financial folks and, of course, SOA is coming out of the IT department. What happens is that the financial folks are saying, “We need more of this automated. We are not going to give you more budget to do it, but IT folks automate this process little bit more for us."

Now, me again, jumping to another date (Mar 22, 2007—the following month) and another context (an Advisory Report for Current Analysis, in which I presented the outlines of my GRC reference framework)…that Feb. 16 podcast was the final-validation point in my development of these ideas, which had been germinating in my mind since the previous May:

“Governance, risk, and compliance (GRC) is a catch-all market segment into which a growing range of vendors are positioning solutions. Recent GRC-related product announcements from Oracle, CA, SAP, and other vendors have to some degree validated that this is in fact an important niche. However, much popular confusion reigns regarding the functional scope of GRC suites, their support (or lack thereof) for related concepts such as IT governance and SOA governance, and the value added (if any) for enterprises that invest in GRC-enabling product suites rather than diverse point solutions. Nevertheless, GRC suites are emerging and maturing, and commercial solutions are converging on a common functional architecture that blends elements of business intelligence (BI), corporate performance management (CPM), business process management (BPM), data warehousing (DW), master data management (MDM), identity and access management (I&AM), and collaboration….

For starters, GRC suites revolve around a core feature set: the ability to monitor, verify, and optimize business controls that have been expressed as structured workflows. All GRC suites support automatic aggregation of enterprise business-process risks, provide supporting evidence of compliance, pinpoint control violations, and enable escalation and prioritization of corrective actions. They do so through the following functional components:

• GRC repositories: These repositories support centralized storage, administration, auditing, and control of GRC-relevant entities, including frameworks, mandates, policies, rules, roles, metrics, and workflows. Often, the repositories include libraries of segregation-of-duties (SoD) controls in support of automated detection and prevention of access control violations.

• GRC BPM tools: These tools support modeling, simulation, and development of enterprise controls; execution and enforcement of the associated workflows; monitoring, auditing, and tracking of compliance; and initiation of alerts and corrective actions. Often, such tools support continuous monitoring for changes in SoD and application-configuration controls, including the ability to set up auditing parameters to enforce organizational tolerances across multiple process instances.

• GRC CPM dashboards: These visual dashboards, scorecards, analytics, and reports provide high-level visibility and detailed drilldowns into GRC metrics across one or more mandates, enterprise levels, organizational entities, business processes, and IT infrastructures. They often support real-time continuous updates to displays of key metrics, and also provide visibility into historical trends into ongoing compliance.

• GRC stakeholder interaction services: These services support collaboration, human workflows, role-based personalized views, survey feedback links, action plan management tools, and configurable alerts to support operational enterprise risk management among business process analysts, process participants, and other GRC stakeholders.

• GRC resource connectors: These connectors provide integration to the diverse applications, databases, middleware environments, and other infrastructures across which GRC controls are being monitored, enforced, and audited. Relying both on loosely-coupled service-oriented architecture (SOA) approaches and/or embedded agent technologies, connectors also provide integration with the diverse portal, BI, CPM, BPM, DW, I&AM, and other point solution elements of a heterogeneous, multivendor GRC infrastructure.

One key area of differentiation among GRC vendors is in their ability to facilitate their customers’ GRC projects through prepackaged “project accelerators.” These accelerators consist of bundled regulatory framework libraries, implementation templates, workflows, and other metadata—as well as professional services--to support diverse GRC mandates and best practices, including SOX, HIPAA, Basel II, COSO, COBIT, and ITIL. The best-of-breed GRC platforms will be those that support ongoing compliance with many overlapping mandates.”

GRC enabling “ongoing compliance with many overlapping mandates”…i.e., the need for business/IT/SOA governance environments to serve many masters, stakeholders, requirements, and policies continually…honoring their myriad decisions and accepting their myriad assertions across myriad business processes….that’s the essence of governance in a world of multilateral multilevel multidomain federation.

Tough balance to maintain. Pulled every which way. Comply continually with contradictory mandates? Is that even possible?

Then again, that’s why “risk” is the fulcrum word in “GRC.”

Jim

thenagin The SOA Avionics Engineering Metaphor

All:

Then: http://briefingsdirect.blogspot.com/2007/03/briefingsdirect-soa-insights-analysts_23.html

Again:

This metaphor—actually, an “SOA projects as airplanes in danger of failing hence going into tailspins” metaphor--comes courtesy of Miko Matsumura (was-Infravio, then-webMethods, now-Software AG), who did a one-off participation in the podcast on Friday, February 2.

Ironically or something, I was reminded of that metaphor yesterday evening--while re-reading the transcript of that day’s (Friday February 2) podcast--while listening to the Jayhawks’ song “Tailspin” (from their excellent 2003 CD “Rainy Day Music,” playing on my laptop)--while sitting cross-legged on the floor at Gate B1 in Atlanta’s Hartsfield-Jackson International Airport—while waiting to get an updated on my much-delayed connecting flight home to DC (flight was canceled right after I started composing this post; as were many other flights yesterday, due first to mechanical problems with my flight, then to various weather issues in the northeastern US that tangled air traffic throughout the country). Was attempting (still attempting this Friday morning, Aug 10, sitting now at Gate A3) to get home from Sybase TechWave 2007 conference in Las Vegas—had dinner with Dana—will share more details in a later post). Nothing much to do now but write this blog entry, offline, and then post it when I get home tonight, tomorrow, whenever. Not in a tailspin so much as just sitting on my tired tail.

Anyway, back to Friday morning, February 2, 10am (eastern). On that prior august occasion (not this current August occasion) Dana focused the discussion on the topic of SOA projects that fail, how they fail, how to detect when they’re failing, and how to prevent them from failing (notice that I’m choosing to ignore the “SOA failure as unpleasant skin condition” metaphor that he seems to be hinting at):

“Gardner: One of the topics I wanted to get into this week, and we’ll throw this out to the entire group, is looking at failure in SOA. What is the problem with those projects that are not going well these days? We talk a lot about SOA, the business value, when the maturity is coming, and where the technology and standards are going. But I thought it might be worthwhile to take a step back and say, ‘Where are the warts, and why are they there? What can we learn from that?’ You’ve had some experience in the field, Miko. Many of our panel speakers are working in these areas consistently. So I wanted to ask the panel, anyone at all. Have you come across SOA projects that have not been stellar successes? And, if so, are there any immediate lessons to be learned?”

Miko’s initial response was funny:

“Matsumura: I'll answer, since you called my name out, and since it’s also a glorious introduction to have someone say, ‘Yes, I’d love to talk about the topic of failures and for this they have a guest expert.’ From our perspective, the thing that is really vital about this topic is that in 2007 we’re as likely to see catastrophic failures as we are limited success. There are a huge number of moving parts within SOA, and I'm going to use that almost as a handout point to this very well-considered group of folks. We need to categorize for the listener which moving parts are more dangerous than other moving parts, because those are the things that eventually cause the thing to kind of wiggle the wrong way, and send it to a tailspin.”

For some reason, Miko’s great “let’s not be afraid to face failure, but, no sir, I’m no failure face” response has me tripping down memory lane. Back in the early 90s, I was a telecom contractor to the federal government, and in a meeting one day I characterized a particular task as a “no-brainer,” then gestured to my colleague across the table, adding, “and we have just the right guy for the job.” Nobody got it. Nobody ever gets my jokes. Maybe it’s my delivery. Or maybe I just suck at comedy. Anyway, back to now, or, rather, six months ago, and this particular podcast. Steve Garone had a good bang-on response that identified the high-level tailspinners in terms of the classic textbook “why IT projects fail” factors:

“Garone: I’ve gotten involved in some research in the past, and it doesn’t really relate to SOA, but the results that I see from this research have tended to point out two major areas that cause or are the main factors behind these kinds of failures. One is a difficulty in nailing down and keeping a continuous eye on requirements for an application. The other has to do with corporate backing for that particular effort within the company. It's more focused on the people-oriented things and the collaborative issues associated with deciding what to build and how to build it. What [Miko] just indicated was that, in the case of SOA, the focus in terms of failure might be more on the technology-based pieces [Jim now-note--i.e., the ‘moving parts’ of the tailspinning aircraft] associated with building an application. Do you see SOA being different in terms of what actually is responsible for failures?”

Then Miko, God love ‘im, extended the “SOA mechanism’s moving parts” metaphor brilliantly and, apparently, spontaneously:

“Matsumura: That’s exactly what I was hoping to elicit -- the idea that, in fact, a lot of the moving parts -- and the most dangerous moving parts -- are people. From our perspective, the system is sort of cybernetic, half-human, half-machine. The human pieces of SOA are the parts that we’ve seen in failure mode. It’s not necessarily just the human beings themselves, but, as you described, the interfaces between the human world and the machine world, whether those interfaces are the specifications used to design applications, or the mechanisms used to manifest constraints and policies. They make sure that people, when they do fight each other, fight each other in a way that's productive, as opposed to destructive.”

Here now was my response then, not so much extending the “SOA aircraft’s failure-prone moving parts” metaphor as sort of beginning to hint at a “each SOA aircraft is a moving part in the larger SOA mechanism defined by the air traffic control system that can fail, six months in the future, to deliver Jim Kobielus on time to his scheduled destination due to the collateral impact of adverse weather conditions such as summer thunderstorms in various cities on flights connecting to and from yet other cities, and if ya really think about it, the entire air traffic control system is itself a virtual moving part in a larger SOA mechanism defined by the dynamic climatic conditions on this planet, which are driven by phenomena such global warming, which, gosh darn it, might be exacerbated by us all continuously trying to boil the SOA ocean” metaphor. Here’s what I actually said then:

“Kobielus: I think that SOA failures are a subset of IT project failures, which are of course legendary. The most common reason IT projects fail is lack of the appropriate business justification for them. Quite often, their aims are so broad and nebulous [Jim now-note: “nebulous” etymological root in “cloud,” which dovetails nicely both with “above the cloud” (my Network World column name), with SOA “clouds” (i.e., what forms when the SOA sun boils the SOA ocean)] that there are over-heightened expectations built up about how it will change the business and contribute to revenues, profitability, and so forth. There’s a ‘boil the ocean’ element of SOA justifications, because SOA as a set of best practices, is often pitched as, ‘We’re going to totally clean up; we’re going to totally clean up our development practices and our integration practices. We’re going to orient them around this new grand unifying scheme called SOA.’ When projects are pitched in that way, and justified in that way, you’re just setting up the SOA project for failure.”

A minute or two later, Miko made the following statement implying, to extend the avionics metaphor, that policy is the cockpit and stick that the human-SOA-pilot moving parts use to control the SOA aircraft:

“Matsumura: [W]e’ve learned that the people who control the SOA are the people who essentially control the policies. The policies include metadata, repository, and registry -- the kind of policies that are machine-enforceable, but also involve human factors. In a way, the model is more of an equal partnership now. On the other hand, real system integrators like to control policy as a way to permanently set up a base camp inside an account, pour people through the door, and take over. It's something that we know they're salivating about.”

Machine-enforceable policies? SOA on auto-pilot? Yeah, now you’re lighting up the radar screen in the control tower in my head…tell me more, Miko, or, OK Joe McKendrick, I’ll hand it off to you, so you can offer up an observation that, in its closing image, puts me in mind of Delta Airlines rerouting passengers—or, more to the point, booking Jim Kobielus on another flight this morning—to work-around the air-traffic snarl that got him so hot and bothered yesterday (in which, incidentally, Atlanta experienced the highest low temperature, 82 Fahrenheit, in its humid history):

“McKendrick: There’s a tension between various groups in the enterprise. I guess there’s a lack of a clear definition as to who is going to be doing what, and who is going to be controlling what. SOA, of course, is inherently cross-enterprise -- or in theory it’s cross enterprise. An SOA that’s confined to a single silo or single piece of the enterprise, by definition isn’t necessarily an SOA. It’s another proprietary system. I was curious as well as to what the definition of failure would be in an SOA situation. Personally, I'm not familiar with situations where an SOA, or components of an SOA, had to be rolled back, such as you’ve heard about with spectacular ERP failures. It seems that there may be heightened expectations of ROI or increased business agility, which don’t happen immediately, but components of the SOA still may stay in place and just be sent off in a different direction.”

Then Miko offered up the example of a real-world “SOA as tailspinning aircraft out of control” project failure, incidentally introducing other “mode of transportation” metaphors that correspond to other options for getting me home this morning that, to be quite honest, I’m more than willing to consider at this point:

“Matsumura: For example, a project I was involved in for the insurance industry was widely touted as an early SOA poster child by the vendor. The CIO was on the speaking circuit, which was dragging him off the field, and he had essentially outsourced the entire project toward a single source. What eventually happened was that this particular individual ended up having to leave the company. I think that the CIO had this mistaken impression that the service interface abstraction allowed him to outsource completely the operational concerns and the implementation concerns, and eventually to treat this service interface as something like a child’s car seat, where really mom is driving. It’s important to treat the interface abstraction layer like a saddle on a horse, which means that the only people who can successfully get from Point A to Point B are the people who have the skill of riding and controlling the horse, which is the service implementation. It’s really an abstract or complicated metaphor. It’s not hard to lose control.”

Then me again, pining for the simplicity of an “SOA as a simple pair of wings that I can strap to my arms and fly my way home under my own power” option (and I can’t believe the exquisite serendipitous beauty, for my present purpose, of the fact that I said “fly in the face of,” which, unfortunately, suggests Icarus, and you recall his epic tailspin):

“Kobielus: I think that the way to define SOA failure is the failure of SOA as a set of practices that a company adopts, the company’s failure to realize the grand claims made for SOA. These include such benefits as improving interoperability, simplifying your IT environment, reducing the cost of that environment, speeding up the development of applications, and enabling greater flexibility in terms of where you can source various components, portals, databases, and integration components from. An SOA project or initiative is a failure if it increases the complexity of your environment, if it increases cost, if doesn’t make much of a dent in the incompatibilities among different platforms, or if it locks you into a given vendor. That’s why last week I brought up the whole notion of SOA suites. This notion of an SOA suite from a single vendor who provides everything for you seems to fly in the face of, ‘Isn’t SOA supposed to allow me to mix and match the BEA, Oracle, webMethods, Microsoft, and everybody else’s components in my environment ?’ If, at the end of the day, you’re a CTO and you say, "Well, here’s my SOA strategy, and we standardize on Oracle or webMethods" -- are you really gaining anything over the monolithic days of yore?”

So take that, you long-departed Mr. Howard Hughes billionaire aircraft manufacturer, and take this you very-alive Mr. Larry Ellison, Mr. Bill Gates, etc. etc, you and your Spruce Gooses of an “SOA as big heavy lumbering monolithic stack that will never quite gain cruising altitude” suite, your so-deliciously-non-metaphorical monument to industry hubris, or something (gee…I need a good night’s sleep right about now…can you tell?). Anyway, at some point in the Feb 2 discussion, Dana ramped up the avionics metaphor to an interstellar science-fiction “SOA as spacecraft” metaphor worthy of Gene Roddenberry (or perhaps Kantner-Balin-Slick Jefferson Airplane-cum-Starship):

“Gardner: We’re getting at the point where world political history is perhaps a guide to how to approach SOA. Do you want a Third World dictatorship? Do you want empires extending their influence? Do we want a Pax Romana approach? Or do we want a pure democracy or a federated democracy? I’m thinking more about Star Trek, when the Romulans and the Klingons get together. If you could only get that to happen in IT, would be in a lot better shape.”

At Dana’s cue (starfleet federation etc.), at that point, we transitioned into an “SOA as federation” discussion, which was substantial in its own right, but ended the discussion of SOA tailspinning, failing, and all that. Which is where I’ll close off this post as well (I’ll take up the SOA as federation/governance topic later….or, hold on, didn’t I do an “arch of governance” thread a while back?....btw, Dana and I had a very pleasant dinner at the Sybase show, and over drinks discussed the potential of wild/wacky SOA evolution or global warming or millennial or anthropology or tectonic or world history metaphors such as “SOA as Bering land bridge” and so forth, but not now….gotta go).

They’re just about to open the gate and board my flight. And hopefully get some wind neath my tuckered tailfeathers. Wish me luck, or something.

Your SOA seatmate.

Jim

thenagin The SOA Arsenal Metaphor

All:

Then:
http://briefingsdirect.blogspot.com/2007/03/briefingsdirect-soa-insights-analysts.html

Again:

Dana raised that metaphor in his opening remarks on this particular podcast, which was recorded on Friday January 26 of this year. That word has made me giggle since Morrissey brit-punned on it in the title to one of his early solo albums. Do a quick Google to giggle along with the master of mope.

Won’t go any further down--or up--that dirty boulevard of metaphorical elaboration. As for the podcast, we discussed three very substantial topics: best-of-breed SOA suites, master data management (MDM), and the “new enterprise architect.” Other panelists included Messrs. Gardner, Garone, McKendrick, Baer, and Macehiter.

Re best-of-breed SOA suites, here’s what I said then (and said more or less the same yesterday, August 3 2007, to Jon Brodkin of Network World, so it’s interesting to see that my fundamental perspective hasn’t altered significantly over the past half-year…or maybe I’m stuck in my ways…you decide):

“Kobielus: …. Over time, we’ve all been seeing this notion of a SOA suite take root in the industry’s productization of their various features, functions, and applications. Now, the big guys -- SAP, Oracle, Microsoft, webMethods, for that matter lots of software vendors -- are saying, ‘Hey, we provide a bigger, 'badder' SOA suite than the next guy.’ That raises an alarm bell in my mind, or it’s an anomaly or oxymoron, because when you think of SOA, you think of loose coupling and virtualization of application functionality across a heterogeneous environment. Isn’t this notion of a SOA suite from a single vendor getting us back into the monolithic days of yore?

This thought came to me when I was reading a Wall Street Journal article earlier in the week about SAP, “SAP Trails Nimble Start-Ups As Software Market Matures.” There was one paragraph in there that just jumped out at me. They said, ‘Some argue that SAP's slump highlights a broader shift under way in business software, in which startup companies wield an advantage over established titans. Under this traditional business model companies buy large, costly packages of software from SAP and Oracle to help them run their back-office functions and so forth, but as the business software industry matures, many companies already have the big software pieces they need, and feel little urgency to replace them.’

So, clearly SAP is then sort of a driver in the SOA suite arena for few years with NetWeaver. Is the notion of SOA suite an oxymoron? Are there best-of-breed-suites? There are also best-of-breed SOA components, and I’m not sure that the notion of a suite, an integrated suite is really what companies are looking for from SOA. They want best-of-breed components with the assurance, of course, that those components are implementing the full range of SOA standards for heterogeneous interoperability. So, I’m taking issue with this notion of a ‘best-of-breed’ suite.”

Of course, I’m hyperguilty of using the term “best-of-breed” all the time in my coverage of the Data Management space. Here’s where I should declare how I construe it, and why I feel it adds value to my discussions of “who’s on first (second, third, fourth, ….nth) in BI, DW, DBMS, DI, DQ, MDM, CPM, CEP/ESP, EII, ETL, GRC, etc.,” so that I can make my peace with it in the sphere of “SOA suites.” Essentially, a “best-of-breed” (let’s call it “BOB” for short) vendor, solution, or product is not “the best” one on the market, but rather one that, for some well-defined market segment, satisfies some weighted/composite metric of a) functional breadth/depth, b) installed base/adoption, c) maturity/stability, d) integration/sophistication/evolution, and e) price/TCO. Fundamentally, BOB is a “shortlisting” criterion: it refers to one or more strategic vendor/supplier/providers in a particular segment that offer enterprise-grade, robust solutions and are worthy of deeper consideration, investigation, and evaluation by enterprise IT.

That said, I agree with the following observations by my fellow panelists that morning:

“Macehiter: ….We have to recognize that organizations increasingly are looking to rationalize their supply strategy. So, they’re increasingly looking to deal with a smaller number of vendors and suppliers, which is, in part, driving the move toward larger vendors attempting to offer a suite or portfolio of product capabilities that can help organizations manage the lifecycle of an SOA initiative….Companies are putting together a bunch of products under a common brand, whether it’s Oracle Fusion, SAP NetWeaver, or under the IBM WebSphere brand. [It’s important to consider whether the products under these brands actually] are well integrated and that they have a common management environment, common configuration environment, and common policy definition environment.”

”Garone: All of us on this podcast today know that the debate over best-of-breed versus integrated-stack approach has been going for many years in a variety of scenarios and contexts, and it hasn’t stopped. I don’t really like the word "suite." It reeks more of marketing than functionality. [What customers want is] an open environment where they can pick and choose and not be tied to one vendor, what overrides all this is a desire to get things done quickly, efficiently. They want a way in which they don’t have to be concerned about integrating a lot of products and what that entails, and having potentially an unreliable environment. What that points to is working toward one vendor. End users will do that even in the short term by choosing someone that they know they can grow with in the future.”

“McKendrick: … Now, Oracle is an interesting case. When I think of suites, I think Oracle demonstrates the best tendency in this area. In fact, they called their offering ‘The SOA Suite,’ and they include a number of components. I have spoken with some companies that have Oracle installations. Now, it should be noted that typically the customers for these suites are the installed base. The people who will be buying into the components of the Oracle SOA suite are companies that either have the Oracle applications, the E-Business suite or the Oracle database underneath. And, in most cases, they are buying into components of the suite.”

“Baer: ….. There is always going to be a tension between homogeneity and heterogeneity. For the customer, it’s going to be dictated obviously by what is already in place, basically as Joe [McKendrick] pointed out. If 60 percent of my functionality, or even say 30 or 40 percent of my functionality, is SAP, I’m likely to listen when SAP tells me about a NetWeaver Solution…..[The] fact is that at the infrastructural level, there is a desire to have consistency. I don’t want to have five security engines. I don’t want to have three different authentications, if possible. Obviously, we’re never going to get that one, centralized identity repository in the sky, but I want to at least have my management framework be as consistent as possible and to manage what will inevitably be, in most large organizations, a federation of different installed bases of different technologies.”

“Macehiter: …. We have to be careful to distinguish between the infrastructure that you require to enable SOA initiatives and what you’re trying to enable with that service-oriented initiative. Just because you want to have a loosely coupled component that you can combine in multiple ways to deliver business outcomes, doesn’t mean that the infrastructure that underpins that has to be similarly loosely coupled and based on the heterogeneous offerings from different vendors.”

And here was me, then, splitting the difference and attempting to sum up what seemed to be the consensus of the panel that morning (and, I assume, still):

“Kobielus: I agree -- I think that the notion of a best-of-breed SOA suite makes more sense from an enterprise customer’s point of view. Most enterprises want to standardize on a single vendor and a single stack for the SOA plumbing -- the registries and repositories and also the development tools. They want the flexibility to plug in the different application layer components from Oracle and SAP and others, that are SOA-enabled and that can work with that single-core-plumbing-stack from a single vendor.”

A minute or two later, Dana moved the discussion toward one of my core focus areas at Current Analysis: master data management (MDM). I don’t recall if I’ve laid out my MDM/SOA framework in this blog before (I assume that I have…so, in a Morrissey vein, stop me stop me stop me, stop me if you think that you’ve heard this one before…or just fast-forward past the following bullets:

• SOA is a paradigm that focuses on maximizing reuse, sharing, and interoperability of valuable enterprise resources over distributed networking fabrics.
• Master, official, reference, scrubbed, corrected, standardized, normalized single-version-of-truth recordkeeping data is one of the most valuable/indispensable enterprise resources.
• MDM refers to the ecosystem of repositories, solutions, applications, components, tools, workflows, roles, rules, etc, that support lifecycle governance of master data sets, so that this “gospel” data can be maximally reused, shared, interchanged, etc in BI, CPM, BPM, ERP, CPM, and other applications throughout the enterprise, supply chain, etc.

That said, Dana framed the MDM-as-SOA discussion quite well that chilly late-Jan morning:

“Gardner: “We [he and Ash Kulkarni of Informatica] had a really long, interesting discussion about the role of data, master data, and metadata when it comes to moving toward SOA. We really shouldn’t lose track of the fact that as you move to applications as services, and you go loosely coupled, and you adopt more reuse across development with common frameworks, and use rich internet application interfaces -- what about the data? The data has to be managed as well. Increasingly, companies that have had mergers and acquisitions, or have just gotten myriad applications with varying views of something as specific as a customer identity -- there might be 10 or 15 different views of a customer, as defined by a variety of different applications. How do you manage that? And when you think about the progression of the data, it seems to me that if not in actuality, in a virtual sense, you want to become centralized with your data so that data can be used in a clean and impactful or productive way across all of your services.”

Then I uttered a short version of the MDM-as-SOA framework that I just now bulletized/expanded in this post a moment ago. Not going to excerpt that here, but I do want to re-present the following excerpt from I uttered then, in which I pointed out that MDM need not be implemented in a centralized fashion (departing from Dana had just stated or implied), but, rather, could leverage enterprise information integration (EII)—aka “data federation”—fabrics for unified governance of decentralized master data sets (this is an extremely important point in the MDM Maturity Model upon which I’m basing my growing body of vendor-specific MDM Solution Assessments for Current Analysis):

“Kobielus: ….[T]here are a lot of enterprise information integration (EII) vendors out there. EII revolves around really federated MDM, where you keep the data in its source repository, and then provide a virtualized access layer. This allows your business intelligence and other applications to access that data through a common object or model and a common set of access schemas -- wherever that data might reside -- but facilitated through a virtualized access layer. That’s very much EII as implemented by Business Objects, BEA, [IBM, Sybase, Composite Software, Red Hat/Jboss/MetaMatrix] and many other vendors, and is very much the approach for federated MDM.”

After we’d explored that theme for a few minutes more, then we moved into a discussion of the “new enterprise architect,” re the career path for SOA developers, integrators, analysts, etc. Here’s how Dana framed discussion on that topic, which was proposed by Joe McKendrick:

“Gardner: ….”There are a burgeoning number of critical skill sets that need to be applied to SOA. We’ve talked about data, whether it’s cleansing, transforming, virtualizing and approaching some sort of a MDM capability. We have talked about development and process, BPEL. We talked about infrastructure. There is the management, the architectural overview, and what’s our philosophy. It seems like we’re going to need a lot of very skilled people who are both generalists, as well as highly specific and technical. Because for SOA to work, a bunch of people who are highly specific -- but don’t share the same vision or have a general sense of the strategy -- probably won’t fare too well.”

Joe’s take on the topic:

“McKendrick: [Ron Schmelzer of ZapThink] is sounding the alarm bells that the folks that we need to drive SOA forward in the enterprise is this class of enterprise architects and enlightened architects, if you will. There are a lot of SOA projects everybody is interested in. Everybody’s kind of ginned up about SOA now, and we’ve been hearing about it. Enterprises really want to begin to either pilot or move SOA past the pilot stage, and 2007 should be a big year. Schmelzer feels there may not be enough architects who can take this high-level view and drive this process forward. Now, it’s interesting, but when I posted this on my blog, I got lot of feedback that perhaps architects are not the only ones who can really lead this effort. There are plenty of developers out there, high-level developers, who can also contribute to the process and interact with the business. The key behind this argument is that you need folks who know what’s going on technically, but can interact with the business. It can be a rare skill to have both.”

My two-cents on it, pointing out that such IT skills deficits are usually short-lived, as smart people quickly get the requisite training, or rise to the challenge, in order to seize these money- and career-making opportunities while they last:

“Kobielus: … Not to get reminiscent or anything, but 10 years ago, when we started seeing Java ramp up, we saw a lag there as well. A lot of organizations were really hungry for Java developers, and the universities came through with more focus on it, but later than probably most organizations wanted. What will happen here is that while this ramp-up goes on, we might see a lot of new business and new interest in service organizations that can provide the professional services required to get people through it.”

You can read the full transcript for the panel’s foreshortened discussion of this topic (we were near the end of the allotted 45 minutes and were trying to wrap it up gracefully). The highlight for me was Neil Macehiter’s take:

“Macehiter: “… the key skills that are required [revolve] around being able to interface with the business. One of the skills and attributes that you also need as a SOA architect is really this ability to balance supporting short-term business outcomes but keeping an eye on the longer-term objectives in terms of gaining high quality and maximizing IT value. That’s an equally difficult skill because too often architecture historically has been focused on quite discrete initiatives or infrastructure. I’m thinking about server architecture or network architecture rather than this broader perspective. There are skills occurring from such things as Oasis and what they are trying to do around things like SOA blueprints.”

All of which gives me a sweet seg-way into the core of my chat yesterday [once again, Fri Aug 3 2007—a week in which Dana didn’t convene the podcast panel] with Jon Brodkin of Network World, who was interviewing analysts, enterprise architects, practitioners, and so forth for a piece he’s writing on 5 tips for making SOA be “about the business,” or something to that effect. Over the half-hour or so that we spoke, I cobbled together the following 5 bulleted tips (I’m paraphrasing myself, since I generated them on the fly and didn’t write them down till now):

1) Banish the phrase “SOA” from your business vocabulary, and only speak in terms of the business metrics, benefits, ROI, etc from implementation of the principles associated with this approach.

2) Boil down SOA’s business metrics/benefits/ROI to the fewest number of actionable words (e.g., agility, modernization, consolidation, rationalization, simplification, optimization, rightsourcing) that can be used to justify/explain SOA-related projects to all business and IT stakeholders.

3) Establish an internal SOA planning/governance practice, under a broader business and IT governance umbrella, that can evaluate, approve, and authorize new SOA-related development/integration/infrastructure proposals for feasibility/ROI per clear corporate-standard metrics.

4) Implement a runtime SOA governance infrastructure/operations to ensure that the end-to-end fabric/ESB/app-infrastructure continuously complies with corporate business policies, SLAs, etc.

5) Provide all SOA governance participants/stakeholders—business analysts, enterprise architects, IT developers, operational personnel, etc.—with a common visual modeling/management framework to catalyze and maintain a consistent, consensus view of the shared environment on all levels, from high business level through drilldown to low-level “plumbing” details, per the needs of each stakeholder.

Or something to that effect. I’m curious to see if/how Jon quotes me in his article, or just paraphrases some segment of the thoughtstream.

Then again, it’s good to have this blog so that I can paraphrase myself, and thereby nail this stuff conceptually to my personal persistent arsenal. And you, all you enterprise architects out there, you’re more than welcome to stick these SOA business-oriented bulletpoints in your arsenals.

Jim

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

thenagin The SOA Shrink-Wrapping Metaphor

All:

Then:

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

Again:

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…..here’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?):

*****************

AN ANALYST’S LISTS

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.

Jim

thenagin The SOA Fungus Metaphor

All:

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

Again:

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?..you 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.

Jim

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

All:

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 www.briefingsdirect.com 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.

Jim

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

All:

Recently, I came across the "2007 Semantic Web Challenge" at the O'Reilly XML Blog (http://www.oreillynet.com/xml/blog/2007/07/2007_semantic_web_challenge.html). 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 Del.icio.us, 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.

Jim