As we've noted here in this blogsite, and many other leading thinkers in this space such as Dave Linthicum have reminded us, the 'A' in SOA stands for 'architecture.'
But what does the 'S' really mean? What is the proper way to define a 'service' in the context of service oriented architecture?
EDS' Fred Cummins recently took up this question, noting that as OMG finalizing the specification of SoaML (SOA Modelling Language), "there were lengthy discussions resulting from ambiguity of the term 'service.'
Some industry definitions:
From the SOA Reference Model from OASIS: "The means by which the needs of a consumer are brought together with the capabilities of a provider."
From the Open Group, SOA Working Group: "A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a 'black box' to its consumers."
As these definitions focus on business relationships, Fred reports he recently drafted a working definition with the assistance of Jim Odell and the Webster dictionary:
1. "The work or action performed by one that serves (e.g., gives good and quick service)."
2. "The occurrence of a unit of work or action provided to a particular consumer (e.g., provided a service)."
3. "An entity supplying some public demand (e.g., a bus service)."
4. "An organizational entity that offers the capability to perform defined types of work or action for consumers (e.g., ABC accounting service)."
But what does the 'S' really mean? What is the proper way to define a 'service' in the context of service oriented architecture?
EDS' Fred Cummins recently took up this question, noting that as OMG finalizing the specification of SoaML (SOA Modelling Language), "there were lengthy discussions resulting from ambiguity of the term 'service.'
Some industry definitions:
From the SOA Reference Model from OASIS: "The means by which the needs of a consumer are brought together with the capabilities of a provider."
From the Open Group, SOA Working Group: "A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports). It is self-contained, may be composed of other services, and is a 'black box' to its consumers."
As these definitions focus on business relationships, Fred reports he recently drafted a working definition with the assistance of Jim Odell and the Webster dictionary:
1. "The work or action performed by one that serves (e.g., gives good and quick service)."
2. "The occurrence of a unit of work or action provided to a particular consumer (e.g., provided a service)."
3. "An entity supplying some public demand (e.g., a bus service)."
4. "An organizational entity that offers the capability to perform defined types of work or action for consumers (e.g., ABC accounting service)."
The term 'service' must necessarily be vague, for it is application-specific, which SOA itself is not.
Many enterprise applications regard 'services' as basically coarse-grained RPC (e.g., "do credit check", "submit loan application", etc.). Web 2.0 companies regard 'services' to be resources that can be manipulated using HTTP such that the services scale in the same fashion as the web itself.
SOA is nothing new, of course: we have been embracing loose coupling and well-defined interfaces between the pieces of a software system (whether distributed or not) for decades. The nature of those interfaces (services) changes with the implementation technology (e.g., XML/HTTP or abstract C++ classes), and what those services are employed to do.
Finally, in our most recent iteration of SOA some observers have noted a useful classification scheme for services. John Crupi created a pragmatic hierarchy for services, based on a multi-level model (his so-called lasagna model, as a corrective to the spaghetti model :-). So looking for a simple one-line definition of 'service' may well be impossible.
Thanks for the further elaboration, Ron. It looks like 'service' remains a loose term, by necessity. Even in Fred Cummins' definition, it is closely related to the generic term for service.
A and S...
Well did we really establish that A was for Architecture and not for Approach?
I am not so sure. The extensive nature of the organizational changes that usually needs to go hand in hand with SOA, might argue on the contrary. Business cases that do deliver seems to be mostly about changing how an organization change its relation to TI services more that about technology.
I do see some parallelism with Agile project approaches, less and less we talk about doing things but more about how we approach and measure them.
Cheers,
Shouldn't we be taking SOA concept beyond IT architecture. Services are a natural phenomenon like tree structure and group theory. Business will embrace it more if we remove the Architecture 'weil' from it. Service concept could be expanded to areas such as outsourcing, globalization by creating a value exchange process with services.