Introduction SOA for Organisations

From Geostandards

Relationship between business and technique

SOA offers new possibilities for a business to guide their developments more strongly. In another, more effective way, it meets the functional needs of a business. Applying a SOA is only really fruitful if it is both supported and applied by the business and the technique.

An SOA is not a short term investment or effort but it is an approach that focuses on the long term. This SOA characteristic needs to be clearly secured within the organisation at the interface of business and technique. Automatically, this role is in the hands of the Enterprise Architects who have the task of translating the strategic vision which an organisation has about business, into a stable long term approach, which makes it possible to realise this strategic vision from a technical point of view. The Enterprise architecture not only creates frameworks via principles and guidelines, but also ensures the safeguarding of these frameworks.

Making the primary processes of the organisation clear is the minimum role of the Enterprise architecture. The processes are drawn up by process architects. Within an SOA context, the role of the process architects is crucial. Services are distilled very easily from the processes. The process transitions or individual steps in the process are the applications which make the requested function and/or information available via a service. If several primary processes use the same information and/or function, the need to make it available as a service increases.

Based on their expertise, the process architects can provide a list of potential services. Business architects are the ones who can be addressed to indicate and appreciate the usage of the services for a business. In conclusion, it can be stated that the combination of expertise found within the Enterprise Architecture which ensures the guarantee in the long term, the specification of potential services and the benefit of each service, is of essential importance to an SOA.

Within a chain, roughly the same approach and fields of expertise should be completed, in order to have a successful SOA. This differs from the approach that an organisation which can take decisions autonomously has about what a service is. It has its own definition of benefit and need. Within a chain, it is necessary to make sure that a consistent and coherent set of services are useful for the chain. This means that the chain processes based on ‘chain architecture’ have to be made clear and that they can be distilled based upon criteria such as what benefit they offer for the chain services from the process transitions and process steps. The chain architecture should also provide content for the standardisation of, among other things, the name that is given to services, message definitions, metadata and for the stimulation of the application of services.

Ownership

The services which are offered usually have a clear owner. The function and information that are offered by a service are guaranteed by the owner in many ways. Amongst other things, these include:

• The various ways they are available;
• The quality and the user right.

The issues above have to be included in a Service Level Agreement (SLA). Within the ebXML family, possibilities of record those issues exist, but they are not sufficiently detailed and applied. Since the client of a service makes a ‘human’ validation step toward the benefit of a service, the same validation can also take place in the SLA of the service. This means that the SLA has to be available in a readable and clear way as part of an attachment in a service definition.

Service orientation makes possible or is an invitation to provide more functionally set up and business related services. Orchestration (assembly) of services can be used for this. Offering a land registry map at a provincial level is an example that combines various municipal systems to one area. These combined services should also have a clear owner.

Within an organisation this can be settled (relatively) easily, but in a chain where services of several parties are made into one service, some provisions have to be made. This can be realised by drawing up mutual agreements and by making one of the providers of the underlying services the owner. It can also be realised by involving a third party and, in this way, offering the service under delegated ownership. The goal should be to have one contact for a service. This third party could be the chain co-ordinator, who acts as a kind of publisher of the services.

Security

Services provide information and functions that should not be used or be made available to everyone. Adequate security is an SOA requirement. Within a chain, the chain co-ordinator or the mutual parties will give a minimum set of security requirements that the partners have to meet.

An important part of those requirements is the confidence of the other parties. This is a requirement which ensures that the costs for security remain at an acceptable level. If there is no confidence in this, then extreme measures (with the commensurate costs) will be taken.

There are a number of aspects about security which divide into two obvious options:

1. Granting access to the service;
2. Allowing execution of the service.

Granting access is a function that has to be solved by infrastructure. Part of this is the authentication of the service client and validation to make sure the service may be invoked. A purely technical affair that can be completed with WS-Security that prescribes standards within SOA in this domain. The security of the execution of services is not the responsibility of the infrastructure, but of the service (provider) himself. Of course the authentication information is used for this; however, the right to execute or skim information that is provided by a service is a business function. It might certainly be true that a service providing information varies between the users. One service may, for example, show information about the price to the user, while another service may not.

← previous

Introduction SOA for Organisations

next →