SOA and the "Contextualization" of Reuse
Oh, what a tangled web we weave.
Earlier today I read a post by Joe McKendrick who was blogging about two blog posts he read (respectively by David Chappell and Harry Pierson) about SOA & Reuse. Reuse is a topic that is receiving a lot of attention from architects, developers, IT Executives, software vendors, etc. I have done quite a bit of SOA related architectural and development work during the last 3 years and in this time I worked with a large number of companies spanning the globe. I also published an article on this topic earlier this year.
After reading the 3 blog posts mentioned above, I decided to jump in and add my voice to the debate.
Harry mentioned that he thinks, "David does a great job blowing the SOA Reuse argument out of the water". I disagree; I don't think David blew the reuse argument away, but rather I think he did a very good job of highlighting some of the barriers that are preventing organizations from gaining desired levels of reuse from their SOA implementations. They key is to challenge people to think about reuse and what it really means within the context of SOA and how one can achieve it. Many assume that by going towards an SOA, reuse will automatically fall into place. This is obviously not the case.
In my opinion the prime reasons for this are organizational issues. Other factors that also play a role include:
- interoperability problems,
- poor internal communication,
- and lack of organizational standards.
David quite rightly mentioned that some organizations are able to achieve significant levels of reuse. I have worked with a number of companies who were able to achieve it. What most of them had in common was the ability to:
- foster a culture of reuse,
- provide incentives for developers and teams to create reusable services,
- implement mechanisms to measure how each services is being used, by whom and how often (this also resulted in their ability to measure the quality of each service),
- implement a governance structure, tools, processes, collaboration workspaces and blogs to facilitate improved communication and thus share knowledge and best practices that helps improve the reusability of the services being created, and
- provide management support to drive the cultural change.
What is important to understand is that each of these companies understood the cultural impact that SOA would have on their organizations and was prepared to drive this change throughout the IT organization so that it became a way of thinking. Again I agree with David, not all organizations will have the same discipline and dedication to these principles and thus they will not achieve their stated goals. To summarize this line of thinking I would say the 3 most important aspects that will impact the levels of reuse within your organization are:
- governance,
- cooperation, and
- incentive.
Harry also posed in interesting question:
"So here's the question: given that general object reuse has seen some success, what's so different about business objects that causes reuse to fail utterly? Since we're really interested in service reuse, knowing why some object reuse succeeds and other reuse fails will help us understand which services are likely to be reusable and which wont."
It is easy to fall into the trap of comparing objects and services. One should keep in mind that Object-orientation is a programming paradigm, whereas Service-oriented Architecture is an architectural approach. The scope of SOA extends beyond just the programming paradigm and thus it is difficult to equate objects with services. Objects generally are only reusable within the programming language of choice, whereas services can be called by consumers regardless of platform, programming paradigm or technology in question. The scope of potential reuse with SOA is significantly larger than in the OO paradigm. Through the use of standards such as SOAP or architectural styles such as REST one is able to connect applications that previously were unable to integrate with each other.
Almost all Fortune 500 companies have significant investments in legacy applications. Many still run their core business on applications that are written in COBOL, PL1, Natural, CICS, etc. and these applications have historically been very inaccessible to other platforms and applications, especially if they are hosted on platforms such as z/OS, OS/400, VSE and many others. The concept of objects simply does not exist on these platforms since most of these business applications were (and still are) written in 3GL or 4GL languages. This explains why companies view SOA as the approach with the most potential of achieving reuse. Not one single organization I have dealt with is either a pure J2EE or .NET shop. This may occur within the SMB market, but it is a very rare occurrence within the Enterprise market (if it happens at all).
Another aspect that caught my attention from the blog post was the following statement:
"A business object on the other hand has significant contextual requirements, which makes reuse difficult or impossible."
I agree this might be the case when dealing with objects, but it doesn't have to be the case when dealing with services. Although the notion of "context coupling" may occur in SOA, it should not be the norm. Services should be designed in such a way that they are reusable, since the consumer doesn't have to know or even care about the service provider's context. The reason why "context coupling" may occur when dealing with objects, is that the business process may be encapsulated within the object. Many companies have fallen into this trap, not only with OO, but also with the older style legacy applications and it is the encapsulation of the business process into the application code that gave rise to multiple and redundant business applications. So the "context" should be elevated to the process layer and NOT encapsulated within the service.
SOA enables companies to remove context through the services that they expose, which gives rise to the reuse of services (such as Purchase_Order_Service) within the business process layer. It is now possible to automate your processes through BPM and many organizations are using this as a method to reduce redundancies and remove duplicate systems through standardizing on a common set of applications. This in turns drive reuse and huge cost savings.
Last year I worked with a major US Bank who exposed one extremely vital calculation routine as a service, which they are now able to reuse throughout the entire bank. This occurred as a result of regulatory requirements they had to comply with. It is possible that the drive for "standardization" may be influenced by external forces that have nothing to do with technology and many companies are finding that SOA and reuse is the way to comply with or accommodate these external forces, as in the example I just used.
It is the combination of loose coupling, standardization, interoperability and the wider adoption of SOA related best practices that is making reuse a real possibility. However it is still up to the individual programmers, project teams and IT organizations as a whole that will be responsible for the ultimate success of their SOA implementations. I think we have a real shot at making this work; the question is do we have the discipline to do it right?


Recent Comments