If SOA is not a UOA it will be DOA

How many of you remember the days of OOP?  Today’s obsession with SOA, which has enabled an entire new religion, has all the same characteristics of the OOP hype of the 90′s.  I recall being badgered by a so-called architect colleague of mine who insisted that we re-write our top selling product (Quicken) in a complete object oriented fashion.  Now, clearly, I was not so stupid to not recognize some of the benefits of turning some of our iterative mechanisms into internal “services” (SOA is like OOP over IP), and we in fact did seperate out our core internal services into a service oriented structure (it was not OOP, god-forbid, but it worked).  I was assured that if we did not rewrite our C code using C++ (this guy obviously didn’t understand that only Objective C was TRULY object oriented, how could he be so blind!), we would regret it later.

Well, 20 million users later, 80% marketshare, and never missing a ship date, where was he now?  Certainly our success was not a condemntation of OOP, afterall OOP is the standard today, however — it was a demonstration of how to make technical decisions — DO WHAT MAKES SENSE.  Implementation tradeoffs need to be driven by objectives, which typically are USER and BUSINESS objectives — technical purity should only be a means to an end. 

The fun continued… next we needed to build a system in which we could deliver data and information to both our new web community (quicken.com), and our client code.  We designed a very rudimentary HTTP based system which included a “data server” (stock quotes, etc.), and well defined request methods using tag-value pairs in HTTP.  I was ASSURED that if we did not rewrite our system using DCOM (the future of the world) we would live to regret it… we would not benefit from re-use, we would not benefit from security protections, and what we were doing was “just all wrong”, our HTTP interfaces did not self-describe (a big topic of the SOA crowd).  Well, it turns out, we not only built a tremendously successful and leveraged set of HTTP based web services, but did it in a fraction of the time it would have taken to use DCOM.  Those services are still in operation today (as far as I know) — and were easily migrated to new platforms — the HTTP standard just kept working.  DCOM would have been a major headache.   Yes, we didn’t self-describe, so we couldn’t just open our service to the world so other machines could figure it out and use it.  We did make a lot of money though.

What is the lesson for the SOA crowd?  Make your Service Oriented Architecture a USER Oriented Architecture — make it WORK for the problem at hand.  Big enterprise applications will still make sense going forward, don’t try to break all your apps into little modules just for the sake of it – but where it is appropriate to abstract concepts to services (identification, data services, directory services, etc.), then SOA makes sense.

Again… just like with OOP, we get it guys… we get what the world COULD be like if we could just “be there” with a world of interconnected services.  I don’t doubt we will get there someday… but for those who are trying to build businesses, manage internal infrastructure, and ship products today…

just do what makes sense.