elemental links

"Service-Oriented World Cheat Sheet"

My "Service-Oriented World Cheat Sheet" report is currently being offered as a free download at Patricia Seybold Group.  Beyond my SOA definitions, the report speaks to key technologies, the SOA landscape (I take a service-oriented view of the SOA environment), and shares some keys for success.

If you've read the excerpt on nextslm.org or enterpriseleadership.org, then skip ahead to the "Technology Landscape" section, on page 4.

Cape Clear's SOA Architects' Forum: SOA Centricity and Standards!

As mentioned in my SOA methodology question post, I had the opportunity to attend Cape Clear’s SOA Architect Forum in Boston. The forum attendees were predominantly enterprise IT professionals, and IT consultants (large firm and boutique) who specialize in integration and/or SOA.

Chris Riley and Andy Wall (engineers/SOA practitioners, not marketers) from Cape Clear did a great job speaking to SOA concepts and practices, supporting standards (Web Services (SOAP, WSDL, UDDI), XML (XSD, XSTL, XPath, XQuery), WS-RM, BPEL), and of course, introducing and demonstrating the Cape Clear ESB.

Although it would be premature for me to comment on the product itself – I want to take it for a spin myself first – there are points I do want to cover, which will lend insight into Cape Clear’s architectural premise.

From the onset, I could tell the forum wasn’t just about selling Cape Clear’s ESB, it was also about evangelizing SOA. Not pound on the podium evangelism, but rational, informative evangelism. My quick recap of Cape Clear’s SOA message:

Why SOA?

• Business benefits: agility (time to market, responsiveness), real-time visibility, better regulatory compliance
• IT benefits: reuse, responsiveness, developer productivity, standards based, innovation catalysts

What SOA?

• Architectural Approach
• An overarching layer, exposing existing IT assets as business services

How?

• Standards based: use the Web Services family (WSDL, SOAP, UDDI, WS-*, BPEL)
• Interoperable: invocation and discovery, XML Schema
• Smart Service Definition: implementation independent, loosely coupled, coarse grained, documents rather than RPC, asynchronous and synchronous
• Incremental: start with a project, work your way to the enterprise
• Business-Driven: partnership between IT and business, smart investment, measurable payback
• Governance: service library, data models, reference deployment architectures

How Not?

• Do NOT derive service definitions from existing code
• Do NOT model the technology, model the business!
• Not Message Centric, but SOA Centric

At a glance, not many surprises here. Good SOA fundamentals. Good Technology practices. Good Business focus. Good advice for the attendees.

What’s important to note though, is this advice doesn’t just pertain to the attendees; it pervades the Cape Clear ESB. This brings me to their architectural premise. The Cape Clear ESB has been designed and developed with the following in mind:

• A document (or noun) view of services; REST architectural style, but not (XML/HTTP) technical implementation model
• IT assets, now and the future, will be heterogeneous, however interoperability will be achieved through standards; specifically, WS-* standards
•  Incremental wins the day. Offer functionality that people are ready for, and that is ready for consumption.
• Invest for innovation. Cape Clear has hand developed the internals of the ESB engine, but leverages OSS projects for tooling, and object/relational persistence.

And the big points…

• SOA Centric, not Message Centric. Within the Cape Clear ESB, the integration services (data translation, interceptors, etc.) run as Web Services, and interact using WS-* technologies.
• Standards, Standards, Standards!

So, a good way for IT professionals to learn about SOA and Cape Clear. It was great to see the emphasis on imparting knowledge, and fielding tons of interesting (but at times tangential) technical questions, rather than a hard product or service sell. It was also nice to hear the same messages from his team, as I heard from Annrai himself, when we spoke of Cape Clear’s vision.

Next, for me on Cape Clear, is to take the ESB for a spin. Now, if only I had screen shots of the design and development of the phone provisioning scenario to get me started…

Changed my Feed to FeedBurner

I just changed my feed to FeedBurner, in order to splice in relevant links from del.icio.us.

While the old feed still works (never break an interface), to receive posts + my del.icio.us, please subscribe to the new feed: http://feeds.feedburner.com/ElementalLinks. 

On the site, you can grab the feed from the orange XML syndication icon in the right-hand column.

SOA Architects’ Forum – An Interesting Question

