I went to a talk on BizTalk and ESB at lunch today that was sponsored by the local connected systems user group. Like many terms in this space (SOA and governance to name two others), ESB doesn’t seem to have a consistent definition. The industry seems to be inventing terms at a fair clip as vendors attempt to differentiate themselves on what to me seem like fairly minor solution aspects.

Today’s speaker talked at length about a “large health care company in California” that he had personally worked with, building an ESB for them with BizTalk. He spoke in glowing terms of the size of the BizTalk environment and the number of messages passing through the bus every day. Then someone asked how many systems this unnamed company had hooked up to the bus. He paused, then admitted: “Six”.

Six? Not six whole systems! That’s gotta be a record!

Of course, I realize that there are deployed ESB’s out there that are integrating more than six systems. My group – the Integration Center of Excellence (ICoE for short) – runs a comparably sized BizTalk environment and we’re connecting around 50 internal systems and hundreds of external partners. But 50 is still a fairly small number. I can’t help but wonder how well will this ESB approach is going scale as the number of systems goes up a couple orders of magnitude. Frankly, I think the answer is “not well”.

The problem I have with ESB is that it’s a centralized approach. Given that one of the overriding trends of society in general and IT in particular is decentralization, the ESB approach feels like it’s swimming against the current instead of with it.

As an analogy, consider how well would the Internet work if every connection went thru a central hub? See what I mean? Centralized systems don’t scale like decentralized ones do.

I admit that there are scenarios where ESB-esque technology solves a practical problem. Transport adaptation and content based routing leap to mind. Services that need those capabilities should leverage ESB-esque technology. But whenever I listen to ESB proponents, I feel that the need for these capabilities is exaggerated to the point that every message exchanged between every service inside your enterprise travels on a central bus, which doesn’t seem realistic to me.

Am I wrong about this characterization? Do ESB proponents think that all messages must travel on the bus? How about you? What do you think? Inquiring minds (aka me) want to know…

Over the past couple of weeks, I’ve gotten a chance to spend time investigating the Guidance Automation Toolkit. For those who aren’t familiar with GAT, it is the underlying enabling technology that powers p&p’s Software Factories. Several of p&p’s factories include data access guidance, but that works against an actual database rather than a VSTDB project. Given my newfound love for VSTDB + my interest in GAT, I thought I would whip up some simple automated guidance.

The key word in that last sentence is “thought”. Turns out that authoring guidance in GAT is extremely unfriendly. GAT’s unit of automation is called a recipe, which consists of arguments, wizards and actions. Arguments are GAT’s equivalent of variables, wizards gather argument data from the user and actions execute changes to the solution based on the values of the arguments. There’s more granularity to the GAT authoring model – for example, GAT arguments have optionally have value providers and converters (which should be called validators) – but you get the basic idea.

What makes GAT so hard is that all these recipe elements are wholly independent. This makes individual recipe elements easy to write and recipes fairly modular, but at the cost of making recipe very difficult to write. Your recipe has to define both the list of these elements that it uses as well as their interconnections. For example, arguments optionally contain value providers and converters. They are exposed to the user in wizards as either custom pages or arguments. They are fed into actions as input parameters. Action input parameters can also come from the output parameters of other actions. All these interconnections have to be hand coded in XML with fully specified type names like “Microsoft.Practices.RecipeFramework.VisualStudio.Library.Templates.TextTemplateAction, Microsoft.Practices.RecipeFramework.VisualStudio.Library”. Ugh.

The good news for GAT is that help is on the way. Clarius’ Software Factories Toolkit includes a graphical domain specific language for authoring recipes. With that tool, you can pick the various recipe elements from a list and connect them graphically instead of hand coding all of that in XML. But why do we have this problem in the first place? How much are we gaining by using this XML format in the first place? Frankly, I don’t think very much. I think it would make more sense to define recipes in code than XML.

I was talking to Michael Lehman about Project Glidepath, which is built on GAT. However, Glidepath only uses GAT for integration with Visual Studio’s menu system (which seems much more difficult than it needs to be, but that’s a separate post). Instead of GAT’s recipe system, Glidepath plugins simply expose an Execute() method. Within that method, the plugin can do whatever it wants. Michael showed me the code behind the Vista Bridge package, and it is MUCH simpler than the GAT equivalent. I could see having a little more structure than just Execute(), but GAT seems like overkill in comparison.

Sometimes complexity is necessary. But I can’t help but think that GAT’s complexity wasn’t really necessary. Wouldn’t it have been simpler and just as modular to define a recipe in code instead?

Conceptually, I like both Service Oriented Architecture (aka SOA) and Software as a Service (aka SaaS). However, I think we’ve done the industry a disservice by overloading the term “service”.

John deVadoss likes the following definition of SaaS from Wikipedia. So do I.

