Service Oriented Architecture (SOA) is a computing architectural style for creating and managing services that represent business function and processes. Due to its complexity, when it comes time to plan for a SOA initiative, the task can seem overwhelming. Info-Tech Research Group has identified a "baker's dozen of common pitfalls. Realize the key opportunities of the deployment by anticipating, and meeting the challenges in the planning stage, before the team gets caught in the weeds.

This is the first research note in a two part series and covers the first seven pitfalls.

Seven of the "Baker's Dozen SOA Pitfalls


1. Beware of political battles over service definition and ownership.

Services must be defined and owned. Defining a service that lives within a business unit is usually not problematic politically. The reality though is that every organization will have services (involving internal or external clients, suppliers, products or services) which span multiple business units. The political battles over who in the business gets final say on the data, process and rules associated with a cross-business service can derail projects. To minimize potential political battles, the overall SOA initiative:

" Must define a governing mechanism for designating ownership and collaborating on service definition and scope.

" Must develop a mechanism for deciding on how a cross-business function gets funded initially and how changes to the service are funded on an ongoing basis.


2. Lack of modeling skills.

The "A in SOA stands for architecture. Services need to architected/designed to ensure reuse, flexibility and agility. Strong modeling skills are scarce in many organizations and even those with the skills face challenges. Be sure to determine the existing skill sets and be prepared to augment with external support and/or train existing staff. Some considerations:

" Since a service supports a business process, good process modeling skills are necessary. Note that those with strong process modeling skills may not have strong data modeling skills.

" Since a service provides access to data, good data modeling skills are required. Note that those with strong data modeling skills may be unfamiliar with packaging data and process into the generalizations and abstractions that form their model.

" Since a service embraces both data and function, good object-oriented (OO) modeling skills are an asset. Note that good OO modelers may have a tendency to model at too granular a level for an effective SOA.


3. Not recognizing the big picture of the SOA service.

Generally, projects are designed to meet a specific purpose of a business unit. However, a key benefit of SOA is being able to create reusable services: services that can be combined with others to create unique solutions over time. The modeling has to be sufficient to design the service to both meet the needs of the specific identified project and also meet as yet undeclared needs. Consider:

" Identifying the key stakeholders to the service that may have been missed when defining the stakeholders for the specific project.

" Taking just enough time to pin-point and model the immediate needs of the key stakeholders.

" Focusing on a design that meets current needs but does not preclude adding to and evolving the service in future projects.


4. Granularity of services.

While a big picture view of the SOA possibilities is necessary for long term success, SOA's ability to get granular on services is a key benefit of the architecture. However, there is a catch-22: services that are too tightly scoped, or too granular, complicate the composition of application solutions. This complication can negatively impact performance. Conversely, services that have a large scope (and possibly, "too big of a scope,) can limit its reusability, and therefore its performance. Understand the demands and the size of the services to determine the best course of action:

" In some cases, a large service might be most appropriate - one that can wrap a legacy system for use by a Web or client front end.

" If the legacy system has data, function and rules that might be widely reusable, a more appropriate approach might be to create several additional granular services, which would highlight the reusable aspects of the legacy system. It would bring the services to the surface, enabling multiple new solutions.

" In creating services, versus wrapping a legacy system, the level of granularity is a delicate balancing act of current needs, future reusability and performance realities.


5. An imbalance between conceptual/logical design and physical design.

An effective SOA design requires a balance between a conceptual or logical view and a physical, often deemed, realistic view. In an ideal situation, the two would match-up in perfect symmetry. However, in reality, design constraints (available technology, performance concerns, etc.) often impair the balance between the two. When one overtakes the other, issues arise, causing extra costs in addressing and repairing problems. To combat:

" The logical design must be the basis for the physical, with the physical design only altered when and where it must be.

" Without that conceptual basis, the key benefit of the services, that being their flexibility to be reused and reassembled, is negated and therefore lost.


6. Poor performance issues and lack of testing.

The complexity of an application that composes services to create a solution must be factored into the development process. By its very nature, the multiple pieces and moving parts must be frequently examined and tested. Services that have been tested for performance are now being combined with other services potentially in combinations that were never imagined previously. The combination must be tested.

" Build performance and stress testing into project plans as early as it is feasible. Do not leave these tasks to the end where performance tuning of the collection will be costly and time consuming.

" Tune the application on an ongoing basis. Make this part of the development cycle.


7. Lack of skills to maintain services and composite application in the Application Maintenance Group.

A common SOA management tendency is to focus on the initial development, involving the development teams. Services and composite applications require ongoing maintenance and enhancement processes. The maintenance group is often separate from the development group. As such:

" The maintenance group must understand the logic and reasoning behind the design of any service or composite application. This understanding will serve them well as they push forward with maintenance of services and of composite applications.

" Involve the maintenance group at the development stage, to ensure they too have the required skills to understand and follow the development process.

" Be prepared to evaluate the structure of the maintenance group. Cross-business unit services may require separate maintenance teams that work collaboratively with the application maintainers.


Bottom Line

Getting caught unprepared and landing in some major snares is relatively common when beginning a SOA approach. Understand the "baker's dozen of common pitfalls before undertaking the migration.