With so much press, and marketing around SOA, one has to wonder.. just how many projects really involve Service Oriented Architectures? It is certainly the latest and greatest thing, but how many of you are jumping on the band wagon?
At the heart of SOA of course, is an old concept of reuse. Many projects have improved productivity significantly with reuse through patterns. I've heard of insane numbers such as cutting cost of projects by over 50%, along with other statistics. Since none of this I can back up and substantiate now, the numbers are not as important as the concept. I think instinctively we can understand that the more of our artifacts that we can reuse within projects teams/ departments/organizations the more we don’t have to build from scratch, thus saving lots of $$$.
One way reuse is implemented within projects is through patterns and pattern based development. The challenge with reuse is that the components have to be generic enough that that they can be reused and yet specific enough that you still get the ROI from them that you are looking for. Of course, patterns allowed you to do so. Whether it was patterns for company specific frameworks, company security policies or companies login algorithms, patterns are able to be defined to include just the right amount of structural and behavioral logical to be adopted into multiple different kinds of projects. These patterns are then incorporated into projects, with additional business logic implemented based on specific business rules as it relates to that process, department or specific situation.
Many organizations saw the effectiveness of patterns - clearly you are not recreating all components from scratch but are just concentrating on the business logic - and thus many began initiatives to create them.
But many organizations failed at their initiatives. Well "failed" is probably a very strong word – however, many did not get the ROI they were looking for. Is it because pattern based development only works for a few? No! Of course not. At the beginning of this discussion, I mentioned that patterns were a way to implement reuse, and get the most out of reusing your assets. Thus, reuse is the culprit!
Reuse strategies had to be put in place to leverage the patterns that were being cranked out of the factory. Thus, did organizations fail with reuse? Why did they fail? That is an age old question that I am sure has many variables, that I don’t have the space to write about – nor, to be frank, the qualifications. I can tell from my own experience, and working with customers, some things that came up were: as organizations grew more and more distributed, with teams increasingly so, how were individuals supposed to know were those assets and patterns were? Even if they were lucky enough to know where they were, how did they know the right ones for their projects? And, how did they know how to use them? Many actually just re-wrote their assets – because it was faster for them to rewrite their company’s software component for their own use than to understand how it was meant to be used. Clearly, this was counter productive. This could be one reason that companies did not see the ROI they expected.
So.. for some, reuse proved to be the greatest thing since sliced bread, and many best practices and lessons learned were gathered throughout these reuse projects.
Grant Larsen, from IBM, even helped to develop the RAS (Reusable Asset Specification) http://www.omg.org/technology/documents/formal/ras.htm which was adopted by the OMG –to help streamline pattern based development and address some of the issues facing patterns, such as how to package them so they can be easily incorporated into their environment. For more information on Assets and Reuse, you can start with: http://www.research.ibm.com/journal/sj/453/larsen.html
Companies, teams and developers also learned that to really be successful with reuse, reuse strategies need to be put in place with tools that help communicate where those patterns, components and company frameworks are located, which are the latest versions to be used and with metrics in place to include information such as whether the asset in place is used, how effective it is and how clear is it to teams on how and when to use, amongst many other factors.
In fact, if you are interested in more details on this, you can check out an article written also by Grant “http://www.ibm.com/developerworks/rational/library/sep07/larsen/index.html”, the first of three articles on how to implement successful reuse strategies with tools from IBM Rational.
Now, isn’t the framework of SOA really all about reuse? For that reason, how many really jumped on SOA framework? How many of you are implementing SOA within your projects? I encourage you to comment… I would truly like to understand. As a marketing manager, I am asked to market our products to SOA. Which of course as a marketer, I oblige and do. But, to me, isn’t SOA just another form of reuse? With patterns geared towards web services, with WSDL definitions? Aren’t all the same issues faced earlier by organizations with reuse, still going to rear their ugly heads with SOA? How do distributed teams know what services – or business processes - are already implemented? And if they do, but need to change them, how can they truly understand the impact of that change to others – since its been reused? How can they find the asset (with the right version and all) to modify to make those custom changes, and then ensure they communicate their latest changes and upload them effectively? All these are issues discussed with reuse, and issues again arising with this new services frameworks? So.. are projects jumping on SOA as magic bullet and is it really helping? Or, are organizations cautiously evaluating SOA, and some either just adopting more effective reuse strategies to compete with the demand of cutting software cost while others adopt SOA as a way to effectively reuse and adopt lessons learns and guidance from thought leaders such as IBM?
Should I as a marketing person, market our products to reuse? SOA? Of course, our IBM tools are construction tools that help you make your software better, cheaper.. does it matter if its for SOA? Or for another company specific framework? No! it doesn’t… but it helps to highlight how it can be applied to it, or your company specific frameworks ;)
I should say I am no authority on SOA, Architecture or really anything. I am not a certified Software Architect. I do have computer science background, working on projects myself as well as part of IBM Rational working and implementing with customers. Thus, this is my humble, private, practitioner opinion.
I’d love to hear yours! Am I totally off? Or am I on to something.. and should write a book and become rich?