Pouring cold water on SOA 'reuse' mantra

Summary: Is reuse an idea that's too good to be true? The idea of "build once, use often" has a lot of appeal for enterprises, and, as discussed many times in this blogspace, the first and foremost return on investment to be gained from SOA.

Is reuse an idea that's too good to be true? The idea of "build once, use often" has a lot of appeal for enterprises, and, as discussed many times in this blogspace, the first and foremost return on investment to be gained from SOA.

There has been a lot of buzz and money flowing into governance and registry/repository technologies as of late, all premised on the idea that reuse (and, I should add, sharing) would soon be the way of enterprise solutions.  David Chappell, .NET guru

However, David Chappell (the .NET guru David Chappell, that is) pours some cold water on this happy-talk scenario, observing that the "reuse" concept didn't work too well with object-oriented programming, and isn't working too well with SOA, either. Writing in the latest issue of his newsletter, Opinari, Chappell says reuse of business objects failed, simply because "despite heroic efforts from many IT managers, architects, and developers, the cultural and business barriers to reuse were just too great." He says that everyone he's spoken with is struggling with the reuse issue with SOA, which raises questions about the fundamental value of SOA:

"I’ve spent much of the last two years flying around the world talking with people about SOA. What I’ve heard from virtually all of them is that reuse of business logic is nearly as tough with services as it is with objects. Even Gartner is now saying that you should expect to reuse only a fraction of your services, maybe just 20% of them. Yet if service reuse is so limited, how much value will SOA really provide? If an organization reuses only one in five of its services, why is it building the other four? The one that does get reused had better provide significant value to make up for the cost of the four that sit idle."

Chappell puts it this way: "Creating services that can be reused requires predicting the future... how can a service’s creators accurately guess what future applications will need?" The 'If-you-build-it-they-will-come' approach is tough to turn into real reuse," he says. Plus, there are few, if any, organizational incentives to build a component that can be reused by other groups.

There are situations where reuse is working, Chappell points out. Integration is one such value point: "Anyone creating an application that must be accessed in different ways, such as by a JSP front end, a Windows Forms client, and a mobile device, might well find that building an application in a service-oriented style is an excellent idea. Letting these various clients access the application via common services will make life simpler for everybody."

For reuse to work, Chappell says, companies need a corporate culture conducive to the sharing of innovation across departments, with "top management support, strong commitment, and diligent effort." How many companies are fortunate enough to have such visionary management and corporate culture?

A few thoughts here: Converging trends and business necessity -- above and beyond the SOA "vision" itself -- may help drive, or even force, reuse. SOA is not springing from a vacuum, or even from the minds of starry-eyed idealists. It's becoming a necessary way of doing business, of dispersing technology solutions as cost-effectively as possible. And, ultimately, providing businesses new avenues for agility, freeing up processes from rigid systems.

The world within and around enterprise technology is changing. Technology is growing increasingly sophisticated, and IT departments overburdened. Enterprises no longer have the time or resources to field numerous technology silos -- those days are over. There's no time to keep reinventing wheels. Plus, to add another Gartner observation, many parts of the IT function are evolving directly into business units themselves. When it comes to future technology, it's all about the enterprise.

