Perhaps I’m just grumpy this week. Or, concerned for the future. Or, most likely, both. Nevertheless, I find conventional SOA lore more bothersome than usual. Specifically, the paired notions that the sole reason to implement services (or not) is re-use potential, and that the main architectural aspect of SOA is governing said services for re-use. Now, don’t misinterpret, there is true value in sharing services and governance is critical. However, SOA, or better said, services-architecture doesn’t begin and end with re-use potential and enforcement.
For those with architectural backgrounds – software not marketing trend – what follows is nothing new. You are well acquainted with foundational tenets such as separation of concerns, modularity, loose coupling, cohesion etc and the associated benefits. Unfortunately, based on my interactions over the last several months, I must report (a) this knowledge is not universal (b) people can’t articulate the benefits of well-architected software and/or (c) the dots don’t connect all the way to SOA.
Since the presence of well-defined (and well-built services) is assumed in a bevy of existing and emerging technology strategies — mashups, event-processing, business process automation and cloud computing — we need to correct the record on the total value of services and make the connection to proper architectural discipline.
