Services Meta Model

minas@optusnet.com.au — Mon, 18 Mar 2002 23:32:14 GMT

The reason for this post is to identify the common services layers, the relationships between the layers and the Business vs Technical perspectives most prevalent in the relevant services layers. This is an important point to identify, as it is usually a point where communication inefficiencies between Business & IT arise.

The diagram below shows the Services Meta Model, spanning the High level Business Services down to Technology Services.

Starting from the top, the High level Business Services are the Business Reason for the Organization being. These are the value-add services of the organization offered to the outside world.

Going down the chain, the Business Services are realised through one or more Business Processes.

A Business Process in turn is usually executed via a number of manual and/or automated steps.

Process Step Services (often called Business Services by technical articles that focus on IT only) are those automated steps that are implemented via software. These services address a the unit of work required to be done by a discrete step in a Business Process.

An Application Service is one that is not usually tied to a specific Organization's Business Process. It is a foundational component that can be used to deliver Business Value and Functionality, however is too fine grained to be of any direct Business value.

Technology Services are those services that are usually cross-cutting amongst Application and higher level Services.

The Process Step Services (PSS) are the points at which SOA based solutions deliver their value. They are the point at which

meaningful integration is done as far as Business Functionality is concerned
meaningful Services to the Business are delivered
orchestration of other PSS' and potentially lower level services are done using BPEL or equivalent

PSS are basically what defines an SOA service and distinguishes it from say, any old web service. This is the level of functionality that the Business really cares about. Anything below this is not directly important and meaningful to the Business. It is at this point that you want to reduce dependencies such that Business Processes can be easily orchestrated and changed quickly.

At this point, these services can be logically grouped into logical Business Components that are merely logical groupings of these services.

If you're a developer, this is the point that the Business wants to to talk to them. They will not usually care (apart from reasons like: out of interest, untrusting souls etc.) about anything lower level.

If you're a business person, this is the level you should go down to and define Business Level Requirements at. No lower, no higher.

These days, the Service Definition for a PSS should include:

a sensible name, scoped as appropriate, containing the Business Service that it's being developed for
input/output Data Definition (in the form of XSD of course, and if you want to save on overall development time, costs, confusion & increase system quality, get the Business to define the Data in XSD, not in unstructured data such as Documents, Tables, Spreadsheets etc.). You can also use a WSDL for this and the above step.
Message Exchange Patterns (MEP)
SLA's, KPI's etc. and anything else relevant to the Business
anything else you require such as Exception Management properties and behaviour, references to other documentation, summaries etc.
a logical owner for the service

Notes:

Even though it's physically possible to develop services that skip layers, this is not recommended. Each type of service is in itself layered and can use types of its own.
Each layer can be thought of as a Process in itself, however that's not the focus here.

ESB Envelopes Whitepaper

minas@optusnet.com.au — Sun, 03 Feb 2002 23:35:56 GMT

The following documents explain the ESB Envelope in some detail, and explains its positive effect on a services based archtiecture.

Archive

Services Meta Model

ESB Envelopes Whitepaper