Alexander Johannesen wrote:
On 3/2/06, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote:
> You read a lot about enabling service re-use, but very little about organizations that
> actually achieve it on anything beyond a trivial scale.

I guess for this sentance to work, you need to define that scale. Number of applications using the service? Transactions per second? Business importance?
I was thinking about the first of these, which I would rephrase as the "number of services that are used in more than one process".  As I wrote in the last email:
are many services ever used in more than one process without significant change?
Some more on this theme ...

I spent some time in 2001 working with a software house that was building a life insurance application out of components, which interacted via Web services.   This application had to be generic - i.e., in principle be usable by any company selling life insurance.  So it was a testbed not only for SOA technology (since this was early days for SOAP etc) but also for SOA principles (in particular, enabling service reuse).

What they ended up with is a set of services that were fantastically complex to invoke.  To hook them up into a useful process, you needed not only to have a very strong grasp of life insurance (the sort of understanding an actuary has) but also of their particular approach to application design (what all the complex types were for, and what their various nested fields meant).

Now, I didn't have much to do with the design of  their application (I was building a particular one of the components, for process modelling and execution, not specific to life insurance, that eventually became RADRunner), so I am not qualified to say whether or not they could have done things differently.  But I suspect that there may be a general problem here - particularly since my experience with ERP, described in the last email, shows the same forces at work.

Stepping back for a moment, the use of patterns and refactoring has been revolutionizing software design across the board for about 10 years now.  But these techniques do not help make software simpler, just better structured.  And perhaps software cannot be made simpler, since in the end it has to reflect the real-world uses to which it will be put.  So I think it is very hard to build services that are genuinely re-usable in many different processes - not impossible, just hard - and I wonder:
  • How many organizations are doing it on more than an ad-hoc basis
  • What sort of services they have made re-usable - are they very simple? very complex? somewhere in the middle?
  • Whether the financial investment in making these services re-usable was worth it.
Anyone got any figures?  Or tales to tell of service re-use in unconnected processes?  To my mind, there is a fundamental axiom of SOA that needs examining - that service re-use gives ROI.  I wouldn't bet on it, myself, and might write something on the subject.  But before I do, I would be interested to hear of group members experiences.  Perhaps I am completely wrong, and organizations all over the world are busy re-using all kinds of services like crazy without having spent a fortune achieving and maintaining this IT nirvana - if so, it would be interesting to know about them!
-- 

All the best
Keith

http://keith.harrison-broninski.info



SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to