In-Depth
Avoiding Common SOA Pitfalls
Knowing common pitfalls of SOA governance teams and application teams is the first step to avoiding them.
Knowledge is power. If you’re considering an SOA initiative, it helps to know what’s ahead.
In their book, 100 SOA Questions Asked and Answered, authors Kerrie Holley and Dr. Ali Arsanjani tackle the basics of SOA and answer many of the business questions already on the minds of IT professionals (how should SOA be sold to business stakeholders, what ROI can be expected, and what criteria should be used for selecting a project for SOA adoption). The authors address governance, architecture, organization, and application issues as well.
As Holley notes, “This book is not about a technology change; it’s about a business journey with IT, where SOA is both the enabler and the catalyst.” We’ve selected two questions (and answers) that are particularly geared to helping you avoid the mistakes others have made on their SOA journey.
Question 37: What Are Common Pitfalls of SOA Governance?
“Trying to do too much too soon” is a common syndrome. “Ironfisted” or heavyweight governance is another common problem. In addition to these two common problems, the following are common pitfalls of SOA governance:
- SOA governance becomes solely about a focus on integration
- Lines of business resist SOA adoption and avoid sharing services
- SOA efforts become “shelf ware”
- Funding issues and SOA projects drag to a halt
- Failure to achieve reuse or time to market savings
- Toothless governance
- SOA goals take a backseat to tactical project goals
- SOA governance is ineffective if poor IT governance prevails
- Selling SOA versus specific measurable strategic or tactical benefits of adopting SOA
SOA is more than the sum of the technologies that enable SOA. SOA governance recognizes the synergistic and overlaps between technology, people and processes to achieve strategic SOA goals. SOA governance should have a scope focused on achieving one or more measurable strategic or tactical goals. SOA governance requires active support from senior executives with authority and influence. With large-scale projects, SOA is often a strategic goal with a larger focus on delivering a business solution with its own sets of challenges. Senior executives can ensure that the strategic goals are baked into the project scope. Architects can make sure these goals are measurable and achievable.
Defining value propositions for lines of business to use and share services and SOA assets is something that SOA governance and change management can positively influence. Management support and delegation of the SOA charge to key respected leaders coupled with grassroots building of consensus of the method to gradually deploy governance is essential.
Establishing an SOA funding model for both short- and longterm initiatives is another critical success factor for SOA governance. There must be some commitment to funding dedicated resources necessary for SOA stewardship (e.g., SOA CoE and SOA governance activities) and the procurement of supporting SOA tools (e.g., design time and runtime) and technologies. Funding for SOA projects must be crafted in a manner that advantages and incents lines of business. Establishing incentives that reward lines of business for serving enterprise goals is an example. Governance bootstrapping that starts with a lightweight approach to governance consisting of an architecture review board consisting of key respected leaders from both the business and technical sides is a prudent and effective way to get started.
Question 60. What Are Common Pitfalls for Application Teams Adopting SOA?
The most common pitfalls that application managers and application teams involved in SOA adoption see are related to not recognizing or not planning for the following:
- SOA is a paradigm shift
- SOA is a journey
- SOA benefits accrue only with improved collaboration between business and IT
SOA is a paradigm shift. The implication is that the advantages of SOA, in areas of agility, reuse, accelerated development, lower cost, and variability, will not be realized if the same application development practices are adopted. If application teams build the same way as before, it’s likely and probable that the end results will have the same quality. Adoption of the SOA-based methods, SOA reference architecture, SOA governance, and rescaling or augmenting the skills of different roles within the organization are gradual changes that should be understood and accommodated. Applications should no longer be built as silos. Application architectures tend to originate in a specific line of business within the context of a specific project, and this will gradually change. Focusing exclusively on the sole concerns of just one line of business often leads to the phenomenon of developing silo application architectures and applications themselves.
Prepare for the SOA journey; it’s going to take more than a day. The adoption of new disciplines, practices, and technologies helps bridge IT and business; and it requires planning and continuous monitoring to achieve the maximum results. Organizations with a clear SOA strategy or SOA vision that articulates the goals, current issues, business scenarios, architecture vision for the future, metrics, and roadmap will see much greater success than organizations that treat each of these activities ad hoc. Adopting a clear set of metrics upfront requires business goals and a vision, to demonstrate that you have actually achieved the goals and objectives of your journey. A journey needs a destination (in this case, an objective), and if you cannot measure that objective, it’s not likely organizations will know whether the objective has been achieved. In turn, this makes sustaining the journey difficult and challenging as funding and resources dwindle if the business cannot see or measure the business value return. Change agents, organization and cultural change, cannot be underestimated, because this is both an ongoing and required activity throughout the journey.
Collaboration between business and IT must often adjust to the new paradigm. Most companies that have spent years adopting SOA are still on a journey to improve the dialog between business and IT development. Very few organizations have metrics to legitimize the SOA claims and manage business expectations. Business and IT must have a collaborative and solid working relationship of shared responsibility for SOA to meet its promises. Technology-only efforts are ultimately doomed to failure if success is measured as making the promises of SOA come to fruition. This is especially true if an organization’s funding comes from the business side. Therefore, for the business to gain the maximum benefit, or in fact any short-term benefit, the business should invest in IT’s capability to meet changing requirements and implement those changes in a time-sensitive fashion that is not cost prohibitive and does not produce large ripple effects not only on the technology side but with the business consequences.
- - -
Excerpted from 100 SOA Questions Asked and Answered by Kerrie Holley and Dr. Ali Arsanjani; Copyright 2011 Pearson Education; reprinted by permission.