The highly touted benefit of reuse was discussed with several clients today as a benefit of SOA. So I asked the question of who was are target? Who are we trying to get to reuse things and why? Of course the response is we want programmers and developers to reuse code. More on this point in a moment. Another point was quickly raised as to whether reuse has anything to do with service orientation?
Of course a lot depends on how you define and see SOA and service orientation. That is, do you see SOA as purely an architectural style, is SOA the implementation of Web services, is SOA largely and solely for integration or is SOA about flexibility and adaptability to allow for rapid changes in the business whether it be business process changes, business model changes or other? I think the answer lies in all of the above; however, if we focus our attention on only one item we lose perspective. That is, we minimize the value and benefits of service orientation or SOA.
SOA has a business dimension namely promoting business agility, it has an architecture dimension which is both pertinent to business architecture and IT architectures, it has an implementation view, and an operating view. Limiting our view to just one, limits our understanding of service orientation and of SOA. Resulting in less business value and loss opportunity.
But lets get back to the question at hand which is about reuse. SOA is not about getting developers or programmers to reuse code, whether it be a subroutine, an object, a component or a service. SOA is about getting the organization or line of business to reuse things. Its about getting the business to share and to reuse business functionality across business boundaries, betweeen lines of business, within lines of business and across the enterprise where it makes sense.
If we look at why we are trying to achieve reuse its not because of reuse its because we want faster time to market, lower risk in implementation, seamless view of information or lower costs or improved quality where using the same functionality in multiple scenarios, multiple consumers, multiple channels, multiple applications helps. For example, we can actually effectuate faster time to market if organizations start reusing things a lot more than if developers start reusing things. The vast amount of elapsed time which affects time to market is consumed in figuring out what to do, integration and testing, areas where the developer role has minimal participation in reducing calendar time.
So the point is SOA and service orientation can help organizations and business reuse more things in their business but it requires that we use the construct of a service, not just a facade, not just Web services, but a service which represents a key activity or step of a business process. A service which is used as the structuring element of an application. A service which has the same care and feeding as applications. A service which has its own testing life cycle as an application, a service which has its own published software architecture, a service which is an asset the the business and is treated as such.
SOA and Reuse