Will SOA work?

Yes, no and maybe. How's that for a straight forward answer? I qualify the answer because your mileage may vary when trying to move forward with the concept of SOA. Why you ask? We all know there has been a tremendous amount of hype associated with SOA. Vendors trying to rebrand old products, new vendors try to market new products, and industry analyst touting it as the next best thing.

Remember the 90's when OOP (Object Oriented Programming) promised to make software reusable, cut down on development time, save the world etc. There was a lot of talk about abstraction, encapsulation, interfaces etc. What happened? Why aren't all software shops specifically IT shops using OOP design principals? When is the last time you saw a sequence diagram, a class diagram...? The answer as it turns out is that it is hard and it takes time.

So what happened with OOP? Well some (few) IT shops did embrace it and are still using it today. Some IT shops formed special units or groups to handle OOP. They were the elite developers for special projects. Other IT shops tried it and failed horribly.

It turns out the SOA and OOP have a lot in common. Interface design (think of contract, WSDL in Web Services terms), abstraction, encapsulation are all design principals used in both OOP and SOA (specifically service design). There are differences as well between OOP and SOA (loose coupling, coarse grain versus fine grain etc) but I would argue that the discipline required to achieve the touted benefits are the same. In fact I would put forth that SOA is much more difficult because of the scale and scope of the interfaces.

Software vendors tend to understand these concepts better because the majority of the big software vendors use OOP design principals on a regular basis. IT shops on the other hand are a mixed bag. So if you are an IT shop, I would ask this question. How did you react to the OOP song and dance when it arrived back in the 90's? If you don't have a good answer for that, SOA may not be your thing.