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” of 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.
