Service Oriented Architecture (SOA) continues to be one of the hottest topics among Chief Information Officers. Although SOA implementations keep eating up more and more of the overall IT budget, there is often not enough effort carried out to govern and manage an ever proliferating portfolio of services. One major issue that keeps haunting both existing and nascent SOA implementations is how to classify or categorize a wide range of services. If services are to be governed properly, they need to be defined in accordance with a pre-ordained methodology or classification system that best aligns (tightly couples) them with the business. Many times it will be prudent to map these service types to specific business areas or technology platforms; however forcing too narrow of a classification on services can have an adverse future impact on SOA scalability. The inverse is also true: If you create and catalog your services with too high of an abstraction, you may wind up with massive redundancies of business rules and logic.
The biggest impediment to implementing a robust SOA governance initiative is retroactively classifying existing services that have sprung up around the enterprise in response to different historical business mandates—some industry pundits refer to this unplanned proliferation of services as JBOS, meaning “Just a Bunch Of Services.” To make matters more complicated, when companies really start to do cursory analyses on their existing services, they find that disparate implementation, platform, and interface methodologies have been leveraged to create their "productionalized" services. The bottom line is that we can not properly get a handle on the governance and management of services until we define them using pre-agreed upon standards. For example, consensus must first take place on how modular and granular a service should be. Although this is mostly a matter that will be addressed by an organization’s SOA architects and IT gurus, business considerations should drive these discussions. Business process use cases should be the guiding light that determines the minutia of their supporting web services. In some cases, defining hierarchies of services will help matters if corresponding business rules and processes can be decomposed in a similar vein. Upon examining business use cases, some existing services may need to be broken down into smaller functional units and other services may need to be congealed and combined into composite services.
One of the best ways for a company to start to understand their existing services, and begin cataloging and classifying them, is to examine their services from a consumer/subscriber perspective. By understanding the consumer of a service, you will often, by default, gain a great insight into the nature of the service provider. In some cases, the analysis and “typing” of services will need to start at the highest levels of service classifications. Although a service can be classified in any way that makes sense to the business, there are some standard high-level industry classifications that help crystallize the nature of origin or essential ontology of a service:
Integration services provide for more seamless communication between external applications and enterprise databases and ERP solutions. Integration services help overcome the various issues of data and business processes that reside on different operating systems, use different database solutions or different computer languages, and exist in legacy systems which are no longer supported by a vendor or help desk.
Content subscription services provide content to subscribers according to a pre-determined service agreement. The most popular subscription services in use today are RSS ("Really Simple Syndication") services, a format for disseminating and collecting content from sources across the Web, including newspapers, magazines, and internet blogs.
Presentation services aid in the formatting and contextualization of various information and enterprise knowledge to distinct user communities.
Information services perform important data manipulation or provide structured and secured data access. Many of these services provide transformational logic or perform calculations in conformance with operational business rules.
Management services are most commonly associated with the administration of control of hardware-focused applications and networks. The most frequently cited management service is Simple Network Management Protocol (SNMP). SNMP is used for collecting information from, and configuring, network devices, such as servers, printers, hubs, switches, and routers on an IP network.
Quite often, logically organizing your services is a catch 22. Knowing how you will create services depends on how those services will be classified once built and knowing how to classify services depends on the functional considerations of current and planned future services. This conundrum often creates a compelling case for an information model (independent of any service consumer or service provider) that establishes general interface specifications for service interaction and invocation. This high-level model is called a canonical model. By establishing a canonical model, a company can more easily classify their services logically without engaging in a bunch of low-level data and method/function mapping tasks. Much like any other gap analysis or mapping exercise, performing an analysis of all possible consumers and all possible providers that deal with a particular piece of information, and then trying to find common ground across all of them can be a painful and time-consuming exercise. This canonical model will have breadth across all business silos, so a loose coupling between consumers and producers of services is modeled - one that is not dependant on logical or physical constraints or empirical dependencies. From this canonical model, an applications architect can focus on logical and physical service definitions from a top-to-bottom approach, creating more specific informational models that suit important low-level needs. Consider the inverse: If the architect employs a bottom-up approach to service modeling, consistent classification of services becomes a perpetual moving target and is not driven by a true enterprise focus.
Assuming that we have defined our services in a manner consistent with the corresponding real-life business processes and data sets that they support, the more difficult task of continually managing, maintaining, and enhancing them comes into play. Like other governance initiatives, SOA governance should be managed via a specialized dashboard created for just that function. (For more information on SOA governance dashboards please refer to my other Dashboard Insight article for May 2008.) http://www.dashboardinsight.com/articles/digital-dashboards/building-dashboards/soa-governance-dashboards-the-whole-picture.aspx
About the Author
William Laurent is one of the world's leading experts in information strategy and governance. For 20 years, he has advised numerous businesses and governments on technology strategy, performance management, and best practices—across all market sectors. William currently runs an independent consulting company that bears his name. In addition, he frequently teaches classes, publishes books and magazine articles, and lectures on various technology and business topics worldwide. As Senior Contributing Author for Dashboard Insight, he would enjoy your comments at email@example.com
Copyright 2008 - Dashboard Insight - All rights reserved.