“Let's imagine a pretty world of SOA-happiness where the computing needs of an enterprise are split into many small applications that provide services to each other to allow effective collaboration. One fine morning a consumer service needs some information from a supplier service.” Martin Fowler sets the stage for problems that face any multi-business-unit SOA infrastructure.
In an ideal world the developers of the consumer service just asks the supplier service to develop the potential service and all is dandy. But life is not ideal - the sticking point here is that the developers of the supplier service have other things to do, usually things that are more important to their customer and management than helping out the consumer service team.
Martin points to an example of a real world solution to the problem, employed by colleague Erik Dörnenburg.
They took a leaf out of the open source play-book and made all their services into internal open source systems. This allows consumer service developers write the service themselves.
He suggests that anyone could work on service enhancements and submit "Patches" which are then reviewed and "applied" by a service custodian. He likens the role of a service custodian an to open-source maintainer and “though the custodian approach doesn't entirely eliminate the problem of consumer developers needing to wait on supplier developers, it does a lot to reduce the difficulty”. He suggests that it is easier for the custodians to apply "patches" than to develop service enhancements themselves and that the process scales well, as the consumer service developer gains the trust of the custodian over time.
The responsibility of the service custodian can be vital to the success of this approach. The solution that Martin alludes to, can be likened to Jim Webber’s Geurilla SOA, a grassroots SOA effort. Tony Baer, from the SOA Insights podcasts, warns of the potential risks of such an approach,
What if the project grows large enough that, to respond to a new requirement, you create a new service from scratch because you’ll get the job done much quicker? That’s exactly how spaghetti code (where you have tangles of point programs) gets created –- while it’s quicker to produce, you really don’t want to end up maintaining all that crud.
Does service re-use need to be institutionalized and governed by the respective functional teams or should it be a grass-roots open-source movement within the enterprise and curated by a Service Custodian in each of the functional teams? Be sure to check out Martin Fowlers original post and do share your experiences.
