Just read an post over at InfoWorld by David Linthicum. The central point of David's post is that reuse shouldn't be considered or advertised as the 'core value' of SOA. I totally agree with that, particularly as often, organisations still insist on setting up SOA projects, rather than changing the mindset and method of working to encourage the adoption of SOA across projects.
To me, half the problem with the reuse argument is that people don't have a clear understanding of what is meant by the term. Often, people consider that reuse is only achieved when a service has more than one consumer within the SOA at a point in time, but (to me) that's missing the point. An SOA is not a static environment; in a well managed organisation, it'll change almost continuously. To me, you're achieving some level of reuse whenever you fundamentally change a business process without having to re-hash all of its services, or you don't have to bother re-testing every combination of parameters to a complex business process because you know already that the services that underly it, which make all the hard decisions about someone's credit worthiness have been tested thoroughly already. You even get re-use whenever you say "Ah, well, we'll apply our standard grade message integrity policy to that service, so we know how to achieve that".
If you take this broader view (let's call it long-term reuse), then long-term reuse and agility become somewhat interchangeable concepts - you get agility through being able to reuse a service across two versions of the same process, by knowing that you've already tested a given service to death, and by not having to make complex technical design decisions each time you create a 'new' service.
So. I agree that the reuse should not be used as an advertising 'headline' for SOA, because in an advert (be it literal or spoken), you don't really have the time or bandwidth to get some of the subtleties of the above across. But in reality, over the medium term, I think we will find that the long-term reuse achieved (assuming for a moment you buy into my definition) is significantly higher than people currently expect.
The last point I'd make is this: If you design your services for immediate reuse, you will likely fail to achieve that re-use. If on the other hand, you design your services for change, and aggressively factor new functionality into them as new consumers require it, I suspect you'll find even 'point in time' reuse increases dramatically over the medium term.
1 comment:
Haven't looked at it yet, but IBM have a new redbook on 'Asset-Based Development', which is supposed to provide re-use.
see here
Post a Comment