SOA and Reuse
KerrieH 110000JQ5R Comment (1) Visits (1882)
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.