So, you have just started implementing SOA within your company – where do you begin? Often at client implementations, SOA Suite was brought in to help with a given project, and as such there may already be composites and code out there in support of that project. Alternatively, your company may have decided to implement SOA due to the many advantages it can bring to the business and IT. In either case, you now have a SOA implementation, and want to be able to leverage its capabilities and implement best practices across the enterprise. One way to do that is to implement and use common services. In this multipart series, you will discover the advantages to using common services, how to implement common services, and some patterns that you can use within your company.

Thinking about common services in a silo

Within IT there is a strong tendency to silo off information. Past attempts to move to a shared model only tend to create new silos. This repeating scenario happens at companies large and small. One way to help break the cycle is by using common services. Although common services cannot prevent the creation of silos within a company, they can reduce the incentive for them to form.

Some of the reasons these silos get built are as follows:

• The new system doesn’t communicate with other systems.
• The team that manages the other system is busy, so we will reimplement it.
• We don’t have the time to integrate, it will have to be later.
• IT moves slowly, so an outside group is brought in.
• The business bought a packaged solution
• SaaS offering is introduced.

In any of these scenarios, the probable outcome is data that could be shared won’t be, and services will be reimplimented over and over. By investing in the development of a rich set of common services, IT can be not only more responsive to the needs of the business, but also to internal needs.

Types of common services

Broadly, there are two main types of common services. Those that interact with business data, and those that support the services that interact with business data. In the first category (services that interact with business data) there could be a common service that would allow different departments to interact with a logistics system. These services could allow other IT systems to get shipping costs, set up a delivery, and manage tracking. Without a common service, each application would have to implement their own way of accessing these services. Additionally, each department would probably be using their own shipping provider. With a common service, all departments gain the benefit of any company negotiation with the shipping company, as well as the freedom to change providers without changing the applications. Only the common service needs to be changed.

The second type of common services are foundation level services. These are common processes that are used within the IT environment in support of the business common services, as well as other systems. Logging, error handling, notifications, email, etc, are all core foundation services. E-Mail is an example of a shared service that is used within almost all organizations. Not all programs/projects have their own email servers. In the same way, foundation level SOA services can be created that enable developers to leverage common functionality to accelerate development time, reduce maintenance times, and generally improve productivity. These are the types of services that the rest of this series will cover.

What’s coming up?

This article is first in a series on common services within the enterprise.  Some future topics we will cover include how to identify services to be made common services, how to architect services, service enablement, tooling, and making the business case for common services.   Please provide feedback, and leave any comments below.