|
One challenge I've faced when discussing reuse is that not everything that is reusable should be a service. In fact, most of the reusable items that come to mind fall into two categories: 1) Things that belong in a reusable class library. After all, two of the best examples of reuse are the rich functionality provided by the .NET and Java EE frameworks. 2) Things that should be externalized from the application and be implicitly executed through declarative policies. As a later post already pointed out, this gets into the world of aspect-oriented programming. It also is well suited for SOAP mediation, as Anne points out.
SOA doesn't necessarily have to be about reuse, although it is a benefit. I'm a huge proponent of reuse, but I also think the more important factor is to place interfaces at the right places so that the units of work can be combined in new ways in response to business change, which may imply turning the old ways off. The logic still remains, we've just combined it in a new, interesting ways, however it may still only be used in one place.
The items that Anne called out are all good starting points. Just don't automatically assume they should all be implemented as services. In some cases, these infrastructure capabilities should be external services, in other cases, an aspect-oriented approach or a class library may be the best choice.
-tb
On Mar 2, 2006, at 6:25 AM, Anne Thomas Manes wrote: The advice I give to my clients is to start their reuse efforts with infrastructure functionality -- things like authentication, authorization, auditing, cryptography, logging, monitoring, caching, etc. One of the things I like best about SOAP is that it enables clean separation of infrastructure from business logic via the SOAP mediation model.
This approach brings two advantages: it is something that can be done reasonably well by an IT group without a huge amount of collaboration with all business groups that will use the services, and it gives the IT group more control over policy enforcement.
One of my clients (a Fortune 50 financial conglomerate) estimates that 30% of its current IT budget is spent on infrastructure functionality -- which currently is reimplemented in every application. By externalizing this functionality into reusable services, they could potentially save hundreds of millions of dollars a year. They would also have much better control of security and management, and they would ensure much more consistent enforcement of policy.
Another sweet opportunity for reuse is in response to government regulations. For example, anytime someone requests to open an account, a financial institution is required to check a government database to ensure that the person is not a known financeer of terrorists. Rather than implement this code in every line of business for every type of account, this code should be implemented as a shared service.
Anne
On 3/2/06, Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote: 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! SPONSORED LINKS
YAHOO! GROUPS LINKS
YAHOO! GROUPS LINKS
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
