"He who rides a tiger can never get off or the tiger will devour him."

Software developers know the truth of this Chinese proverb. We ourselves have created an environment that forces us to cope with ever-increasing complexity. Twenty-five years as a software developer, manager and architect has taught me that every day has something to teach me. Here's what I'm learning now in the hope that it helps someone somewhere stay in the saddle and off the menu.

Monday, January 25, 2010

SOA Success Factors in a Nutshell

Based on my experience and research, here is a summary of observations and best practices for successful Service Oriented Architectures.

Service-oriented Architecture (SOA) is a well established architectural pattern by which organizations can design and implement an agile architecture that supports a rapid pace of change in business needs. SOA can also provide a means to reuse, extend and re-engineer existing applications by extracting their core logic into a set of services that can then be reassembled into new solutions.

SOA is in use in a growing number of organizations worldwide. IDC, a leading IT research company, expects spending on SOA software to reach almost $15 billion by 2009. Because SOA is used so widely, best practices for success have emerged from the practical experience of thousands of implementations. The most important of these are summarized here.

Keep your eyes on the prize.

The whole point of SOA is business agility. SOA enables this, but can deliver it only if the goal of reuse permeates the analysis, design and implementation.

Feel their pain.

A truly competitive business wants to reduce the latency of its response to changes in its marketplace. To enable this, one goal of SOA must be to remove technology as the limiting factor in the business' responsiveness.

Show them the money.

SOA has two core value propositions:
  1. Software is cheaper to build if you have the parts in stock
  2. Adapt to change faster than the competition and thrive
The ROI of SOA is the product of the improvement in a business's ability to adapt to change as multiplied by the frequency of change and its value to the organization. Some industries, such as the financial services industry, traditionally have high levels of both frequency and value of change.

Know the problem.

The problems that SOA addresses are complex. Finding a path through them requires a clear understanding of the business and its needs. To find the way through, the SOA architect must:

Understand the business objectives and define success
To be considered a success, the SOA must contribute to the business's bottom line. The technology organization must clearly articulate the objectives and define what constitutes success.

Define the problem domain
As with distributed systems, it is tempting to view an SOA as the answer to all the organization's problems. Unfortunately, overreaching plans to build a New Jerusalem in software are doomed to disappoint.
The best pattern for success is to take small steps guided by a larger roadmap. The overall strategic plan should be advanced in a prioritized series of tactical projects. Small successes build competence and confidence toward larger victories.

Understand the application
SOA planners must:
  • Understand the semantics (data definitions and relationships) of the application.
  • Define and list the business processes and services in the domain.
  • Define the interaction mechanisms between the processes and services -- including existing services and non-automated processes.

Choose tools wisely
Once enough is known about the requirements -- and only then -- the technologies to implement the solution can be chosen. A realistic proof-of-concept and a useful pilot project are crucial steps to selecting technologies that will actually do the job.

Remember the people

Business agility is as much about the organization as the technology. A successful SOA will depend on the knowledge and input of both the people who build it and the people who will use it.

Run to finish the race

Make no mistake. An SOA is a long-term proposition. The number and value of services must reach a critical mass before the business realizes any appreciable ROI.

Organizational committment to SOA must come from the top to overcome organizational inertia and be sustained through shifting project priorities and investment capacity. Approaching an SOA as a quick-fix project is a well-trodden road to ruin. Failure here is worse than just a waste of opportunity and resources -- it generally leaves behind yet another layer of complexity atop an enterprise's infrastructure.

No comments:

Post a Comment