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.