Service Taxonomy

Something that you may run into in your conquest of adopting SOA is the Service Taxonomy. Taxonomy, according the Oxford English dictionary on my Mac, is the branch of science concerned with classification. Aside: Did you know that you can hit control-open apple-d with the mouse over any word and MacOS X will pop up a definition? I never knew MacOS X had this feature but now find it incredibly useful. A service taxonomy, therefore, is a classification of services. Back when I was first getting into the SOA space, the chief architect at the company I was with told me that we needed a service taxonomy, so I set about trying to create one.

What I found in that endeavor was that taxonomies are difficult. It isn’t difficult to come up with a taxonomy, however, it is difficult to come up with a taxonomy that adds appropriate value. There are an infinite number of ways of classifying things. Take a deck of cards, for example. I could sort them by suit, by color, by face value, or by number (and probably many of other ways, as well). Which is the right way to do so? It depends on what your objectives are. To jump into a classification process without any objectives for the classification effort is futile. It may keep someone busy in Visio or PowerPoint for a while, but what value does it add to the SOA effort?

Two areas that I’ve found where taxonomies can add value to the SOA effort are service ownership decisions and service technology decisions. I won’t say that these are the only areas (and I encourage my readers to leave comments with their ideas), but I think they are a good starting point for organizations. Solution architecture is what many of you may refer to as application architecture. I try to avoid using the term application anymore which I’ll go into in another post some time. In solution architecture, the architect defines the major subcomponents of the solution that will undergo detailed design. A key activity of this is service identification. Services represent boundaries, and one place a boundary typically exists is an ownership domain. Therefore, to assist the solution architect in identifying the right services, a taxonomy that can assist in ownership decisions makes a lot of sense. Be careful on this one, however, because ownership is often defined in terms of the existing organization. Anyone who has worked in a large enterprise knows that organizations are fluid, not static. Your taxonomy should be classifying the service, not the organization. The most common classification that clarifies ownership is that of business services versus infrastructure services. As a sample, you could define two the categories this way:

A business service is one whose description contains terms that are specific to the business. That is, if you were to take the service to another vertical, it may or not make sense.

An infrastructure service is one whose description is not specific to the business at hand. It is likely to be equally applicable across many or even all verticals.

Now, this classification certainly isn’t rock solid, since a business service like “Hire Employee” fits the later definition, but in general, it attempts to differentiate between things like security services from ordering services. Your organization may have an infrastructure area that handles infrastructure services, while the business services are likely handled by the development group. The classification itself doesn’t mention any specific organization, but can be easily aligned to the organizational model.

The second area I mentioned was service technology decisions. While it’s certainly possible to write all of your services in C#, Java, or any other programming language, odds are you have multiple technology platforms available for hosting services. It is the job of the enterprise architect to ensure that these platforms are used appropriately. Therefore, some taxonomy is needed that can allow the solution architect to define services that have architectural significance. If your taxonomy doesn’t differentiate between when a BPEL engine should be used from when Java should be used, then it probably is not capturing the architecturally significant characteristics. At a minimum, the taxonomy should make it clear where process orchestration engines should be used (think visual environments that are largely schema-driven), general purpose programming languages like Java or C# should be used, and where database technologies (stored procedures, views, etc.) should be used. These things are architecturally significant. A good taxonomy will remove the guesswork from the solution architect and result in solutions that adhere to the technology architecture.

7 Responses to “Service Taxonomy”

  • Alex:

    I started the process of writing such a taxonomy (actually, I want an ontology), but I realise I can’t possibly do it all by myself. I’ve looked for open possibilities and raised the issue on SOA aware mailing-lists, without any luck. If anyone has pointers, I’d be happy. If not, let’s get together and create one.

  • Todd:

    I’m working with a colleague who is very interested in ontologies, unfortunately, he doesn’t blog. It’s a subject that I continue to learn more about, and certainly, it’s importance to semantics will be critical as SOA becomes more mature within organizations.

  • Just want to direct you to Swoogle ( in case you haven’t come across it. You might find it interesting and helpful–Keith.

    From the Swoogle FAQ:

    “Q: What does Swoogle do?

    “Swoogle is a search engine for the Semantic Web on the Web. Swoogle crawl the World Wide Web for a special class of web documents called Semantic Web documents, which are written in RDF. Currently, it provides the following services to the following services:

    * search Semantic Web ontologies
    * search Semantic Web instance data
    * search Semantic Web terms, i.e., URIs that have been defined as classes and properties
    * provide metadata of Semantic Web documents and support browsing the Semantic Web. (Please refer to Li Ding et. al., Finding and Ranking Knowledge on the Semantic Web, ISWC’04 for details)
    * archive different versions of Semantic Web documents

    “Currently, Swoogle only indexes some metadata about Semantic Web documents. It neither stores nor searches all triples in an Semantic Web documents as a triple store.”

  • […] Service Taxonomy: This was originally posted on December 18, 2006 and was my 100th post. It discusses the importance and challenges of developing a service taxonomy. […]

  • Shy Cohen worked across a wide array of SOA architects, including a heavy-weight or two, to come up with a service ontology that he submitted to the architecture journal. See

    I have taken it and am extending it to use in my own IT organization. I find it is not as strong as I need it to be, but it is a reasonable starting place, and if you add principles and assumptions, then extend into specifics, you can get value by starting here.

    Hope that helps,
    — Nick

  • […] in all, I’m not sure what value this is bringing. I’ve posted previously on categorizations and taxonomies and how they need to have some purpose behind them. I’m not […]

  • Todd – Would the following become attributes of a Service and hence be used as part of a Service Taxonomy?

    – QoS profile
    – Primary mode of service invocation – real-time synchronous interactions vs. EDA model asynchronous interactions
    – Whether a service is stateless (idempotent) or stateful or conversational

    Finally, I would like to know if any of the others (for instance those who are part of Enterprise Architecture teams) who have been able to use Service Taxonomy to get a inventory of the number of services by type to assess the architecture maturity and service utilization profile of their enterprise. For instance could these metrics be used to answer the question on which types of services are prevalent in the enterprise – fine-grained business informational services or foundation business utility services or more course-grained business-function/ process related services thereby allowing one to project if the enterprise’ services are becoming more mature? Also, can these metrics be used as an aid in capacity planning as each service would have a known resource utilization map. I am wondering if there are enterprises that are able to use this information in their assessment of SOA adoption and architectural maturity.

    surekha –

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.