A lot has been written on the approach to service-oriented architecture (SOA) migration. Although they are referred to by many names, there is the strategic approach, which is of high quality and so is also costly and initially less responsive because of the analysis involved up front. Then there is the organic growth approach, in which services are developed on an as-needed basis within the context of projects, which is responsive, but leads to redundancy and the lack of vision leads to unmanageability later. Finally, there is the hybrid approach, which attempts to take the best of both of these worlds. It is so very important that the business analysis is not cast aside when developing the SOA through this hybrid approach to migration.

What we will discuss here is just one facet of ensuring a successful migration to an SOA, that of Classification Analysis and the use of service taxonomies and ontologies to define these classifications. Where we will differ slightly from other discussions is in our use of classification of services to help provide the necessary bridge between the complexities of services and that which the business understands of the enterprise.

All Services Are Not Created Equal
At the end of the day we have a lot of functional assets, business processes, and data locked up inside legacy systems. We do not want to reinvent the wheel for new business requirements; thus, through SOA we are attempting to expose those functional assets for reuse. A typical large enterprise can expect to have 100+ course-grained sets of services. However, many of these services are likely to be processes or composites of other lower-level services, which in turn could be reliant on data services, and so on. The end vision could end up with thousands of services to be managed (not counting versioning). A large catalog with no structure, as shown in Figure 1, is not conducive to reuse by either the business when developing requirements or IT when implementing new features or composite applications.

The Need for a Service Taxonomy
In order to manage the complexity and potentially the sheer number of services, it is quickly apparent that we need to first "horizontally" manage the classification of services.

In the beginnings of the focus on SOA it was typical to only talk in terms of a simple set of horizontal service types: shared business services, shared application services, and shared data services. While this is still good for articulating the concept of SOA, it is necessary to go far beyond this for the actual implementation and management of services.

Figure 2 shows a simple expansion of the horizontal classification of services. Although there are many published versions of this, it is not a "one size fits all" and should vary by scope and enterprise size. What is important is that the need is recognized and a suitable model adopted. An SOA implementation will mature and the organization will become more sophisticated in its understanding. It is therefore important to have the ability to recognize the need for change and adopt change in the classification models selected.

Some of the benefits that may be experienced from a horizontal taxonomy such as this are:

• Help in defining the complexity of service implementation and hence assistance in estimating the cost of implementation and/or change
• Garnering a better understanding of granularity of services and hence how composable they may be
• Assisting business in understanding the level of reusability when considering new requirements perhaps targeted at the use of a particular service
• Aid in analysis of identifying higher-level composites and façade services from atomic services to proactively populate the service catalog
• Specifying principles for service interaction, such as "services may only utilize services from the same or lower layers," etc.

This still does not provide enough clarity and we need further "vertical" classification to assist in simplifying the service catalog.

The Need for Service Ontologies
When we suggest the use of "vertical" classification, it is not really a single set of columns applied to our original taxonomy (i.e., just another taxonomy), but what is needed is a more rich, semantic, and hierarchical understanding of the services available, specifically in terms of their relationship to the business.

There is a lot of discussion about using ontologies to help map semantics of data between different models. Although this is a valid point, there is a far more fundamental set of benefits to be realized in using ontologies to provide a vertical classification of services:

• A common language is established that makes the technical and business problem domains more understandable
• Because understanding is generalized and removed from the context of potentially multiple source systems, a virtual model is being established that promotes interoperability
• Achieves a greater simplification of the development of business requirements
• An enterprise-wide understanding of the functional architecture of the business is established
• Shows the progression or lack thereof of service catalog population, and hence helps plan and prioritize the population of the service catalog
• Establishes understanding of when a service is overstepping its bounds
• Makes identification and management of service ownership much simpler

Don't give up! Take onboard an incremental analysis of the enterprise. Also, many vertical industries already have useful information or functional domain models that can accelerate the development of initial levels of service ontology, such as the eTOM for the telecommunications industry, OTA for travel industry, OFX for financial industry, etc. The enterprise should leverage wherever existing work has already been conducted and where shared ontologies already exist. Remember, the intent is to develop a semantic understanding of services within the business today, and not to redesign the business architecture for a future vision (one step at a time).

Figure 4 shows a very rudimentary functional domain model for our fictional company that can be applied as the higher levels of a service ontology. We have simply applied the top two organizational layers of our service taxonomy from earlier. Of course over time this could become much more sophisticated and there could be a service hierarchy established within these two layers. For example, when working with one client with a very large SOA implementation we established a functional domain model with five layers of decomposition.

Ontological analysis should be conducted from the outset and the functional domain models of the business should be established. This will take time and effort and should not stall or inhibit the development of services, but is conducted in parallel (as per the hybrid approach to migration). There must be a feedback loop established in the governance processes to ensure that any ontology is updated with real understanding from a project, and that ontology is refactored into services when sufficient analysis has been completed (for example taking a "while the hood is up" approach).

Figure 5 shows how the services are now classified according to their functional alignment. We have only zoomed in on the Customer Relationship Management business category, but it is evident that the services are much more understandable now that their vertical and horizontal classifications have been made apparent. It should be noted that the use of a vertical service ontology would predominantly benefit the classification of shared business services rather than other types of services.

Other Useful Classifications
The more useful metadata that can be established regarding the services catalog, the better. Furthermore it is particularly true when attempting to establish that "ever so desirable" business alignment. Other equally useful classifications could be:

• Quality of service
• Versioning services and build metadata
• Scoping services