Service-oriented architecture (SOA) is an architectural approach that should be looked upon as a journey within an enterprise. Different enterprises embark on the SOA journey with different aims. However, general goals include creating agility, enabling faster time to market and encouraging reuse within the enterprise. None of these are easy to achieve and require a set of guidelines that we will explore in this article.
Depending on which article you read or which analyst report you believe, the time for developing projects using SOA has arrived. Many enterprises are already in the pilot phases of SOA projects while others have actually moved implementations into production and have services that are being consumed across the enterprise.
Either way, what I’ve outlined here are the nine essential elements of a successful SOA deployment:
Careful Choices
Different enterprises embark on the SOA journey in different ways. Some take a holistic view of their business processes and define a service map, whereas others take a more incremental approach and define services as a by-product of the different applications they build. When an enterprise embarks on the SOA journey, there may be many non-believers among the business and IT landscape.
The initial sets of services also require extra cost and effort. Hence, it becomes extremely important that the first implementation involving SOA is chosen with care—one that has a high chance of success and will help create the momentum and visibility for the SOA journey.
Business Agility
One of the key mantras behind an SOA-based methodology is that it enables business agility. One of the key ingredients how such agility is achieved is by preparing a business architecture and enabling different business processes via service implementations. The tighter the alignment between the business architecture and service map, the easier it would be to keep the two in synch. It will also ensure there is a platform available to absorb the ever-changing business requirements and needs, enabling the wider goal of business agility.
More Than a Registry
Reuse is the Holy Grail for a SOA-enabled environment. Most software vendors will talk about their registry products and how one can achieve reuse by ensuring all the services are visible to the enterprise via a registry. That may be a good practice but it is not sufficient. In order to achieve reuse, each service will have to be designed, implemented, tested and deployed in a manner that takes a wider view of the requirements than the particular project(s) it may be initially implemented for. There also have to be mechanisms for incorporating newer requirements into services and, at the same time, maintaining backward compatibility.
Developers are People Too
Many developers like to build things from scratch and sometimes they don’t trust things developed by others. In addition, many feel that it is easier to build something from the ground up rather than spend time to understand an existing service and its usage scenarios.
There has to be a “carrot and stick” approach in order for developers to line up behind an organizational commitment towards SOA and reuse. There needs to be some explicit incentive for teams in order for them to reuse existing services. The initial developers of a service as well as initial teams that try to reuse them will go through some pain. They need to be aptly compensated for their extra effort. Similarly, any team that shies away from using an existing service should have a lot of explaining to do.
Governance
Whether it is defining the design principles behind services, a security strategy for services, reuse incentives or a clear ownership structure for services, governance has to be thought through from the initial implementation of services within the enterprise.
A governance model for SOA should define guidelines at the architecture level, initiative level and operational level. It encompasses best practices and policies, review mechanisms, tools and methodologies as well as the organizational structures need to enforce the different mechanisms.
Managing a Shared Infrastructure
As part of implementing multiple applications in a SOA paradigm, co-deployment of applications on a shared infrastructure is a common theme. The applications tend to use a common set of services and are most likely will be built on the same architecture. Application boundaries also become blurred in SOA because one project uses services provided by another.
In such an environment, it is imperative that strong controls and policies are in place. Aspects like deployment of new services, configuration management, versioning, maintenance and upkeep, batch and update cycles have to be thought through with a shared environment in mind. Infrastructure and policies have to be designed so they are able to satisfy the most stringent requirements across the different applications.