Is Reuse Still too Hard?

Many of the benefits of SOA derive from service reuse. Software reuse as a concept has been promoted for many years and proposed for many different technologies. Services represent a greater level of abstraction for designing and implementing reusable software, and XML and Web services are easier to use than their predecessors. But is it still too hard?
This, I believe, is what’s at the heart of David Chappell’s recent paper on reuse.
He says that almost everyone he has talked with during the past two years about SOA has said that achieving reuse with services is almost as hard as it was with objects.
Because reuse was promised and not really achieved with objects, and because it’s not much easier with services, David’s conclusion from his conversations appears to be that the industry is going to fail again.
He cites the usual difficulties with creating reusable services, including cultural challenges for developers (like my colleague Steve has written about), political problems (in which one department is not motivated to share the cost of reuse with another), and the fact that a service published for reuse might not contain all the features and functions some consumers require.
I do not agree with his assertions that the industry adopted objects, and will adopt services, simply because the big vendors push these technologies onto their customers. If these technologies were not addressing real customer problems – which is where vendors get their ideas for new features – customers would not buy and use them, no matter how hard vendors might push. Customers have a low tolerance in general for unuseful features (anyone remember “Bob“?)
However his conclusion is what bothers me, since he’s basically saying that reuse is still too hard. I wonder whether or not that’s true. Certainly I have heard a lot of success stories from our customers and from others at industry trade shows.
If it were it would be a serious disappointment. I certainly think that the current technologies for SOA – XML and Web services – represent a sufficient level of abstraction to achieve reuse.


5 responses to “Is Reuse Still too Hard?

  1. I have to be heretical here and take a directly opposing POV to you. I would contend that software reuse is maybe hard, but that it exists, has been an enormous success and forms the mainstay of software development today.
    Let’s look at UIs. Nobody would develop a UI today without a set of reusable components. What about basic programming. One only needs to look at how rich and extensive the J2EE or .NET class libraries are and how much their (re)use is part of standard software development practices is to see that reusability is the norm rather than the exception.
    But what about the bit in the middle, the so called business logic? The enormous success of ERP companies such as SAP is surely adequate proof that reusable business logic is a reality.
    The only thing that stands out here is that reusable components are not developed in-house by IT-Shops (as David Chappel pointed out when he asked about in-house reuse programs), but are developed by vendors who:
    a) invest heavily into their products and
    b) have an industry wide view point instead of a restricted company view point.
    Perhaps this is clear indicator to where we can expect the majority of reusable business services to come from.

  2. Hi Andrew,
    Actually my intention was to honestly ask whether David’s paper was an indication that the technology for the reuse of application level functionality is still too complex.
    I was not really trying to promote a particular point of view on this. I’ve been involved in complex software systems for a long time and it seems to me that Web services represent a sufficient level of abstraction to enable business software reuse.
    I completely agree with you that many levels of reuse already exist, and probably should have been a bit clearer about the particular type of reuse I was referring to.

  3. 重用,仍旧很困难吗?


  4. You argue that customers would not adopt technologies just because vendors push them – whilst I partly agree, perhaps another side is that customers will not agree to an expensive overhaul of their systems without the promise of some “tranforming” silver bullet.
    The vendor thus needs OOP or SOA or some other TLA to get the customer to agree to the spending – but perhaps the benefit would be obtained even without any new technology, simply by reviewing, refactoring and updating the customer’s systems.
    Any resulting benefits will of course be credited to the silver bullet TLA…some credit may be justified, some unjustified.

  5. David,
    I’ve worked on both sides of this –on the customer side and as well as on the vendor side.
    It’s a complex situation. Customers don’t usually invest unless they can see – for themselves – what the benefits would be.
    Sure, sometimes customers get talked into things by vendors, and sure, many vendors just push their own products regardless of the customer’s requirements.
    But these TLAs would not exist at all unless there was some reality behind them.
    You are right that success is often unfairly attributed in order to bolster the latest marketing campaign, but I believe that good sense will win out over the hype in the end.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s