Last Wednesday, I had the opportunity to attend Cape Clear’s SOA Architects’ Forum in the Boston area. While it was my intent to write about the forum last week, a question posed by an attendee at the end of the day propelled me down a research rat hole from which I’ve yet to fully emerge. The question, innocent enough, was “Where do service definition activities fit into mainstream development methodologies, such as RUP?”

From my own experience, service definition activities span business modeling, analysis and design. You find a service (and the need for it) during business modeling. You define and refine the service during analysis. You further refine and provision the service during design.

I think there is general agreement on the above – perhaps not in “how”, but definitely in “what”. Cape Clear certainly made their perspective known early in the forum, with a slide that said “Model the business, not the technology”. (Yes!)

However, the larger question – the how – and the fit of service practices and related artifacts in industry accepted methodologies – is still open. Certainly, methodologists, consultants and vendors are all (independently) circling the question, with MDA, UML 2.0, SOAD, SOMA and SOBA.   

But, I have yet to find (and welcome references to) a publicly available, cohesive, services-oriented modeling/analysis and design methodology. I should note, I am eagerly awaiting the release of Thomas Erl’s second SOA book, to dig into his chapters on service-oriented analysis and design.   

I suppose it is too early for fully formed methodologies to appear. After all, the best methodologies -- those that apply the right amount of methodology to accomplish a task, no more, no less -- evolve over time, through real-world practice.

But, it’s not too early to be thinking about unifying service-oriented architecture practices, and even, to start doing something about it. If you know of, or are interested in, such an effort let me know.

In the meantime, I’ll continue my research, and report back my findings.

Oh, I really will post about Cape Clear’s SOA Architect Forum; it was good, well worth the time. 

Blog Biology…Linking up the Food Chain?

Last Tuesday, I posted a seemingly inconspicuous entry on the need to understand the architectural intent of the provider of your SOA and integration infrastructure. In the entry, I provided names and links to some thought leaders in the service-oriented architecture (SOA), integration, and event-driven architecture (EDA) spaces that I had the opportunity to speak with (and learn their architectural leanings).

One of those links, for Michael Terner of KnowNow, happened to reference a Jon Udell podcast from December 2004. And that single (coincidental) link, made for an interesting day for me on Thursday, when Jon wrote this piece about Blog Biology. In it, he describes how he found me through his sensors (Technorati and his referral log), and how it makes sense that we would eventually meet given our common interests in SOA and EDA, but this one oblique link (of mine) expedited that meeting.

Why that link made for an interesting day (days really) for me is threefold. First, Jon’s “reinforcing the connection” introduced me to his large readership. Second, one of my free works that I am sharing was picked up by ZDNet’s Between the Lines. Third, in a reinforcement of “a cool thing about my job is I get to talk with a lot of smart people”; I had the opportunity to chat with Jon this morning about SOA.

Not bad for one link. So, that got me to thinking about blogging and linking. Because for me, technology is most interesting for what it allows us to do—for our businesses, our lives and society. [Although, I must admit, occasionally I’m drawn to a technology because it’s cool.]

On linking, many companies employ “Google Gaming” strategies for high search placement (results and ads). But, I wondered, can an individual link their way to inclusion? Look at what happened with my one link.

So, if (for the sake of illustration) I started being intentional (and incessant) in my links, targeting high influence individuals and communities, would that provide me entry? Or, would my appearance (my URL) on blogosphere sensors become the equivalent of spam? Forever, relegated to being filtered out (ouch!)

Gut feel says, the latter…because the overall connection has to be stronger than the initial (one-way) link. There needs to be relevance for all parties. The blogosphere, after all, is opt-in.

Jon’s post speaks to manufactured serendipity, which essentially says the technology of the blogosphere makes the useful discovery of ideas, individuals and groups less accidental, or somewhat manufactured.

Although these interactions are prompted by technology, there is still something natural at play. There has to be a reason/force – shared interests, views, friends, or associations – for any link back, and forward introductions. This is what promotes a one-way link to an actual connection. Which, in this instance, were SOA and EDA.

So, I worked myself around to “No, an individual can’t just link their way to inclusion”. I believe the natural forces of the blogosphere would protect serendipity despite any manipulation of the manufacturing. This is good…