SOA deployments: What actually works

SOA may have seemed the savior of bad software architecture and poor development project planning, but the reality is that it's a complex and difficult venture. Thus, the number of failed SOA projects is about equal to the successful ones. In other words, you have a 50 percent chance of failing, and the odds of failure are even greater if you work within a larger Global 2000 organization or within the government.

But key patterns are emerging from the successful SOA efforts, patterns that can help you determine whether your SOA is a failure or a success.

The most important lesson from these patterns is that SOA is as much about old-school IT disciplines as it is about new, inventive technology. Moreover, it's about changing an organization from the people down to the technology, driving a systemic and valuable change. The patterns of success likewise follow that change from the people on down to the technology.

People: From leadership to staff, the right aptitude and commitment is critical

The fundamental cause of SOA failure is the lack of good people working the architecture, from leadership to staff. This lack is not of numbers, but of knowledge and the vision to drive change.

People-based SOA failure begins at the top. A recent Burton Group study determined that the arrival of a new CIO typically spelled success for SOA. In essence, innovative leadership and the ability to change the culture and then the architecture is a clear critical success factor.

Moreover, critical to SOA success is the presence of a leadership team that values an investment in infrastructure and understands the long-term value of being more agile and efficient, and, better yet, is willing to make the investment. SOA is not cheap. Indeed, it's a huge systemic change in how you build, deploy, design, test, and architect your information technology. It's an investment that goes well beyond the millions of dollars required to acquire the necessary training, consulting, and then the technology required to make the changes.

The SOA investment cannot be treated as a one-time "transformation" project. Instead, you need to consider SOA as a journey, not a project, and -- for the purposes of budgeting -- treat it as a series of projects that make up the journey. The SOA effort does need its value clearly defined, and the investment and commitment to achieve that value made up front.

Because SOA is really about a journey, not a project, enterprises need to take a long-term view of SOA. It's a multi-year and typically multi-million-dollar commitment to drive a systemic change to the core IT mechanism. But most SOA "projects" are stopped at some point, typically due to budget issues or to the need to redirect resources at some tactical short-term need. Thus, the SOA never had a chance; there was no follow-through. Executive and IT management must not allow this.

SOA also involves two fundamental business changes that IT historically doesn't have the clout to make happen: One is the sharing of processes across political fiefdoms that fear loss of control. The other is that SOA requires a rethinking of fundamental processes, which is not only hard but also challenges established practices, resource allocations, political power, and so on.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email ARN
• Follow ARN on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark