Service Oriented Architecture (SOA) implementations are complicated processes. Accordingly, creating an architecture style for designing and managing business services is a multifaceted procedure. To best manage this complicated situation, Info-Tech Research Group identified a “bakers dozen” of common pitfalls. Meet the challenges in the initial project stages, to capitalize on the approach’s key opportunities.
This is the concluding note of a two note series. For the first seven tips, refer to the McLean Report research note, “A Baker’s Dozen of SOA Pitfalls.”
The Final Six of the “Baker’s Dozen” of SOA Pitfalls
8. Assuming tools get the job done.
The nuts and bolts of SOA include a variety of enabling technologies, such as enterprise service bus (ESB), repositories and modeling tools. These technologies act as SOA enablers. However, relying simply on the technology is not efficient in the case of SOA. The technology cannot identify a service from a business process, cannot work through the best business design for a service and lacks the intuitive nature to notify the developer of a well-designed service and assess its flexibility, etc. With this limitation in mind:
- Don’t forget that defining services requires an understanding of business processes and functions.
- Don’t forget the importance of the people and process when it comes to architecting a SOA service.
- Validate and support the role of the technology tools, coupled with people, which proves for a successful SOA initiative.
9. Believing that SOA always means “build everything from scratch.”
A common assumption with the SOA strategy is that all services have to be designed and built in-house. While historically this was the case, the landscape is changing. Increasingly, enterprise application vendors offer software that is divided into services. Conversely, if the core software is still offered in packages, a growing number of services for smaller-related functions are available, for functions surrounding the package. As a result, while some organizations opt for a complete in-house solution, it is not the only option. And so:
- Be sure to investigate services offerings to see what is available for the specific design.
- Evaluate the viability of the existing design, before deciding to purchase or build the solution in-house.
10. Underestimating the work to monitor and measure services.
Often, the current infrastructure and current support processes are not well equipped to support SOA. Service level agreements (SLAs) measure the ongoing operation of an application and define things such as help desk response time, escalation procedures etc. Internal SLAs between IT teams often support these business SLAs through defining how teams work together to provide the support. As SOA progresses in an organization, applications become collections of services. Each service could be used by many other applications and potentially be supported by different support teams. Current infrastructure that monitors applications may be able to signal an issue but often has not been designed to monitor and measure down to the service level. Diagnosing problems and assigning the right resources increases in complexity. To increase effectiveness and minimize frustrations:
- Be proactive. Ensure that project testing includes the necessary performance and load testing required.
- Ensure support teams have the application design and support information they need to diagnose applications issues once in production. Some additional information that outlines the service composition within the application is likely to be required.
- As SOA moves from something done by a few projects to an architectural and development approach, consider infrastructure tools that do support monitoring and measurement at a service level as well as an application level.
11. No service repository.
A service repository is a valuable tool to drill down and identify implemented and in-progress services. Accordingly, it is useful for project teams to examine and reflect upon the service model. Information stored within the repository can be further analyzed and can help avoid service duplication. At the onset of a SOA approach, a small number of teams might be building services, and then an additional small number looking to reuse or enhance those services. Due to the economies of scale, a full-fledged services repository is probably overkill. However,
- A service repository of some sort should exist, to keep track of the various projects. Services must be easily located and understood in order to reuse them. Without seeing and understanding them, service duplication and service spaghetti will result.
- As a starting move, consider setting up a spreadsheet, and storing it in a central location, to keep track of the projects. Remember that the spreadsheet is simply a starting point, to help get into the practice of maintaining records. Aside from being a band-aid solution, it also has limits as to what information can be stored.
- A services repository is the more effective long-term solution. However, getting some SOA wins before spending the money on a formal repository is often a wise solution.
12. Don’t forget about SOA Governance.
SOA governance provides policies, procedures, and escalation mechanisms that mitigate risks associated with SOA. SOA governance covers what needs to be done, including answering questions such as: who, what, where, when, why and how. The notion of setting up an “SOA governance model” can also seem intimidating at first. For an effective model, and to avoid analysis paralysis, consider:
- SOA governance is a plan, an outline, a framework. It doesn’t have to be intensive to start. For an effective framework, refer to the McLean report research note, “SOA Governance: Avoid Service Spaghetti.”
- Beware of the assumption that all answers should and can be known up front, as opposed to uncovering them as SOA experience unfolds.
13. Getting lost in the hype.
The final, and perhaps the most common, SOA pitfall is assuming that SOA is the next silver bullet. It is not a product ready for purchase, but rather it is architecture, a process, and a design paradigm. While components and enabling tools can be purchased, SOA requires attention to people, process, technology and governance to have any hope of success. SOA holds great promise but achieving the promise requires work and commitment to render it valuable.
- Assess the organization’s readiness by looking at the full list of pitfalls and determining the current state of people skills, development process maturity, technology capability and political readiness for the governance involved.
Bottom Line
Suffering major headaches is common when beginning a Service Oriented Architecture (SOA) initiative. Be prepared for the onslaught by understanding the “bakers dozen” of common pitfalls to help best manage the design process.
