SOA for an Organisation

From Geostandards

An SOA, and the services that are used within an organisation, do not have a different lifecycle from the more traditional applications which are used by organisations. There are, however, a number of differences that make service orientation different and that need special attention which is not, or is barely, important in a traditional environment. This is explained below.

Developing

When developing a function within an application, the users are known. But in an SOA where services are being developed, the users are not always known. A service will initially always be built with the user in mind, but to optimize the benefits of a service, it is necessary to develop the service for a larger group of users. Or a service has to be developed with the intention of re-using it. For the development of a service, this means that standardised information models have to be used that are supported by a large group of users.

In the geographic world information models like these are available as application schemas. It is recommended that both the input and the result of a service (function and information request) are completed using these standard information models. If a service, for example, provides a spatial planning plan, then it is wise to apply the standardised spatial planning plan.

A service might provide information from the core system of a provider. If the number of service clients becomes too large, the result may be that the core system does not react anymore and the provider can no longer execute a core process. A lot of these scenarios containing risks for provider and client are possible and can be solved actively, proactively and passively.

• Active makes sure that the application provided by the service can be graded and that there is no burden. This could be regarded as an insurance premium that may never need to pay out.

• The pro-active method works by actively monitoring the service requests to restrict the number which are admitted and their use, or if there is a limitation value set that is crossed, by upgrading the application (and thus the service as well).

• The passive method is to wait for the problem to occur and then solve it. Because a service crosses the borders of an organisation’s application to the limits of the Internet, the need for 7/ 24 availability is important.

An SOA requirement of the service client is that he should endeavour to have minimal to zero independence of the services used. Possible modifications to a service should be absorbed as much as possible without any adaptations being made to the code. This way new information elements that are added to the result, should not lead to any malfunctioning of the service for the client.

Governance

From a developer’s point of view, the client should not be ‘bothered’ by any modifications which are made to the service. From a provider’s point of view, the user should always be informed about a modification made to a service definition. This definition should be regarded as a binding contract. Since the provider of the SOA service does not necessarily know all the clients, this area should be given special attention. A role that is needed here is one of sector co-ordinator who can take a central role and bring service applicants and providers together. This supervisor can perform analyses of the affects that users of the service come across when service modifications are made. These parties can then be pro-actively informed about them.

The principle ‘a contract is a contract and the services will never be modified` is valid within the SOA context. However, in practise it is impossible to give a service an infinite life. It is customary – when a service is extended – to offer it as a ‘new’ service, alongside the one already in existence and to give users the option of making a transition to this service. By defining the number of ‘maintained’ versions or the lifetime of a version, after it has been replaced by a new one, an infinite lifetime or a proliferation of versions can be avoided. The issue about the management of versions is not only important for the actual service, but also for the service register where the service descriptions are recorded and managed. It is very important that versions of service definitions are stored ‘infinitely’ so that modifications can be traced back through the years.

The managers role – one that does not exist in a normal application context – is to stimulate re-use. It is the task of the management organisation to actively promote SOA and to stimulate the re-use of available services. Also, when there are new requests for new services, the management organisation will have to participate actively when defining a service that is applicable in a large context. A sector co-ordinator could take the role of ‘vendor’ of the service and he or she could offer a platform from a service desk point of view in order to bring providers and applicants together.

Registrations and ‘data close to resource’ principle

In each organisation, a lot of registrations and administration systems that are important to a number of (internal) clients can be identified for internal purposes. Registration can be described as: "The process to clearly identify the relevant object which is being managed based upon a fixed procedure which, in turn, is mostly based on, or results from a unique identification characteristic or document".

A direct derivative of the registration is the sustainable recording of the registered information and/or the way in which the settlement procedure is run in an organisation. Nearly all organisations use automation tools for their registration and administration, such as applications and databases.

Examples of registration functions and administrations that all organisations have are:

• The administration of employees
• References to building and/or rooms
• Cost centre
• Debtor numbers
• Project numbers

When setting up these types of registrations, it is important to use ‘data close to the resource’ which guarantees both efficiency and data integrity.

Both inside and outside the organisations, various clients of those informed can be recognised and from the point of view of costs and data integrity it is efficient to centralise these functions as much as possible. A special person, or a specific part of the organisation will be responsible for how the collection process of the data goes and the correctness of the data, but this will also depend on content, need and size. Specific organisational or technical measurements can also be used to separate applicable function (external) quality checks by a supervisor or auditor.

The text above is particularly applicable to organisations focussing on the public, as registrations are especially important in that field because of:

• The monopolistic, and therefore unique, position of the public organisations for a specific working area;
• The wide group of clients or high volume of purchasing.

An example of a public register is the register of residence for a specific (political) administrative unit which is made tangible for the consumer in the form of documents such as a birth certificate, proof of life certificate or passport. Other public registers include the ones for the registration plates of vehicles and for aeroplanes. For consumers, these types of registration become mostly visible via an 'approval procedure' which might consist of a publication and disclosure stage and an objection procedure; all culminating in the provision of a document such as a registration certificate, a residence permit, a marriage license or an occupancy permit. This cohesive system of registrations, both basis registrations and core registrations, is one of the fundamental components of a national system of provisions such as the Geo-Information Infrastructure (GII).

← previous

SOA for an Organisation

next →