"Adopting a services-oriented architecture should be undertaken as a gradual process, working toward your vision of a new IT enterprise which is more responsive to business drivers," says Tom Termini, author of The Zen of SOA.

Complex concepts have emerged over the past few years regarding the potential productivity an organization can achieve with their website, but few take the mystery out of it. In his new book, Tom Termini has describes how top management can look and move forward with clear goals, appropriate resources and confidence with SOA.

Organizations face quite different challenges in laying out a Service-Oriented Architecture (SOA) blueprint. Internal integration needs may be more straightforward, but business models may focus less on internal integration than external partners or customers. Traditional approaches like EAI, however, are notoriously inflexible and expensive, according to Termini.

In The Zen of SOA, Tom Termini shares his experience helping organizations leverage agile development practices and Web services to reduce the cost of older approaches to address their integration and new development needs. The simple addition of Web services interfaces, however, typically remains as inflexible as approaches previously available. Termini asserts that only through the application of SOA can C-level executives build and leverage loosely coupled Web services that are flexible enough to respond to ongoing change in the larger environment.

Termini sees the adoption of SOA as a continuum.

The following principles are among the many Termini recommends to successfully deploy an effective SOA:

1. Learn from others - study what worked for other organizations that may have had parallel processes, or similar objectives to yours. For example, at the Federal Trade Commission, we learned that commodity hardware and software promote the transition toward a fully-realized SOA. From the detritus of a failed EAI effort, the fruits of a SOA success can be found with the creative application of an "agile" approach.

2. Maintain a "baby-steps" approach toward a fully-realized SOA - expectations are more realistic, costs are spread over a longer period, risk is deferred, and you have the opportunity to foster organizational adoption. Cultural resistance is often the primary reason for failure in enterprise IT endeavors. If your adoption posture is incremental, you will lessen the impact on your organization, customers, and partners so they can assimilate change gradually.

3. SOA is more about the business customer than about IT innovation. Service-Oriented Architecture, when rolled out successfully, can empower the people driving the business processes in your organization, free up limited IT resources, and improve flexibility to meet change. While on task at the U.S. Department of Justice, we learned a portal is integral to Web-enabling the enterprise. Why? It provides the single, simple point-of-entry to the SOA-enabled systems for the less-technical business user. We found the portal was excellent at answering the question, where do I go to find what we already have? It also simplifies the human interface, since all Web applications share the look-and-feel or some derivative of the portal's cascading style sheet. Finally, the portal simplifies single-sign-on access - and ease of access means greater acceptance by the user community.

4. ESB does not equal SOA. Providing an enterprise services bus (ESB) to your organization does not mean you have a SOA. Gaining a full grasp of this concept is key to embracing the Zen of SOA. Think commodity software as well as hardware: one of the keys to SOA success. While we've found the messaging layer to be critical, often time success can be achieved by simplifying a few key business processes and SOA-enabling with a web service. Example: customer record lookup, because so many systems touch on that process.

5. Manage the SOA as part of the whole enterprise. Think of the SOA approach as a layer to simplify complexity - as above, consider the customer lookup process. What vital information needs to be presented to a consuming service? This layer does not stand apart from the organization's larger enterprise; rather, it supports the business architecture. The underlying services orchestrate and communicate business processes - these components are part of the technical architecture. Internal developers, external consumers and others will require access to reuse SOA services.

6. Measure progress and communicate results. The successful implementation of any SOA must be driven from the top down. This means gaining early wins that engage senior management. Define three or four metrics and regularly communicate results.

7. Promote SOA as the Future. Implementation of a SOA blueprint may never fully end, because business processes change or new ones are required. Your target architecture inevitably will evolve to accommodate changes in the external environment and corresponding adjustments to organizational goals.