Ten Ways to Identify Services

SOA is increasingly becoming an unavoidable part of project delivery for many organizations. It is therefore high time that practitioners avoid the dangerous practice of creating ad-hoc services and begin following proven industry principles and methods. In this article we discuss ten approaches for identifying services. The intention is for this list to become an effective starting point for service definition, alleviating project teams from the longwinded discussions about granularity, feeling, intuition and craftsmanship that have historically been part of initial service delivery phases. This collection of methods is the result of research. Therefore, it is important to understand that even though some have become established industry practices, there are still pitfalls and trade-offs that need to be taken into consideration. Introduction: Service Fundamentals In a service-oriented IT landscape that has been shaped according to the principles of service-orientation, functionality and data are provided by means of services. These services can be defined in a uniform fashion based on international standards (XML, SOAP, WS-*), or they may be based on more traditional and proprietary mediums. Modern integration technologies, such as the ESB, enable consumption of services regardless of location, platform or programming language. By orchestrating services in the desired order, business processes can be optimally supported with functionality and data from systems both internal and external to the IT enterprise. Along with the rise in popularity of SOA began a community-wide discussion about how to best identify services. When is a service "too big" or "too small", when is it "too specific" or "too generic", or exactly "right"? Before getting into the most common approaches we need to establish some fundamentals. First and foremost, generally accepted architectural principles for services exist. These design principles should always play a guiding role when identifying services. The eight established service-orientation principles [REF-1] are: Standardized Service Contract, Service Loose Coupling, Service Abstraction, Service Reusability, Service Autonomy, Service Statelessness, Service Discoverability and Service Composability. The golden rule to successful service identification is that services should adhere to these principles. Secondly, there are various ways of typing services using service classifications or service models. Examples include presentation services, process services, business services, application services and data services [REF-2]. Naturally there are approaches that are particularly suitable for each type of service. In this article we primarily focus on methods for business and application-centric services. When desired, these two service types can be further subdivided (e.g. into create, read, update, delete, transform, generate, select, value, validation and calculation services [REF-3]). Finally, what determines if a service is well-defined depends on perspective: an administrator will have different requirements than a process designer or a tester. Ultimately, the success of a service is measured by the value it http://www.soamag. com/I13/1207-1.asp (1 of 7)10/12/2007 10:44:34 PM