The Emperor, his attire and a Genius

David Chappell has had a long history of stating the obvious. It sounds like an easy task but it is not when an industry tends to embrace FUD rather than fact. His ability to cut to the chase and put things in context really made me a big fan (something that does not come easily).

David’s latest post exposes a few similarities with a popular activity a decade or so ago and SOA. In 1996, everything was an “Object” and if you didn’t make your IT infrastructure into objects, you were doomed. Well, its’ ten years later and many are claiming the same thing with SOA and services. Zapthink’s book also puts this into perspective (good reading – I encourage you to take a look).

Rather than repeat David’s article, I whole heartedly encourage you to read it. It should stimulate some thinking on SOA. Some of my thoughts follow.

Rather than pitch “reuse”, I like to think of “re-purpose” as the goal of SOA. Reuse means you simply use something again where re-purposing it has far stronger business connotations. Juxtaposing reuse with repurpose, I prefer the latter for accuracy’s sake but want to clarify that I did infer the meaning in David’s Opiniari.

David asks a very pragmatic question – “If an organization reuses only one in five of its services, why is it building the other four?”. Do you like my new services / clothes? What do you mean I am naked?

There is of course the business driver of isolation. Using a service as an action boundary that cleanly separates two systems or pieces of functionality does make it easier to maintain those two pieces. The service isolates the functionality behind it and the consumer on the other side of it in a concept called Managed Transparency, a core component of Chris Kurt’s Web Services Architecture book. As long as a new piece of functionality replaces the existing one AND supports the service interface, you should be able to replace it or amalgamate it with another system without ripple effects on the other side of the service. Many business people have touted this as a win scenario to me. David and I are not alone, other great thinkers like the brains from Redmonk also see this pattern.


I think David’s article can be summarized in one sentence – “Think about what you are doing before doing it”. Like the carpenter’s axiom “measure twice cut once”, IT shops have to start looking at the layers above and below [ pick one: {objects || services || web services || API’s || whatever_we_call_it_tomorrow }]. Some of this starts with business process analysis. If a corporate analyzes their processes and discovers several use the same functionality (like single sign on), that is often a good candidate for “re-purposing” and might make a great service. Others, such as finding a specific telephone number for an employee’s cell phone, are probably too specialized and easy to solve via other means and would not be ideally suited for building into a service. A more generalized service to find any employee’s phone number of “number-type” might be a better consideration.

To those of you who are panicking to make everything a service, heed David’s words about the object craze. Slow down, think about what you are doing. To those of you who are advocating everything should be a service, look in the mirror to make sure you not naked.

Ciao!