THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

This Information Model is describing the important entities needed to define SOA in a Business Perspective. It is based on the structure in the Zachman Framework and the interrogative WHY, HOW, WHAT and WHO. The interrogatives are rearranged in this order to be presented to the business people on various levels.

The description is presented step by step to make the understanding easier. Most descriptions of the SOA Concept are made from an IT perspective and are usually difficult to understand for business people.

This description is based on the assumption that you are familiar with data modeling and understand what a business process and an information entity is.

1. Service Components

A Service Component includes a specific amount of functionality that can be reached by a number of well defined Service Interfaces. In the IT environment these interfaces are normally called Service Contracts.

The Service Component and the Service Interface are the main entities in the SOA Concept. It is wise to specify them and not just call them Service or Interface. Service means a number of different things; it may be the result of a Business Process that is delivered to a customer or it may be perceived as a Web Service, when sending a message.

2. Entity and Entity Group

The Service Component should be defined related to a number of business Entities. This is a very important statement! If you only base your Service Components related to your Business Processes you will loose control. Which means you will have the same data handled in many Service Components resulting in bad Data Quality. You will also destroy the opportunity for reuse of Service Components in your business.

This statement also means that the Enterprise Architect should be responsible for defining the Service Components in the business based on the Enterprise Architecture.

All entities related to one Service Component are collected into one Entity Group. The Entity Group is sometimes named Subject Area or even Domain. The latter may be misunderstood since it usually stand for something else and not just a group of entities. Notice that an Entity may only belong to one Entity Group.

3. Business Process and Process Activity

The SOA Concept will facilitate the change in focus from standard Business Processes to strategic Business Processes. The standard Processes should be handled in ERP systems or be outsourced to a partner that has them as their strategic processes.

The SOA Concept will also allow the Business Process to orchestrate (adjust) its Process Activities for a specific customer or product. This agility is one of the main driving forces behind SOA and is based on the" loosely coupled" Service Components. That the Service Component is"Loosely coupled" means that it is independent of its technical platform and is reached through a well defined Service Interface.

A Process Activity is related to a specific Service Interface (not just a Service Component). One Service Interface may be reused and supporting many Business Activities in different Business Processes. This relationship is created in the Requirement Specification process. If the Service Interface already exist this is easy. If the Service Component already exists, a new Service Interface has to be created.

4. Business Vision and Business Rules

The Business Processes should be related to the Business Vision and they should be divided into strategic and standard processes. The strategic Process should be prioritized giving the Enterprise Architect the basis in which order to develop and implement the Service Components.

The handling and management of Business Rules are a very important part of the SOA Concept. Normally the Business Rules are just hidden somewhere in the legacy systems. Which means they can not be managed and changed easily.

Now the Business Rules have to be defined and checked against the Business Vision. A Business Rule must be related to one or maybe several entities. In that way they are always related to a specific Service Component, but there may also be a need to relate a Business Rule to a specific Service Interface.

5. Service Level Agreement (SLA)

The best Service Component implementation may easily be destroyed through a bad operation by the Service Provider. Therefore the creation and the management of a Service Level Agreement are of outmost importance. The SLA is agreed between the Service Provider and the Process Owner. If one Service Interface is used by many Process Owners there must be a specific SLA for each Process Owner.

Comments

Of course there are many more detailed entities to be defined and described when implementing a SOA Concept in your business. This description describes the most important entities on the business side. The same thing should be described for the IT side. That will also result in more relationships between the Business and the IT making a true traceability and a long-term agility possible.

A long-term agility must be based on a stable information model describing the SOA Concept both in a Business Perspective and an IT perspective.