Morning Coffee 95

  • New version of dasBlog is out, the final version on ASP.NET 1.1 (unless this release “kills a kitten” as per Scott Hanselman). I don’t have the time (make the time?) to run daily builds, but I do try and upgrade to new major releases in a timely fashion. I’m also moving hosters, so expect a little downtime around here at some point in the near future.
  • Matt Winkler is doing a series on alternate WF execution patterns. His first is the N of M pattern. While I can nitpick some things in WF – especially the limitations of transaction flow – WF’s support for variability and extensibility of execution patterns is fraking brilliant. (via Sam Gentile)
  • Joe McKendrick is all excited about a SOA built without web services! We’ve been “doing SOA” since the EDI days without web services, so I’m not sure this level of excitement – with an exclamation point and everything – is warranted. But it is good to see people realize web services != SOA. Instead of web services, CERN is using JMS to move messages around. I don’t know much about JMS, but I do know it supports async and durable messaging, two things I think are critical for enterprise services.
  • I saw on LtU that there’s a new paper on Singularity out. For those who don’t know, Singularity is a MS Research platform designed for reliability instead of performance. But there’s more than just a new paper. According to the project home page, “Singularity Version 1.0 is complete. We’ve shipped the Singularity Research Development Kit (RDK) to a small number of universities for their research efforts.” I wonder if I can get my hands on that RDK?
  • Jeff Atwood is starting to show ads on Coding Horror, but he’s donating “a significant percentage” of the ad revenue back into the programming community. He’s starting with $5,000 and Microsoft is matching for a total of $10,000 to be donated to open source .NET projects. Go tell Jeff which projects you think he should donate to. Castle seems to be an early favorite.
  • On Monday, Nick Malik posted what he called the Simple Lifecycle Agility Maturity Model (aka SLAMM) as a way of measuring your “agile factor”. Surprisingly, the community response has been zilch. After Nick’s comments on Agile last week, I figured someone would have something to say about it, even if only to slam it. (Slam SLAMM, ha ha.) Maybe nobody opened the spreadsheet and saw Mort has an agile factor rating of 71%? Personally, SLAMM seems like a rather coarse tool for measuring how agile you are, but coarse tools are better than no tools at all.

The Myth of the Service Catalog

Normally, I would simply note that Nick Malik had finally moved on from the Great Mort vs. Agile Debatetm in my next Morning Coffee post and be done with it. But man, his post on the Unimportant SOA Catalog is just too good to leave until then…

Nick has come around to the view that the catalog does “a really good job of solving the wrong problem”. I agree 100%. I haven’t talked about it much here, but my teammates could tell you I have been on a rampage about this internally. People think a service catalog will create adoption and reuse. That suggests that the big obstacle to service adoption and reuse is simply the issue of finding something to adopt or reuse.

It’s not.

The next PM I meet who says “I wish I had a big catalog of services so I can search for something that I can take an external dependency on” will be the first. And they’ll probably be wearing a straightjacket, because looking for dependencies on purpose like that is crazy talk. Project managers avoidexternal dependencies like the plague. So when a PM looks at a service catalog, what they see a big list of stuff they don’t want to take a dependency on. Not exactly the mindset to stimulate reuse and adoption, is it?

Nick suggests that a catalog might work if it was small (20-50 services) but not for hundreds or thousands of services. I think it’s a culture issue not a scale issue, so I don’t think it would work even for a small number of services. But in the end, it’s a moot point since he expects a large number of services. Different reasons, same conclusion. ’nuff said.

However, while I rail against wasting time building a service catalog that won’t do what everyone thinks it will do, I haven’t had a better idea.

Nick does. The Periodic Table of Services. Go read. More of my thoughts on this later.