We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

Is Service Reuse Overrated as a Value Proposition for SOA? Does Reuse Even Work in Real-Life Situations?

Vote 0 Votes
This question comes from Joe McKendrick, and will be covered further in depth at ebizQ's SOA in Action Virtual Conference coming this Oct. 28-29.

11 Replies

| Add a Reply
  • user-pic

    Yes, reuse is extremely overrated.
    Yes, there are several (not many) cases where business service may be reused.

    I always said and would like to repeat now - nobody need SOA to implement reuse.

    The problem, however, is with the word 'reuse' itself. I define reuse of Service only if the Service is used in changed Execution Context; otherwise it is simply multiple use.

    A lot of people think that if they use the same Service in another project, they reuse it. I believe that from SOA perspective such 'reuse' is a mistake. If one day a bus runs on the Rout 111 and another day - on Rout 93, are we reusing the bus or just using it exactly as expected? However, if one loads the same bus with construction materials and delivers them to the place of construction, it is reuse to me.

    With respect to SOA Services, we, e.g., can have a Debit Card Payment Service, which can be reused in the UK and in the US for paying for some goods; it will be the case of 'reuse' because these countries have different financial law and, thus, Business Execution Context for the same service will be different.

  • In my opinion Service reusability is more of a cultural value where every individual within an organization needs to understand the significance of it and diligently abide by policies laid down by organizations to make it a success.

    Generally, making something reusable requires one to comprehend existing artifacts and then choose to create a new artifact or do with the existing one. The question is do people have the time to comprehend and react? Yes, reusability in the long run would certainly provide the much talked about value proposition to SOA, but from an implementation perspective, there are difficulties which could prove to be deterrent unless addressed early on. SOA Governance/Registry is what could cater to it but given the situation today there are very few enterprises who are using Web Services and a Governance product. Well your guess is as good as mine!

    Let’s understand some of the challenge:

    • Service Ownership/ Turnaround time: As an example, a Line of Business (LOB) representative who is more interested in knowing about whether the delivery schedule is in place, most probably wouldn’t be interested in Service Reusability from his standpoint. His regular train of thoughts would be to have a simple service up and running which will provide him with the required details - may not go with the Chief Architect as he or she would require time to provision such a service keeping in mind, the Service granularity, existence of a similar service and the likes which may take time. But if you see the LOB is finally the Owner of the service as he is the one who would be asking for a service of that kind in the first place. Also, addressing the immediate and the quick time-to-market needs might more often than not win over the principles of reuse outlined early on.
    • Service Visibility: Most often in Enterprises, Services are developed in different departmental silos. This poses a huge problem in terms of reusability as the development group that is developing a service may not know that a similar service already exists. One may argue that a Service registry could help in such a situation but then suppose they don’t have the privilege to access them then they will end up creating similar services! Though a proper design vis-a-vis Security and Taxonomy would control how much service-reuse can be experienced
    • Granularity of Services: Another area of concern is the granularity of services. Should it be fine grained or coarse? The question is not about who gets to decide, but due to pressures from the business side it often becomes difficult for IT to have services which have the right granularity and could be reused later. Services become very specific and not designed for reuse.

    All in all, Service reusability would provided the much needed value proposition to SOA. But then enterprises would need to first understand the challenges and then have a roadmap to benefit from SOA leading to Service reusability.

  • I get the tendency to see reuse with regard to SOA; after all SOA should reduce redundancy, which means that those redundant business functions will be represented once and only once in the organization. Hence, they will most likely have more than one consumer. But, to be clear, the goal is to have one and only one way for the business to deliver a business function, with no ambiguity, as a service. This gives the organization the reduction in costs, consistentcy in approach and agility to change quickly because there's only one touchpoint for a given business function.

  • The handkerchief is a great idea; you can wash it and reuse it over and over. But despite this, nearly everyone—myself included—uses Kleenex. It’s just more convenient. The only handkerchiefs I own go into the breast pocket of my suit.

    Software reuse is also a great idea and a worthy goal. The truth is, though, it rarely happens in real life. Copy/paste/edit is just too fast and convenient, even though it’s easy to make good arguments against doing so. I suppose it’s a sad reflection of the disposable mentality that runs throughout modern society.

    I see a similar pattern in SOA all of the time. Everyone leads with a story of reuse; but reuse takes a lot of discipline, commitment, communication, process, organization and even time to do well. Once the pressure to deliver applications rises, good intentions and great ideas get short circuited because of the overwhelming need to finish the job at hand. The reuse, we say, will come later. It rarely does.

    Where reuse does happen more naturally is with infrastructure and experience. Load balancers and application servers acquired for web sites now also support SOAP applications. Expertise in Java or .NET is applied to writing new services. These victories may not make as compelling a story, but they are certainly important and potentially easier to quantify.

  • I agree with most of the points but what I would like to point out explicitly is that service reuse per se shouldn't be the end goal for SOA. Value proposition is achieved by two primary means - saving money and/or generating revenue. Service reuse can get you these benefits provided it is a disciplined and sustained effort. I have seen it work first hand but it has to be approached less as a fad and more as an investment.

    Service reuse is no different from the traditional challenges with reuse. You need to understand the domain, understand the relationships/variations that need to be captured, as well as pursue architecture convergence. Without these your services reuse won't succeed.

    I agree with you Scott. With regard to copy/paste/edit - my personal experience is that it is a cultural thing more than anything else. You can control reusable components/service capabilities via interfaces and ensure developers refactor components before jumping to create redundant code. Now, this is a lot easier if the codebase is actively reviewed, and developers communicate effectively.

  • K. Scott Morrison's analogy above about Kleenex(R) vs handkerchief is a pretty funny and good one...

    My veiw is along these lines, and if you can help your "software developers" (in quotes because I've seen organizations define the role differently as "capability or service development which isnt so centered around the generation of new lines of code as a goal) understand what the implications of service reuse are.

    One of the most frustrating and painful things for a programmer is to see their work thrown away. This is one of the emotional drivers behind Open Source, which is to say that the code that you worked so hard on becomes canonical, immortal and the platform for future generations.

    If you can speak to your developers about the goal to make their efforts canonical, immortal and the platform for future generations instead of throwaway, you can recruit them to this task.

    Another organization studied the long term cost of new lines of code and determined that the fully loaded cost (risk adjusted) for each new line of code was about $200 USD. Multiply that by hundreds of millions of lines of code and you end up with big numbers.

    So although it's easy for one group of devs to crank out new code in the IDE, it can cause a downstream externality (externality is a term borrowed from economics where one group produces a cost and another is forced to pay for it) that burdens other groups.

    The word "reuse" is painful because it comes from an overburdened history and thus is semantically overloaded.

    Although it's cumbersome, the phrase "not wasted" might carry a more meaningful connotation. A connotation that also carries meaning in the realm of finance is to look at software project efforts as not being ROI based but closer to a model of ROA or Return on Asset. Although it is not permitted in general to capitalize and amortize the cost of a software "asset" in the same manner as a hard asset, this conceptual thinking can help financiers see the appeal of both extracting and measuring the value of a software effort over a long period of time, and amortizing the cost over a similar time frame.

    My 2 cents,
    Miko

  • By the way, reuse does happen in software--most of the software we use makes a lot of "system calls". The platforms we use, Java, .Net etc are reusing the core libraries like gangbusters.

    It's really related to whether your organization thinks it's time to build a technology platform for their business. It's not a guaranteed win, it's a function of granularity and stability of core business functions and an attempt to commoditize the underlayer.

  • It very much depends on the level of the service. At a high 'business level', a service may never be reused as it simply implements one business function. At a lower level in terms of exposing IT assets, it is absolutely fundamental IMHO. How many times have you seen very similar integration efforts repeated time and time again simply because the person that developed the original service is not around and noone really knows how it works ? Organizations end up with a lot of duplication that would be resolved through reuse and proper management (Governance in today's language) of the services they have. One of the major advantages that using SOAP gives you is that a WSDL represents an accurate technical document of what a service does so it doesn't matter if the developer is still there. A UDDI server gives you a database of existing services. People knock these standards regularly and while I agree they are far from perfect, they can help to ensure reuse of existing assets thus fulfilling one of the promises of SOA.

  • SOA reuse is highly overrated. When SOA first started climbing up the hype cycle, it was pushed to developers as a way to increase the "reusability" of their code by making everything into a service. This created at least two problems with the first being a massive service proliferation as developers eager to jump on the SOA bandwagon made everything into a service, which in turn led to poorly performing architectures (not SOA's fault) and huge issues around service management and governance. The second problem was that upper management and the mainstream media also started "drinking the reuse Kool-Aid" served by the bottom ranks.

    The fact is that reuse is only a by-product of SOA. Adopting SOA for reuse is like saying that you're working out to sweat (instead of for losing weight, building muscle, or improving overall health). In fact, I would contend that the re-use provided by SOA is only marginally better than what we've had in previous architecture generations. We've gone through libraries and modules in procedure-oriented architectures, objects in OO architectures, components in component-based architectures, and now servces in SOA. A key issue around reuse is not the technology but the identification, segregation, and granularity of "reuse" items - none of which are dependent on what architecture style you are using. The real value of SOA is as a building block of the larger enterprise-level strategy of aligning IT with the business to ensure that IT value is justified, IT supports the business objectives, and IT has an equivalent level of agility to adapt with changing business needs. In some cases, SOA even becomes the catalyst that spurs the IT alignment to business objectives.

    The nutshell is, SOA is about strategic IT alignment with business goals and objectives. Service reuse is only an operational - not even tactical - outcome of SOA. A corollary to the discussion is that many bottom-up adoptations of SOA start with lofty reuse objectives and either quickly become disillusioned or fail to demonstrate adequate value to the rest of the organization because their original reuse goals are far from being met. That is why SOA has the best chance of success with a top-down adoptation with the long term sight on strategic alignment objectives rather than operational reuse objectives.

  • Great question, and great thoughts. I have learned a lot by reading this post. I think it's fascinating that we can all be in agreement but for so many different reasons. Here's my rationale...

    Service reuse is valuable only to the extent that your company reuses requirements. If clients (be they customers or systems) don't need similar data and functions, then designing for reuse has no benefit. In my experience, IT benefits from reuse, the business not so much.

    Miko mentioned service granularity, architectural layers, and reuse of core libraries in his comments. Reuse is needed, and is more successful, at lower levels of the architecture. It combats the point-to-point problem, which is an IT problem.

    But customers don't care about how many integration points IT maintains. They care about getting what they need when they need it, and they all have different needs (different requirements). This is agility, and it is a business problem.

    SOA must address both concerns -- improving business agility by increasing IT responsiveness. We can make IT more responsive by designing reusable, finer-grained services -- the basic building blocks of SOA -- but these services are too raw to be of significant business value. To enable an agile business, we must be able to rapidly build unique, one-off services that meet very specific customer needs.

    So reuse is important to SOA, but only at lower levels of the service hierarchy where the same requirements turn up again and again. Here IT can achieve cost savings and responsiveness by reusing integration plumbing across many projects. But customers need specialized services -- that have little shared demand across the company -- that grind those core functions and data into strategic solutions for their businesses. Emphasizing reuse at this level falsely assumes that customers need the same information and undermines the agility proposition of SOA.

    More at http://soacoach.blogspot.com

  • I also see reuse possibilities for different kind of presentation. For example customers want to use the same functionality via WebBrowser, Portal, PDA. This can also be a good reason to SOAlize.

    (rogervdkimmenade.blogspot.com)

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT