Guest Post: Services Taxonomy

November 8, 2009

Carlson Wagonlit Travel SOA vision charter states all our internal business units should contribute to delivering services. We should be able to support any external business or technical services. We designed an architectural blueprint for service categorization, to be used for the design of new systems as well as the refactoring of existing systems. The main advantages are:

  • For the business decision maker, understanding the business value of a component and its commoditization level makes it easier to make build vs. buy vs. lease decisions, and may expose business opportunities for making a service available for others.
  • For the architect, having a good grasp of the different categories assists in classifying existing or new services, as well as helps define the appropriate functionality to include in a particular service in order to promote composition and reuse.

This architectural blueprint for service categorization is presented in the following sections.

Technical/Infrastructure Domain Services

Technical / Infrastructure Services are common facilities that do not add any explicit business value, but rather are part of the required infrastructure for the implementation of any business process in an SOA. They are typically purchased or custom built and centrally managed. Let’s cite for example:

  • Communication Services transport messages into, out of, and within the system without being concerned with the content of the messages.
  • Utility Services provide generic, application-agnostic services that deal with aspects other than transporting application messages.
  • Security Services provide required security-related capabilities like identity, privacy, confidentiality, non-repudiation, etc.

Business Domain Services

We decided to support three hierarchy levels for managing Business Domain services.

  1. Core Business Process Services tie together the data-centric and action-centric building blocks to implement the business processes of the organization. They are in general stateful services (manages Business Process state).
  2. Business Services implement the business-level capabilities of the organization. They are in general stateless services and represent the action-centric building blocks (or “atomic verbs”) which make up the organization’s business processes.
  3. Business Entity Services unlock and surface the business entities in the system. They are in general stateless services. They can be thought of as the data-centric components (“nouns”) of the business process: employee, customer, sales order, and so on.

Application Domain Services

Application Processes implement the specific business-level capabilities or some other action-centric business logic elements (“building blocks”) which are unique to a particular business application context. Those services are not managed by the SOA governance team, with stateless or statefull service support. Most of the time, the portal is consuming the Business domain services. We intend to test information mashup in the future.

About the author

William El Kaim is lead IT Architect at Carlson Wagonlit Travel for Global products. He spent more than 10 years working for consulting companies and client companies on enterprise architecture, solution architecture, SOA and Web services, and Identity and Access Management architecture. He had to implement several enterprise Architecture frameworks, processes, on different tools. Finally, he contributed to OMG ADTF work on UML 2 and Model Driven Architecture, and worked with SEI on software product line. You can follow him on twitter (welkaim) or read its blog (Blog:

tweet this add to post to facebook

Building Reusable Services Meetup Talk

June 19, 2009

I recently presented at the Silicon Alley NYC Meetup on service orientation and building reusable services for Service Oriented Architecture (SOA) initiatives.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

Software Reuse Quick Tip #13

June 18, 2009

Tip # 13 Reuse Data Schemas in Business Process Orchestrations

When implementing business process orchestrations, look to reuse data schemas. This has several benefits:

  • Reusing data schemes will make your business process interfaces simpler and more modular. You will be able to decouple processing data from core entity data.
  • Data transformations from business process orchestrations to data services will be minimal (if any) because the interfaces will use identical data structures. This is often referred to also as using a canonical data model.
  • This reduces maintenance effort on the schemas themselves because multiple business process will leverage these data schemas.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

Reblog this post [with Zemanta]

%d bloggers like this: