Application Services
While an Application Service is considered a basic service type, services contained in this service type are not considered core services within the context of SOA; rather, they are referred to as supporting services. These concrete services are usually fine-grained and are associated with a specific application. In other words, they have application (or silo) scope and therefore are generally not shared in the enterprise. Application Services are typically identified and defined by application developers and are specific to the application scope they are defined under.

Application Services are generally used to perform fine-grained application-specific functions such as validation, data collection, and data transfer. For example, when creating an auto quote the application developer may create services such as addDriver, addAddress, and addVehicle. These services are used to accumulate the data needed by the Business Service as defined by the Business Service input and output specification.

A service classification template containing the primary characteristics for the service type of Application Service might look like Figure 4.

Infrastructure Services
This service type classification defines those services that are used to support the enterprise. Examples of Infrastructure Services include such aspects as logging, auditing, data access, and security. These concrete services are generally shared by the enterprise and used by Enterprise Services (and sometimes Application Services).

What distinguishes Infrastructure Services from Enterprise Services is that Infrastructure Services implement non-business functionality. The gray area between Infrastructure Services and Enterprise Services appears when considering such regulatory requirements as auditing and compliance. Although some forms of auditing and compliance are designated as business requirements, these services do not specifically address a particular user or business function; rather, they support the business requirements.

Infrastructure Services are typically identified and implemented by application developers or an infrastructure support team. They generally have enterprise-level scope, which is one reason they are typically confused with Enterprise Services.

A service classification template containing the primary characteristics for the service type of Infrastructure Service might look like Figure 5.

Service Taxonomy Guidelines
You can certainly extend the basic four service types either horizontally or vertically to suit your particular needs. However, before considering extending the basic hierarchy, you may want to consider the following service taxonomy guidelines:

Start your service taxonomy with the four basic service types described earlier first. If you think you need an additional service type at the same level, make sure it is non-overlapping with respect to other service types. If you think you need an additional breakdown of service types below the basic level, then read on.

Avoid the common pitfall of creating domain-specific service types (i.e., types that are specific to divisions or functional groups within your domain). For example, if in the insurance domain, avoid creating service types such as Claims Services, and Policy Services. These are not service types, but rather actual domain service names that are represented through the various types of services. To put it another way, there are many different service types that constitute a Claims Service (e.g., Business Services and Enterprise Services). Don't confuse an actual service name (e.g., Policy Service) with the service type (e.g., Business Service).

Keep your classification hierarchy taxonomy as simple as possible and avoid accidental complexity; remember one of the goals of the service taxonomy is to facilitate communication between the various stakeholders and groups involved in the SOA initiative. A complex hierarchy of service types will create confusion and hinder the basic understanding of the service types you are using. A complex hierarchy invariably leads to increased debates and lengthy meetings about how deep and wide the hierarchy should extend, and also increases the chance for overlapping service types in your classification hierarchy.

Consider creating a simple context diagram showing the relationship between the different service types in the service taxonomy, particularly if your classification hierarchy extends beyond the basic four service types. This can greatly help in understanding where the service types fit into the big picture.

Create an agreed-upon template for recording the definition and attributes of the service taxonomy. In general a tree-graph coupled with a context diagram and a simple document template is all that's needed to effectively document and communicate the service taxonomy. Try not to go overboard with complex tools or UML to describe the hierarchy. If you need such tools, chances are your service taxonomy is too complex and should be simplified.

Don't wait until the SOA initiative is well underway before beginning to put together a service taxonomy; start creating a taxonomy as soon as the SOA initiative starts by using the basic SOA service types and refining it as necessary during the project initiation phase of the initiative.

If you end up with something like a "duck-billed platypus" when creating the service taxonomy, stop and revisit how you are defining your service types. After all, you are just classifying service types, not something as complex as the animal kingdom. Chances are you are introducing accidental complexity and making the service hierarchy more complex than it actually needs to be. Keep it simple.

Summary
An effective service taxonomy developed early in your SOA initiative can significantly improve your chances for success. Communication, clarity, and collaboration between the stakeholders in a SOA initiative are all key to the success of the overall effort. Start simple, use the four basic service types (Business Service, Enterprise Service, Application Service, and Infrastructure Service), and only extend the classification hierarchy only when necessary. Make Mr. Linnaeus proud.