How Can You Implement SOA without an Architecture?

Michael Meehan writes, in "Having trouble with SOA? Pay attention to the architecture," that he has never seen a successful SOA implementation story that did not feature an architecture.  He goes on to write, “If you can’t produce a representation of your architecture and then demonstrate that you’ve actually built systems in accordance with that architecture, then you can’t claim to be doing SOA.” As one commenter on Michael's blog wrote, it is asking the right question.

I would extend that you can substitute just about any enterprise technology for SOA in this statement, whether that is an ESB or even a Java server. I think it needs to be said, even if it is a "duh-yeah, of course" statement.   

I am constantly amazed that people think about implementing any complex technology without creating an architecture, but they do. At the risk of being corny, SOA without the architecture is SO? Michael goes on to say that the top SOA development challenge listed in their surveys is the lack of skills.

The demand for architects who can design SOA is greater than the supply.  In this kind of environment, you see a lot of both premium outsourcing, and training of the necessary skills for handling both changing business requirements and complex integration processes. We try to instill this with customers by training them on the paths of least risk and resistance in the architecture phase, so there is a better chance of delivered quality, while the skills are cultivated.

Unfortunately most architects don't get the luxury of designing an ideal solution, and they are inheriting "the sins of the father..." in their own heterogeneous environment. One of our goals is to try and make the testing and validation process simpler within the tools and offer virtualization to eliminate the constraints of dependency from much of the lifecycle. If those phases move faster, the architect has more time to focus on optimizing new features. However, an SOA tool does not reduce the need for strong architecture skills -- as it is in design and definition where the costliest errors will occur due to bad architectural decisions. And no toolset or platform is going to architect that requirement away from us.

We'll have plenty more to say on this topic. Your comments welcome.

Comments

[Mark Griffin]

Your dead on with this. I have being saying that the design and architecture of services is trivialized. Not near enough focus on the skills required to be successful with this. The exact same thing happened with EAI which is why so many companies struggled with it.