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.
- 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).
- 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.
- 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: http://blog.resilient-it.com/).