Almost 15 to 20 years ago Reuse was described as main benefit of Object Oriented.
SOA Reuse is Easy to say and hard to do. 100% Reuse was an unrealistic target. However, even 30% Reuse ratio could provide significant Business Value.
There are Systems or Systems Components, which you can not break into Services reasonably, e.g. Batch Systems or Legacy Systems.
People tend to ignore systems that do not fit well to the Service Oriented Architecture due to lack of Reuse or insignificant Reuse. They should not. Instead of ignoring them by fitting them into Services Framework and Architecture, they should accept the reality, that building Services for these Systems is wrong.
Douglas Adams's Last Chance to see
Douglas Adams's most famous books are The
Hitchhiker's Guide to the Galaxy books. However, Adams's favorite book was: Last Chance to see which was written together with Mark Carwardaine.
Most of the books written by Adams are Science fiction books.
Last Chance to see is an exception. It is a book about animals which almost become extinct.
Mark (a Biologist) was the expert, Douglas wrote and a BBC representative photographed and recorded. They traveled to various countries such as China, Zaire, Madagascar, Indonesia and New Zealand in search of rare animals which almost become extinct.
The marvelous book is about those animals as well as about people trying to preserve them or trying to kill them or trying to document them (including Adams himself).
Adams and Improper Reuse
If you wonder why I wrote about a book on Biology in a post about Information Technology concepts, the answer is: Reuse when you should not, i.e. building for Reuse that probably will never occur.
Adams wrote about two related ridiculous Reuse cases.
The first Reuse or actually lack of Reuse is performed by a bird similar to a chicken, which unlike a chicken, can fly. The bird built a very complex and very large nest.
The bird dug 3 meters in the ground. It filled the large hole with plants and added earth above the plants in order to verify that the nest's temperature is not too low. It continuously added earth, to verify that the temperature would not be lower than it was before.
The problem: It is used only once for a single egg. It could easily get the same "Business" results of growing a young chick, by building a simple and smaller nest.
The second Reuse without Reuse Case is Douglas Adams writing a Computer Programme to calculate the size and structure of the nest. Such a program could save the need to measure the nest physically. However, Adams travelled to this country only once for few weeks, to search for another animal.
The required Computer Programme is complex, but the probability that it will be used again is extremely low.
Conclusions
Adams's examples are clear and could be generalized to SOA.
There is overhead for building Reuse Service. The overhead is in Planning, Architecting and Building a Service.
If the Service will never be Reused or will be seldom Reused, consider other alternatives which are not Service Based.
5 comments:
iCMG Architecture World
Reuse: Myths and Reality
I agree with Avi.
If I don’t agree with figure (percentage), but definitely as far as reusability is concern this is the only SOA promise which is being least addressed in the enterprise. Technology wise reusability can be achieved but problem comes in non-technical way (i.e. building and maintaining reusable component as asset, mindset change about linking vs. re-build, ownership, etc.)
If you compare with OOA & OOD, scope of SOA is big, vast and complex. Identifying a SOA reusable asset is require holistic view of the enterprise, it means you must have all the models with all the perspective. While OO is concern, its scope is small limited to an application so only class diagram is required and effective review process is required to prevent copying the code (linking vs. copying).
By Amlendu Choudhary
iCMG Architecture World
Reuse: Myths and Reality
At least as evidenced at my last employer, reuse via SOA building blocks utilizing a SOI, is very achievable. What is not as apparent though is that it took us, depending on where you start measuring, anywhere from 8 to 15-years to get to a level of enterprise maturity where we could even attempt it (2 CEOs and 3 CIOs). Even at that, there were a number of false starts and we had to employ the CFO organization to act as our auditors when any reuse claims were made (which was one of the smartest things we did).
As suggested in one of the earlier inputs, it is very easy for a vendor to tell you, "SOA in a box" will save you a great amount of $, but it is what is unsaid pertaining to the bits that need to be in-place and part of the culture, that will eat your lunch. Unfortunately, too many organizations seemed to have drunk the SOA Kool Aid, before performing any due diligence.
By Bob Deutsche
iCMG Architecture World
Reuse: Myths and Reality
There is a different rate of platform change - than far away you from UI than more stable.
By Igor Rozenberg
Gartner Application Strategies (Xchange)
Reuse: Myths and Reality
There's a lot of difference between design-time SOA and run-time SOA, and all kinds of logical interdependencies which aren't handled well by multi-user version control systems. If one wants reuse one can get to about 85-90% but one has to design it, using SOA as a design paradigm.. but SOA doesn't translate into high degree of reuse automatically.
By Paul Peters
CMG Architecture World
Reuse: Myths and Reality
My view is that Reuse should be seen in a larger context. I agree to an earlier comment that in a SOA context Reuse has mostly happened thru a wrapper based implementation.
Reuse components can be broadly classified into two categories - Infrastructure ( GUI, Security, DB related, common validations, memory caching, generic business components - (EX; credit card validation, SSN validation, etc) & Business ( domain specific) . Infrastructure component reuse is rather easier to adopt and has wider scope of applicability and has substantial positive impact on quality and productivity.
Reuse of Business components has an additional challenge of IP protection. With more adoption from Open Source components, i feel Reuse is increasing over time.
A developer mostly gets into dilemma when he thinks of reuse, i.e. search and locate a component for reuse or code again. Another factor that also needs to be factored is the quality of the reusable component, how easy to adopt, if standards followed, quality of documentation, component quality ( bug free) etc..
By Subbu Subramanian
Post a Comment