Post originally published by Robert Laird, rglaird@us.ibm.com.

I’ve had a number of questions on the benefits of service management and how WSRR can help the business and IT in a meaningful way.
Services provide benefit in two ways. The most often cited is that of reuse. That is, a service is created that can be reused throughout the enterprise. Certainly, reuse is interesting and the benefits are obvious – work is done once instead of multiple times thereby saving the enterprise not only the development but multiple maintenance efforts of separate software objects.

The less obvious, but I think more important usage of a service is that of providing business flexibility. To have only one software object where business change needs to be made is something that the agile business will find useful. For example, think about pricing. If the business enterprise had a single pricing service instead of multiple pricing services, how much simpler would it be to maintain and update pricing for the business?

So a service management capability provides many IT and business benefits for the organization. Let’s enumerate those in more detail.

1. Discoverable: A service must be discoverable by potential consumers of the service. If a service is not known to exist, it is unlikely ever to be used. Services are published or exposed by service providers in the SOA service directory, from which they are discovered and invoked by service consumers. A service registry & repository must make discovering of services easy with ability to find services based on service classifications or keywords within service documentation.

2. Self-describing: The SOA service interface describes, exposes, and provides an entry point to the service. The interface contains all the information a service consumer needs to discover and connect to the service, without ever requiring the consumer to understand (or even see) the technical implementation details. A service registry & repository must be able to load and validate the format of SOA contracts in a fast and easy manner.

3. Composable: SOA services are, by nature, composite. They can be composed from other services and, in turn, can be combined with other services to compose new business solutions. A service registry & repository must be able to show consumer and consumes information and have available Impact Analysis information in textual and graphical form. An easy way to contact service consumers is required.

4. Loose coupling: Loose coupling allows the concerns of application features to be separated into independent pieces. This separation of concern provides a mechanism for one service to call another without being tightly bound to it. Separation of concerns is achieved by establishing boundaries, where a boundary is any logical or physical separation that delineates a given set of responsibilities. For example, an account service has open account, authorization, and audit features representing delineations of responsibilities and three separations of concerns. A service registry & repository must be able to classify services so that the usage of each service component is easily discoverable.

5. Governed by policy: Services are built by contract. Relationships between services (and between services and service domains) are governed by policies and service-level agreements (SLAs), promoting process consistency and reducing complexity. A service registry & repository must be able to specify service level agreements for the consumption of provider service by a specific consumer, an anonymous consumer, or all consumers.

6. Independent location, language, and protocol: Services are designed to be location transparent and protocol/platform independent (generally speaking, accessible by any authorized user, on any platform, from any location). A service registry & repository must support SOA industry standard contracts, including a Web Service Description Language (WSDL) contract.

7. Coarse-grained: Services are typically coarse-grained business functions. Granularity is a statement of functional richness for a service—the more coarse-grained a service is, the richer the function offered by the service. Coarse-grained services reduce complexity for system developers by limiting the steps necessary to fulfill a given business function, and they reduce strain on system resources by limiting the “chattiness” of the electronic conversation. Applications by nature are coarse grained because they encompass a large set of functionality; the components that comprise applications would be fine-grained. Similarly, within an application, a service such as “get account information” (which returns name, account number, and address) could be described as coarse-grained, whereas a service to “get account number” could be described as fine- grained. A service registry & repository must support both coarse-grained and fine-grained services and must be able to demonstrate the relationship between the services.

8. Asynchronous: Asynchronous communication is not required of an SOA service, but it does increase system scalability through asynchronous behavior and messaging techniques. Unpredictable network latency and high communications costs can slow response times in an SOA environment, due to the distributed nature of services. Asynchronous behavior and messaging allow a service to issue a service request and then continue processing until the service provider returns a response.

9. Portfolio management: is in place to avoid the proliferation of services and applications. “Less is more” is the mantra, but this requires active management where both the business stakeholders responsible for the business operations and the IT stakeholders responsible for IT automation sit together to discuss how to extend, retire, provision, or reuse an existing services portfolio of shared business services. Reuse becomes a priority versus buying or building from scratch. A service registry & repository must support the design time governance to ensure reuse is taking place.

10. Strategic planning: addresses sharing across the organization for increased business operational flexibility. Sharing of services and its enabling infrastructure occurs regardless of whether the organization represents a centralized or decentralized IT delivery model. Issues pertaining to standardized business processes are addressed as the return of investment of the overall organization is favored over the investment of a single business unit.

11. Requirements gathering: also change how business and IT interact and relate when specifying requirements. Practices that promote application silos give way to practices that promote the strategy of “build once and reuse.” This requires a twofold approach: providing a view into what can be reused at the business level during requirements gathering and moving away from specifying requirements as functional domains, which is largely done today with use case modeling.

12. Project prioritization: takes into consideration the shared functionality necessary for the on-time, on-budget delivery of projects. Globalization, increased competition, and empowered customers force a choice about what to do first. Services such as applications must be part of any prioritization scheme.

13. Organizational change management: is the answer to how barriers to shared services success can be removed organizationally. Organizational change management is required when adopting new strategies, such as SOA, because it requires a change in how teams develop applications, relationships, and interactions between business units and IT and changes within IT departments as to how they interact.

14. Service Categorization – there is a categorization or labeling of services, whether they be described as business services, IT services, information services, or utility services. Grouping services can help with understanding the degree of reuse possibilities, the domain covered, the business area scope, or ownership model of a service. Governance and provider responsibilities can vary based on the classification. For example, business services may be assigned to business stakeholders as owners and IT services assigned to owners in the IT department. Categories can also define service domains, where a domain defines a set of related services that someone can own, maintain, support, and fund. If an organization has defined a taxonomy of services, the classification helps architects, designers, and developers understand the scope of functionality to include in a service to promote composition and reuse. Enterprise architects can help with classification, and it becomes a fast path into searching for services and leveraging architectural frameworks for the design and implementation of services. Service classification or categorization helps to match service types to a business process model, to logical operational models, or to layered component models. For example, services could be divided into two categories of business and technical services, where business services map to business process models and technical services map to operational aspects (such as authentication and authorization). Armed with this taxonomy of business services, it helps prospective consumers determine where to first look for reusable services. Or the taxonomy helps architects determine the software stack necessary to address qualities of service. Categorization is advantageous as the label tells the consumer, the practitioner, something about the service like granularity (such as business sub-process service) or provider type (legacy service). A taxonomy and service classification aids in creating governance models, service ownership models, and reuse as the service repository is organized accordingly. This enables faster access to identifying services that can be reused. A service registry & repository must support service categorization and service metadata.

15. SOA governance: extends IT governance with the context of SOA. SOA involves people, process and technology, is cross-functional involving lines of business and IT. SOA governance extends all aspects of governance present in organizations necessary for creating specific outcomes (e.g., faster time to market for new products) using SOA. Governance activities focus on the outcomes an organization desires to effect via SOA adoption. SOA governance shines a light or magnifies those aspects of IT governance that should be enhanced when seeking to achieve one or more benefits from SOA adoption. The service registry & repository must support design time and run time governance.

16. SOA executive steering committee: provides visibility and commitment to SOA within the enterprise and brings proper focus to bear when necessary to remove political roadblocks or other obstructions. The SOA executive steering committee also ensures business involvement and commitment to SOA adoption.

What have you found to be useful from a service management perspective at your enterprise?

You can also email me – Robert Laird at rglaird@us.ibm.com

Join The Discussion

Your email address will not be published. Required fields are marked *