However, most of the organizations we've worked with are taking a project-driven approach to SOA - namely, addressing tactical integration and composite application requirements with SOA tools. So where does this leave them? Fortunately, companies don't necessarily have to do SOA for the same reasons, or do enterprise SOA. Each of us can do SOA in our own way and still benefit from it.

How?

You need to answer two key questions:

1. Why are you doing SOA? This question isn't limited to those who haven't dipped their toe into the SOA pond.
2. How are you going to do SOA? How are you going to make sure you don't do it willy-nilly?

This article reflects our experiences - synthesized from working with CIOs, IT managers, and architects - of the ways SOA practitioners are addressing these issues.

Why Are You Doing SOA?
When architects and developers talk about SOA, they discuss Web Services-enabling applications; interoperability through standards; reducing integration pain; and the ease of use of new-generation SOA tools and platforms, compared to using the legacy integration brokers. On the other hand, business people often think their investments in SOA are delivering agility, reduced IT costs, and reduced business risk - if IT people have articulated this clearly to them. If not, they see SOA as the panacea for the long change cycles and lack of responsiveness of IT. As IT people, how do we ensure that we can deliver on the objectives of the business and ensure that expectations are adequately managed? Or, how do the aforementioned magical SOA benefits actually manifest themselves? Surely not just from buying the right tools, however important that is.

Let's look at SOA benefits from a business perspective and see how IT helps make them a reality:

• Agility comes from a flexible IT infrastructure that enables you to build new capabilities quickly, compose new solutions from services, and align and change existing systems in response to changing business requirements.
• Reduced IT cost results in the ease and speed of development, interoperability, and reuse and optimized use of existing resources.
• Reduced business risk comes from increased visibility into systems, applications, processes, and data and the ability to enforce security policies.

These SOA benefits are shown in Figure 1. These business benefits can be mapped to supporting IT benefits, which, in turn, are enabled by what we term SOA enablers. Each of these enablers is realized through tasks, activities, or technologies. Figure 2 is the overall picture of the IT benefits, SOA enablers and supporting tasks, activities, and technologies.

You are doing integration between your customer relationship management (CRM) and your financials application with an SOA platform, and your aim is to enable greater business agility, which depends very heavily on how flexible its IT is. IT flexibility, in turn, is determined by the extensibility of existing applications and systems - how easily they can be extended to incorporate new business requirements.

Extensibility in applications isn't enough because tightly coupling applications can have a ripple effect of changes and is, in most cases, very costly and time-consuming to manage. So, managing the impact of change becomes a key enabler of IT flexibility. Designing the right level of abstraction and an appropriate service-layering architecture can help reduce the cascading effect of change. Loosely coupled, and even completely decoupled, applications help reduce the impact of change. An important factor in determining how changes are handled is the appropriate use of tools and technologies. Especially in an SOA environment with a wide set of tools and infrastructures that may provide overlapping functionality, it's important to understand clearly the design patterns for which each tool is most suitable.