Topic: Enterprise Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • Once more for the hard of hearing

    Reuse has 2 major problems that have NEVER been solved (or even addressed) they are:

    1. How do I find what I need?
    2. If I can't find it, is it because it doesn't exist or my searching is inadequate?

    Having an Excel spreadsheet listing a couple of dozen procedures can work. Having a database of thousands of procedures is problematic. What do you search on (How to describe this "thing" you made)? How can you make sure that formatting rules are enforced? When you get more than one "hit" which one should you use (i.e. how much do you need to know about their internals)?

    People make too many assumptions about reuse - and those get parroted to people that don't understand, so decisions get made that don't jibe with reality. Here's a clue for you all - The Walrus was Paul! No, I mean reuse doesn't now and probably won't ever work.
    Roger Ramjet
    • Encouraging Reuse

      The best way to encourage reuse is to shrink all schedules and budgets to the point where they cannot be attained without it.

      We've actually had a fair amount of success with reuse of FPGA code, but not much for "regular" software...at least the last time I saw a presentation on it.
      Erik Engbrecht
    • It depends what you mean by reuse

      I would agree that "application specific" reuse is very difficult.

      However I feel a more promising approach is what one might call "axiomatic" reuse. This means developing a set of generally usable non-application specific techniques.

      I would say that the relational model is an example of just such reuse. All data is represented in exactly one way. All data manipulation can be achieved with a very small number of operators. Furthermore all of these operators are not specific to any application.

      Of course you still have operators that apply to specific types but in the relational model types are very specifically associated with attributes and definitively not with relations (tables in SQL speak). For manipulating relations you only need relational operators. Of course in an RDBMS the operators that are associated with specific types could be represented in the database itself.

      I often wonder whether there may also be "axiomatic" principles that you could apply to such things as user interfaces.

      One of my objections to OO is that the sheer volume of class libraries and methods becomes so overwhelming that it is often difficult to find your code (never mind someone else's) among them all. OO is a bit like the Pompidou Centre of programming techniques, all the plumbing is on the outside.

      Frederick Brooks commented on this in the anniversary edition of "The Mythical Man Month" concluding that learning a class library was no more difficult that learning a foreign language. Well learning a foreign language is damn hard work and learning a programming language ought to be a hell of a lot easier.

      With "axiomatic" techniques most of the "plumbing" is out of sight and you can concentrate on solving the problem you actually want to solve.
      jorwell
  • "Reuse"

    So Charles Stack talks about the Three "R"s of SOA

    http://blogs.zdnet.com/service-oriented/?p=697

    Reuse Reduction and Remix.

    Hmm, I agree with the premise of the previous commentator "Roger Ramjet" as well as the premise of this blog that "reuse" doesnt come for free.

    One of the most blindingly obvious things about Enterprise software is that there is a TON of redundancy to it. There's redundancy of hardware, redundancy of function, redundancy of software, of services etc.

    So the idea of SOA magically offering you "reuse and reduction" is somewhat farcical. Why?

    Because much of the redundancy is there for a reason. Some of it is there for legitimate reasons, and some of it is there for pragmatic, but perhaps sub-optimal reasons.

    For example, redundancy into application "silos" is certainly an antipattern for SOA--but these silos emerged not because people were dumb, but because they were smart (or at least shrewd). One group doesnt want to become dependent on another, and no group in an Enterprise wants other groups to "Mooch" off their infrastructure for free.

    Reuse is pretty badly misunderstood in services. Since a service is already deployed and running (as opposed to software, which may or may not be deployed), reuse is use. The fact that the component has different users that are more loosely coupled comes with the territory.

    A decent use case for this type of reuse is
    http://webservices.sprint.com
    (disclosure, Infravio customer/I work at Infravio)

    At Sprint, the same underlying services such as Trouble Ticketing or Order Entry are "reused" by many different customers. What changes from customer to customer? First of all the identity of the customer and their access privileges. The Service Levels to which they are promised. The specific security preferences which they need to authenticate themselves. All of these preferences can be stored in metadata. What is this? Reuse? Use? Multiple-Use?

    Which brings us to the third R, which Charles states is "Remix". I think it's posssible that that's a legitimate value of SOA.

    But Reuse is such a tainted word from Object Orientation. Reuse has too much baggage, let it die a quiet death.

    If you really are getting "Reuse" properly from SOA, you are getting more different kinds of "Use". This is pretty well indistiguishable from Agility, which is a crappy word, but it beats "Reuse".
    mikojava
  • SOA needs special gouvernance schema

    I worked as consultant on several SOA projects (inc. one very large).

    I agree with mikojava : there are good reasons for silo based architecture and there are very few reasons for business units to spend effort and money to build common services.

    I also agree with Joe : the world is changing and enterprises need SOA. The trick is that SOA is needed by the enterprise not by its business units.

    I wrote a short paper on that topic :

    http://www.lesmoineau.fr/Papers/SOA_Gouvernance_EN.pdf

    Th. Moineau
    (www.lesmoineau.fr - thierry @ lesmoineau.fr)
    ThMoineau
  • Its all about the Matrix

    A Vertical organization is that top-down, responsible for all things type of organization. They staff every position (network, storage, server, client, appdevel, etc.) and can satisfy most of their customer needs. The down side is that in a typical corporation, you end up with TONS of these "Chimneys" and they don't interact.

    A Horizontal organization is one that stretches across the company (say "Networking"). In this way, the corporation can enforce standards and streamline support. The down side is that they are less accountable to each (Chimney) organization and tend to have slow response times.

    A smart corporation does BOTH of these things and leverages the strengths while working on the weaknesses.
    Roger Ramjet
    • The Matrix

      Have you ever worked in a matrix organization?

      In theory it's a good idea...

      But you get the accountability breakdown of the horizontal organization (because workers end up having >=2 masters) and two dimensions of silos instead of one (because functional organizations turn into little empires and programs/project organizations try to form "rogue" states and bypass the empires).

      Now, it's not all bad. There are economies of scale and there is a certain leveling effect on workload (well, filling in the valleys).

      But overall it makes a much more complex organization.
      Erik Engbrecht
      • Implementing the Matrix

        Horizontal organizations are weak - so it is absolutely necessary to have STRONG leaders (this is not so important for Vertical organizations). Standards are implemented (and enforced?) through the HO's. Hiring is done by the HO's. The Vertical organizations end up being like a permanent customer for the HO employee.

        This can be done with the front-office/back-office split. Business-facing management and project managers occupy the front-office - which is where the "customer" (internal customers as well) interacts with the company. The back-office is where the solutions are developed. The CIO is the head of the front-office (Vertical) organization while the CTO is the head of the back-office (Horizontal) organization. Front-office employees do not have to be technology savvy and back-office employees don't have to be "people persons".

        This allows for "dual tracks" for advancement in the company. Organized people-persons will do well in the front-office. Technical geeks will do well in the back-office.

        The Matrix (just like the movie) actually exists - while we don't see it. These 2 roles are not recognized and organized properly - but they exist and do the work today. Bits and pieces of the Matrix crop up in different areas of the company in an ad-hoc fashion - so why not harness it and make it official?
        Roger Ramjet
      • Advantages of hierarchies

        One of the principle advantages of hierarchical organisation is that the number of paths of communication is much smaller.

        If everyone talks to each other then adding one more person to an organisation of n people requires n more lines of communication. Adding one person to a hierarchy requires only one additional line of communication.

        In practice, everyone talking to each other is wholly impractical outside of small groups.

        Matrix organisation is somewhere between the two.
        On the whole I would say hierarchical is simpler and perhaps should be favoured on that basis alone.
        jorwell
  • Effective ReUse

    Most of us would agree that re-use has been unsuccessful most likely because it concept is often misrepresented. In whatever forum you are discussing the mantra of efficiency, cost savings, reduced development time, etc - mentioning re-use will generally get you knods of acceptance.

    As we have found that most of the initiatives at a corporate or even organisational level have failed - most likely because there is not a clear understanding of whether re-use is indeed appropriate in the first place. I have tried to capture how we might approach this categorisation in a blog I recentley posted here http://www.eds.com/sites/cs/blogs/eds_next_big_thing_blog/archive/2006/06/19/8597.aspx.

    I believe that SOA, properly approached does offer a real chance of establishing the level of re-use that will have the sponsorship of the business - a key measure of success.
    alex.cameron@...
  • ReUse requiires Real Work

    The mistake is thinking reuse will happen for free. It doesn't work that way. Customers who get reuse to work have to invest lots of hard work negotiating across the silos to be certain that services are written with more than one group's needs in mind. It helps if the cost of this facilitation -- and the investment costs of the extra work -- is underwritten by the enterprise rather than borne by whatever group happens to go first.
    amywohl
  • Service reuse is actually happening out there

    I decided to see for myself what the reality is of service reuse, so I went and compiled some information gathered from our customers who are building SOAs.

    Without doing too much digging I came up with substantial list of reusable services that are being used in live deployments, which I have posted <a href="http://www.oreillynet.com/xml/blog/2006/10/service_reuse_fact_or_fiction.html">here</a>

    Dave (Progress/Sonic Dave that is)
    Dave_Chappell