[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal on key service concepts
So I have a somewhat heretical proposal for the committee. I am coming to conclusion that service is not a normative term. That is not to say that at the core of SOA is the concept of service. A service is the performance of work by one for another. What is typically, and nebulously, referred to as a service in SOA is actually a service offer. A service offer is a proposal to perform a mission function for others. A service is the actual performance of that work by a service provide for a service consumer. The use of the word "service" is adopted from the notion of business services in commerce. The noun "service" is defined in dictionaries as the performance of work (a function) by one for another. Service is "an act" not "a function," a common misperception is that services are functions. There are several supporting definitions that also need clear definitions to accurately communicate the definition of a service offer. Mission Entity An entity operationally responsible for performing a mission function, or operationally in need of having a mission function performed. Mission entities may include entities such as individuals (humans) as well as organizational units, etc. Service Provider The mission entity that performs a mission function for another mission entity Service Consumer - The mission entity that requests to have a mission function performed by another mission entity Service Offer A proposal to perform a mission function for others (Service Consumers) An offer is made by a specified Service Provider. Mission function behavior is described by a referenced (or embedded) Service Specification The mission function is made accessible at Service Access Points Service Specification A formal description of a mission function to be offered. Includes a description of how to interact (inputs/outputs and associated semantics) Service Access Point A logical location where a mission function is made accessible (a.k.a. "endpoint"). A mission function may be offered from one or more Access Points Within this service concept, there are several implicit dualities. There is the duality of capability and need. Without a need, there is no reason to perform work. Where there is a need, a capability to satisfy the need will eventually emerge. There is the duality of service offer and service provider. An offer to perform a mission function for another cannot exist unless some entity offers to perform that service. That entity is a service provider. A final duality is that of a service provider and a service consumer. The existence of both entities is implicit in the definition of service; 'by one' and 'for another.' This necessary duality of provider and consumer gains clarity when thinking about contracts and exchange of value. Outside of technology, these notions of service, service offer and service provider track well with the business world. For example, a caterer offers to prepare and provide food (appetizers, accoutrements, etc) for another, typically in exchange for a fee. A caterer may also perform these functions for himself (for example a caterer most probably prepares his meals). However, even if the caterer prepares exactly the same food, we do not refer to this act of food preparation as a catering service. It is only when we introduce the concept of performing this act for another can it be accurately described as a service. This distinction between service provider (by one) and service consumer (for another) depends heavily on perspective. The distinction between these two entities rests squarely on the exchange of value. Consider a caterer that prepares food for his wife. If our perspective is the "household"; then food preparation is really an internal function, not a service. If, however, our perspective is at the level of the individual, the caterer does perform a service. The value that is exchanges may not be monetary, it may only be gratitude. Nonetheless, there is an exchange of value. This exchange of value tracks well with the themes of an offer, contract and consideration. This closes the loop back to the definition of service - "performance of work by one for another." First, there is an offer to perform that work. Then there is agreement between two parties, the entity which offers to perform that work and the entity which needs the work to be performed. The performance of work has value for the entity which needs to work to be performed. In turn, this entity must provide something of value (consideration) to the service provider. So where does this leave SOA? Consider first the definition for architecture - the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. In the technical sphere, people often equate architecture with design. However, design is only a part of architecture; it is the representation of structure and relationships. Architecture encompasses more than just design, it is a methodology to evaluate questions like: what are the appropriate components? What aspects of relationships are critical to represent? What are the principles that guide these selections? What are the criteria that are used to shape design decisions? Therefore, SOA is a methodology whereby business services are the key organizing principles that drive the design of IT to be aligned with business needs. These business needs may be about is the buying and selling, or exchange, of goods and services. In the government, business needs are suitably described as mission needs. It is often difficult for those of us (myself certainly included) with a technical background to recognize how "adopting a SOA approach" will transform the way we think about systems. There are three sequential areas of analysis: 1) An operational analysis of the mission needs and mission functions to satisfy that need. 2) A definition of service specifications for service offers 3) Analysis of the access points and agents that make accessible and implement those mission functions. This third step is where we start getting into the design of software and devices that actually implement a mission function as a Service Provider Agent. Often, such agents are defined using Web Service technologies. Joe identified an important difference between creation of a Web Service and the creation of a SOA. Let me take that a step farther. Focusing only on definition and development of web services will not automatically result in the alignment of technology with business needs. Therefore, developing web services does not imply a SOA Focus. Rebekah Rebekah Metz Associate Booz Allen Hamilton Voice: (703) 377-1471 Fax: (703) 902-3457
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]