Software as a service (SaaS) is a model of software delivery where the software company provides maintenance, daily technical operation, and support for the software provided to their client. SaaS is a model of software delivery rather than a market segment; it assumes the software is delivered over the Internet. Software can be delivered using this method to any market segment including home consumers, small business, medium and large business.

To paraphrase, SaaS is software that traditionally you might have bought, installed and run yourself but instead now can access over the network where someone else is responsible for installing and running it. For example, instead of buying, setting up and managing my own mail server to handle a single @devhawk.net email address, I use the WL Custom Domains service.

SOA on the other hand isn’t a model of software delivery, it’s a model of software segmentation. Again, here’s the Wikipedia definition, this time for SOA:

There is no widely-agreed upon definition of Service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle.

Err, that’s not very helpful. Let’s check out the OASIS definition (cribbed from Wikipedia).

[SOA is] A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Well, at least it’s not a self-referential recursive definition. But it is littered with committee-speak. (Who talks like that in real life?) Frak it, here’s my definition:

SOA is a way of implementing IT systems as a web of interconnected yet independent loosely coupled subsystems (typically called services) instead of as big honking systems we have traditionally built that tend to be unwieldy, in-agile, difficult to change and probably obsolete by the time they were deployed.

We could argue about the language, but you get the point. There would be a ton of argument about the size of the subsystems (i.e. the service granularity), but I think most people can agree that SOA encourages building multiple smaller interconnected subsystems instead of one big (honking) system.

Which brings me back to my original point: Service, in the SOA sense, describes the approach to factoring parts of an software solution. Service, in the SaaS sense, describes a software delivery mechanism. Certainly, you can use both together and take an SOA approach to building a SaaS product. But you don’t have to. So having the same term “service” used in both is very confusing.

How many SaaS products use SOA today? I would guess “not many” since there hasn’t been much demand for it. When you’re selling to the long tail of the LOB market, support for service-oriented integration isn’t a critical selling feature. As SaaS becomes more attractive to larger companies (i.e. ones with dedicated IT staffs), using a SOA approach will be more important to SaaS product vendors. So they will converge in a way, but not in the way their naming suggests.

Of the two uses, SaaS seems closer to the dictionary definition of service. Maybe the S in SOA should stand for “Subsystem”? Nah, I like the term “connected systems” better than “service oriented” anyway.

• From the “Ask and ye shall receive” department: A couple weeks ago I wondered how good or bad my Gamerscore conversion rate is. MyGamerCard.net just launched a completion leaderboard where they rank you on your Gamerscore times your completion rate.
• Shane Courtrille pointed out that the prize you receive in from the Xbox Rewards program gets better if your Gamerscore is higher. With a meager 1090 points, I’m in level 1. But those with 10,000+ or more can get a copy of Fuzion Frenzy 2 for completing the challenge.
• Yesterday, I complained that code in my RSS feed looks awful. It appears to be a problem with dasBlog. In validating the HTML is actually XHTML, it screws up the white space. Of course, usually that’s not a big deal, but inside a <pre> tag, it is. Until I get a chance to submit a patch to dasBlog to fix this, I’m using CodeHTMLer, which has a “convert white space” option that doesn’t use the <pre> tag at all. As a bonus, it even support PowerShell! Note, you have to use the website, not their WLWriter plugin, if you want the convert white space option.
• There’s a new beta of Ruby.NET available. Now that I’ve moved on to PowerShell, I’m only slightly interested in Ruby these days. If I can figure out how to create internal DSLs with PS, what would I need Ruby for? (via Larkware)
• My old team just shipped a single-instance multi-tenancy SaaS sample called LitwareHR. Details are on Gianpaolo’s blog, code is up on CodePlex.

• I wonder what MSBuild would look like if the team had cloned drawn inspiration from Rake instead of Ant. Seems that PowerShell would have made a great foundation for build scripting.
• Looks like the digital music business is about to undergo a dramatic shift. Nick Carr and Mark Cuban have more on the possible ramifications. A friend of mine is about to move over to the Zune team. Sounds like a good time to making that switch.
• Anne Manes of the Burton Group says the time is right for UDDI, calling it the “foundation for governance”. Frankly, I think that gives UDDI a lot more credit than it’s due. We’re looking at UDDI as part of our SO infrastructure project, and I think it’s more appropriately called “one piece of the puzzle”. In my experience, the major roadblock getting projects to share technical details is desire, not discoverability. Getting information into the registry is much easier than getting teams to use that data rather than succumbing to Not Invented Here syndrome. (via Joe McKendrick)
• Jeff Snover of the PowerShell team left me a comment the I “get” PowerShell. “Getting” it may be a better description, but it’s nice to see how well engaged the PS team is in the community.
• After 13 long weeks, Lost is back!