Defining service boundaries

 

What is a service? This simple question can truly excite any enterprise architect. And the definitions seem to be as numerous as the number of enterprise architects.

Does a service represent what we previously called a system, a database, a department within the organization, a user or a user role? The candidates are plenty. Is a service a single method or is a service a collection of methods bundled together in logical units?

In this article we will present a generic model that will fit most organizations. We have developed this model through our experiences with numerous customers. Hence the model has a proven track record of being a solid and durable way to identify services.

The model is:

• accessible by the organization outside the IT department
• capable of embracing existing 3’rd party and legacy systems as well as
• embracing newly developed services.

Different organizations have different opinions on questions concerning autonomic services, data redundancy, authorization paradigms etc. The model we suggest supports these differences and dealing with them is simply a matter of implementation. Please visit the FAQ section for more details on these scenarios.

3 layer model

The model consists of 3 kinds of services:

• Presentation services - holding the UI’s
• Activity services – holding the business logic and
• Data services – holding the data.

Below you will find some guidelines we use to identify the boundaries of the services. Usually the easy part is to divide the services vertically. It is the horizontal segmentation that causes most discussions.

Data services

Let us start with the easy part: the data services. The primary purpose of a data service is to provide support for CRUD (create-read-update-delete) operations for a given data entity. In this context a data entity is considered high-level, complex entities like an invoice, an employee (identity, cv, salary etc), a vehicle (id, owner, user, model, other details).

Data services do not support CRUD operations on low-level entities like customer name, customer address, vehicle model name, vehicle model number etc.

Data services govern data by enforcing validation and referential integrity within its own boundaries. This means that the data service validates that numbers are numbers and dates are dates. Also the data service will validate for existence of a given zip code if – and only if – the data service has a zip code register/table to validate against. If the data service does not have a zip code register, it will assume that the values are valid. The data service will not cross boundaries to validate the zip code. This rule leaves a task to the activity services above – more about this in the activity services section.

The initial boundaries of existing data services are set by the applications in the organization. Generic examples of data services are;

• Employees
• Accounting
• Stock
• Orders
• Customers
• Vendors
• …

We have the naming convention that we put a “d” in front of the name of the data service. Hence HR data service is called dHR, Customer data service is called dCustomer etc.

Basic data about the employees might be held in an HR system which means that also data about CV, career path, position, salary, benefits and training might be held here. This usually calls for a discussion as to whether we have one dHR service or if we have dEmployee, dCV, dCareerPath, dPosition etc. Experience from having been through this discussion some times now is, that it does not matter much how you make your logical model. It is a theoretical discussion but for practical use the result does not change much.

Usually the organization has existed for several years and has a lot of systems and databases up and running. Our suggestion is that you start out

Please check out the FAQ section on questions regarding data redundancy, autonomous services and caching/performance.

Activity services

The second level in the service model is the activity layer. The objective of the activity layer is to hold the business logic. The activity services will receive the messages/events depicted as trigger to the process in the process model. The activity service will perform the business logic, update relevant data services and finally fire the message/event signalling then completion of the process. This event will in turn trigger the next process.

In our experience the best way to segment the activity services is to reflect the departments within the organization. Hence an activity service is a collection of methods exposed by a particular department. The notation for activity services is to put an “a” in front of the service name. Hence the activity service representing the HR department is called aHR, aSales represents the sales department etc.

Using this segmentation it is our experience that we have immediate ownership of the service from the management of the department – the Line-of-Business (LOB) management. Using this segmentation during your project you automatically divide your questions into department specific questions. Hence it becomes easy for the project to figure out whom to address with questions regarding the business logic/process – and reversely it is easy for the LOB to answer your questions due to the fact that during your preparation you have trimmed your questions so that the question becomes an HR-only, a Sales-only question etc. Thus you automatically avoid posing questions in one department that can only give you half the answer.

Furthermore you gain an intuitive, easy to understand, 1:1 mapping between the process description domain and the service domain.

The business process domain is easily understood by the business. With a simple and intuitive map between the process domain and the service domain, also the service domain is easily understood by the business. We can see this because the LOB quickly starts using the terms aSales, aHR etc. The a-terms quickly become part of the spoken language within the business.

Presentation services

The top layer is called presentation layer. The boundaries of the presentation services are defined by user roles. Examples of p-services are pHRManager, pSalaryEmployee, pCEO, pCIO, pSalesEmployee etc. Within pHRManager lies the user experience/user interfaces from all systems presented towards users having the role of HR Manager.

To be honest we do not use the boundaries of p-services much in everyday enterprise architecture. Reason is that in most cases the user experience is defined by legacy systems outside control og the enterprise architects. As an example the user interface shown to a user of the financial system is defined by the setup of the financial system and is not in any way connected to the user interface provided to the same user in the CRM system.

For practical use today we use the concept of p-services to identify and define roles in terms of authorizations - and hence try to support single-sign-on-scenarios across several legacy systems. However we also face many challenges i related to this.

It seems like the community share a vision that some day hosting of UI's from several legacy systems this will be possible - however right now the support for this vision is very sparse.

On to SOA infrastructure.