Despite any declarations made to the contrary, service-oriented architecture (SOA) isn’t dead. In fact, the writer of the original SOA obituary, Anne Thomas Manes of the analyst firm
Many organizations are, however, struggling with services-oriented computing projects where budgets are out of control and positive results are siloed and often infrequent. The problem is that many of those same companies buy into the concept that SOA is a product instead of an architecture. SOA is simply a way of doing things—a comprehensive design pattern. Implemented properly, SOA provides a powerful set of services that can be leveraged within a business process to add efficiency and accuracy to repeatable functions. This article explores characteristics of SOA project failures and how they can be avoided.
Assuming that All Technology is Created Equal
Many organizations think that all programmers, engineers and technologies are created equal. In other words, many organizations believe that they can build without restrictions, but this is rarely the case. When initiating such projects, organizations must take an honest inventory of the resources available within their IT departments and the technologies in place, as well as existing process definitions. These resources must then be matched as closely as possible to the SOA project requirements. If the resources and requirements do not align, organizations must either set clear restrictions and scope boundaries on the project, or seek additional external resources. Many organizations fail at this early stage and watch their SOA projects balloon and spiral out of control, because internal resources are not equipped to match project demands.
Another important issue that needs to be addressed right from the start is that the traditional “waterfall IT” methodology does not normally fit the needs of SOA-related projects. Waterfall IT follows a strict series of processes that begin with the phase of developing requirement specifications and flows downward through the stages of design, coding or programming, integration, debugging, installation and maintenance. The waterfall IT model calls for strict completion of each phase prior to moving on to the next step in the development process.
The sheer size of many SOA developments and the number of stakeholders involved make it virtually impossible to use the waterfall IT methodology, because user requirements change and new realizations are made about the problem itself. Organizations must develop and leverage a clearly defined change management process throughout the implementation of both business process management and SOA that outlines how change requests will be evaluated, prioritized, reviewed, communicated and implemented. Organizations must use a team approach throughout the whole development lifecycle. All key stakeholders need to be involved and active in the discussions as well as have an understanding of the implementation. Thus, a more agile and iterative development methodology, one which integrates feedback and allows for overlap within the various stages, works much more effectively in real-world SOA implementations.
Not Putting Processes First
Organizations often embark on SOA projects and think that there is no process work required. Despite all advice to the contrary, many organizations still skip the step of accurately defining business processes—a major mistake. Smart organizations use BPM to capture the unknowns. IT must ensure that it has an accurate and clearly documented process specification (i.e., business requirements) that is understood, validated, signed and approved by the client or partner organization prior to beginning development and prototyping. As discussed earlier, systems should be designed in an open fashion in lieu of strict requirements, allowing stakeholders from the business side of the house to make ongoing decisions. Automation and rules engines should be brought in as the requirements and rules solidify.
A best practice when identifying processes is to start with a single, mission-critical and/or significant process that can show visible and quantifiable value. This is especially effective and relevant given the current economic climate. Closer scrutiny on spending from the executive level means that SOA projects are becoming more incremental. ROI is being measured at various stages, and projects are being driven forward by the level of business value or problem that is being solved. Also accept that there is no such thing as a perfect process. Organizations should avoid overengineering solutions to handle every permutation – that is where people are better than any technology.
Organizations must also avoid trying to use BPM to fill a vacuum of organizational and computing standards. BPM requires process to build against. Without true process, or a vague notion of them, BPM is ineffective. BPM cannot fix an undefined or unorganized process, and it is not the best fit in every situation. By comparison, the strength of Enterprise software is that it often implements a process where none existed; thereby giving an organization needed structure. BPM is most effective integrating technologies and people within a well-understood process. Organizations must design and implement BPM to match their business process needs, as opposed to trying to make their business processes match an off-the-shelf system.
Buying a SOA
By now, you’re probably starting to recognize some general themes. Clearly business stakeholder involvement, or ownership, on projects and some early strategic thinking of how the implementation will unfold can help head off many of the reasons that SOA projects ultimately fail. But, there is an even more fundamental reason that such projects fail. Many real-world SOA projects fail, or fail to materialize as expected, because organizations disregard SOA as a whole. It is typically regarded as a technical solution and not an organizational solution. Often, IT takes critical ownership of SOA projects, which causes a clear disconnect from the strategic goals of the business. The tendency is to be more focused on the technology than the underlying processes or business needs. This leads to organizations buying SOA as if it is some off-the-shelf solution. Organizations must implement SOA as it should be: as architecture, not a particular technology standard.
IT managers, working with business stakeholders, must first think about the “how” of designing such environments. Organizations must realize up front that analysis and discovery phases are at least 40% of the project effort, and if this does not appear to be the case, then they need to go back and start over. This is a significant issue with SOA projects that can lead to potential pitfalls and reduce the ROI benefits of the project. A simple solution is to try and secure upfront buy-in from an executive sponsor and a business champion with ownership, ensuring that the project is not wholly owned by IT.
Organizations often expect IT to set up and extract the business benefits of SOA in a vacuum, when they should be tackling the organizational aspects of SOA from a business perspective prior to service implementation.
With SOA, it is important that organizations take a strategic approach that enables them to get it right the first time. A successful SOA implementation methodology will preserve existing process value, is iterative and process oriented and allows organizations to get the most out of their people, processes and existing resources. Organizations must realize that doing Web services for Web services sake is unnecessary overhead. Does SOA make sense for your organization? Are there apparent business needs that can be solved by using SOA? Organizations must first answer those questions before their SOA projects begin down a slippery slope to ultimate failure.
Peter Woodhull is president and co-founder of
