The 9 Requirements for a Successful SOA Deployment
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 Ive outlined here are the nine essential elements of a successful SOA deployment:
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 careone that has a high chance of success and will help create the momentum and visibility for the SOA journey.
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 dont 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.
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.
A cohesive security policy and approach has to be thought through from the onset. Many enterprises have existing security repositories they want to leverage in a SOA environment. On the other hand, many of the products that are typically deployed in a SOA environment come with their own security enablement.
A holistic SOA security approach will answer questions like:
- What will be the approach for authentication?
- What kinds of security standards will be leveraged?
- How will existing security assets get integrated?
- What approach will be taken for message-level security?
- How will fine grain authorization get implemented keeping a shared application environment in mind?
Application performance is usually calibrated by the needs of its distinct user community. However, when a service is being implemented its future usage scenarios may not be visible. Needless to say that services performance becomes a very important factor in ensuring it is used across a wider set of applications. Each service needs to meet the most stringent performance requirement across applications.
Success for an SOA initiative needs to be measured and tied to broader business goals. Questions like the following need to be answered before any level of success can be claimed:
- How much reuse actually happened due to SOA?
- Was there a reduction in time to market for certain business priorities?
- How reliable was the overall SOA environment?
- Were the SLAs that were defined for the services properly met?
- Have the performance and scalability requirements been met?
Some of these questions may be answered via spreadsheets, but many will require the proper deployment of tools and processes to provide reliable answers. The success of the SOA journey should be quantifiable via metrics rather than left to perceptions formed due to incomplete information.
While some of the above guidelines may be applicable for any software development lifecycle, an SOA environment imposes a new outlook given the reuse and agility guideline requirements.
Kamran Ozair is the CTO at MindTree Consulting.