Service Oriented Architectures (SOA)

The software service is a concept that has gained great momentum over the last five years. The main reason for this sudden interest is due to the emergence of the Web Services (WS), that have been more or less unanimously promoted by all the major actors of the IT market. Web Services use the standard SOAP, WSDL and UDDI protocols for interconnecting, generally over the Internet, various applications that may have been developed in different environments.

Whereas the WS standards are exclusively about technology problems, the SOA or Service Oriented Architecture approach has a much broader scope and is typically concerned by the business aspects. During the last fifty years the vast majority of the IT programs were developed to automate certain functions of specific departments within the company. Nowadays the applications are designed in order to be inline with the “business value chain”; they will cross the boundaries of multiple departments inside the organisation or even interface with the customers, providers, banks and government agencies. For this reason the software development must open up to change and integration.

The SOA approach considers this complex problem very globally. A classical metaphor is to compare SOA to an urbanisation plan, that is compulsory for all new houses that are under construction, in other words all the applications that are being developed. But another fact to consider, that is even more important and far more complex, is that over time this urbanisation plan should integrate all the existing houses and old cottages that already exist, while minimising possible damage as much as possible.

There are many good reasons for organising IT according to the SOA paradigm. Hereafter we are going to describe those that were defined as essential by a large bank, that can be considered as having done  pioneering work in reorganising the internal application portfolio of the bank with a permanent service orientation in mind.

• It is crucial to efficiently handle the ever increasing complexity of IT. The number of programs is permanently growing; furthermore these programs must be consistently integrated and they must be open to change over the time to cope for evolutions in regulatory requirements, competition, company strategy or mergers. All these modifications must be possible without propagating through the complete application chain. The service oriented approach is particularly suited for handling these diverse requirements, that are both complex and contradictory.
• SOA is completely compatible with the so-called “agile development methodologies” which nowadays are often considered as the only efficient way to handle complex IT projects.
• Adopting a Service Oriented Approach allows for maximising the reuse of these services and for eliminating redundancies in business rules and data, a prerequisite for reducing integration and maintenance expenses.
• SOA represents a rational and cost effective alternative for replacing the Enterprise Application Integration (EAI) methodologies, offering a consistent overall scheme, rather than a variety of specific interfaces.
• Finally the existing legacy applications are an integral part of an SOA approach. Even if these applications are often old and partially outdated, they nevertheless contain vital rules for the company. Restructuring and integrating the existing development is a key aspect of SOA, subtly renamed to “Save Our Assets” by the CBDi Forum.

Obviously a Service Oriented Approach is complex and needs a serious organisation, even if there already exist a few large organisations that have achieved remarkable results. Fortunately the SOA scheme should not be considered as a revolution, but rather as an evolution, that can be progressively deployed, following the four steps described in the “SOA Maturity Matrix”.

• Early learning
• Integration
• Re-engineering
• Maturity

There exist a certain number of vital points to consider when trying to implement an SOA structure in the company; we are only going to mention a few :

• The business model and the organisation that is necessary for a service oriented approach
• The infrastructure defining the Enterprise Service Bus (ESB)
• The infrastructure for handling the services
• The security infrastructure
• The portfolio management for the services that are available in the company
• The services specifications
• The acquiring and adapting of services
  
• The assembly of applications from the service portfolio

All these aspects have to be seriously examined and implemented in order to achieve the major advantages of the SOA approach. At CompoSys we have a long experience in Component Based Development, and so we are particularly skilled to advise about the four last aspects, that are very close to the CBD approach. Concerning the selection and installation of the adequate infrastructure we prefer to work in collaboration with certain partners, who are among the few companies with a consistent and serious experience in this innovating domain.