05/23/08 :: [SOA] The fundamental achievement of SOA [permalink]
Many pundits have criticized SOA for not delivering the kind of reuse that was once promised. Creating reusable IT assets is not easy, yet it is the fundamental goal and therefore achievement of a Service Oriented Architecure. There are at least 3 things you need to do right to achieve measurable reuse:
- Governance
- Versioning
- Loose coupling
Governance will only get you so far. It's good to bring every potential service consumer at the specification table, but you can rarely predict the kinds of scenario a service will support beyond 12 months. There is also a cost associated to governance (in analysis, design and implementation) that's important to access and minimize.
I talked quite a bit about versioning with Pete Williams. It sounds like we were able to proceed with logical arguments. What I call forwards compatibility is very important to achieve -this is not easy again, and easily overlooked. Forwards compatibility is when a service consumer of version m.n can consume the versions of a service from m.n to m.n+p (m represents the major version, n the minor version and p an arbitrary increment of the service). Versioning is key to reuse because as new consumers come on board, they will require minor changes. No other technology before web services (that I know of) ever supported forwards compatibility. You really need it because you never want to tell an existing consumer that they have to change anything when a new consumer comes on board nor do you want to support a version of the service for every single consumer.
Last but not least, loose coupling. Neither governance or versioning are perfect. You want to build your reusable assets within containers that support loose coupling (for both the consumer and the provider), just in case. I provided some comments here on how an ESB and SCA can complement each other very nicely in that role.
So if you fail to establish an efficient governance, if you fail to establish a versioning strategy that can tolerate changes to the service without propagating those changes to the existing consumers and if you fail to understand the principles of loose coupling and choose a programming model that allows you to assemble consumers and providers efficiently, you will automatically fail your SOA implementation, will experience little or no reuse and conclude that SOA is just vendor markitecture. The irony, is that very few of the vendor white papers would tell you what I just wrote.
In the near future I will talk about how you can connect governance, service design and logical data models. This is an important aspect of achieving reuse as well as it helps get service message types right.