Today most of the conversations surrounding service-oriented architectures (SOAs) focus on flexibility and breaking down applications into services: modular, reusable, componentized, with increased availability to the services as well as increased management of them. However, with these conversations comes the risk of getting sucked into a technology-centric vacuum in which consideration for the real business problems that customers need to solve might be neglected.

Undoubtedly there is a huge demand for the development and implementation of SOAs. Gartner predicts that by 2008 more than 60 percent of organizations will use SOA as a "guiding principal" when creating essential applications and processes. With this in mind, and as the spotlight on SOA grows ever brighter throughout the industry, companies in all sectors are posing the question, "What are the key things we need for successful SOAs?"

Before embarking on building an SOA, business and IT executives need to sit down and determine what business problems need to be solved. These are clearly going to vary by industry. For example, Telco and wireless service providers worry about customer turnover. Pharmaceuticals stay up at night trying to get new, life-saving drugs to market faster. Hospitals want to ensure that up-to-date patient records are available to doctors when needed during emergencies.

Solving real business problems using the flexibility afforded by an SOA is critical to helping customers transform to on-demand businesses that can quickly respond to rapidly changing market environments. An SOA can help companies do this by providing an industry-standard framework that is interchangeable, adaptive, and flexible, but most important, is closely linked to the business goals.

Business leaders who are not aware of the benefits an SOA can provide will likely lose a competitive edge in the marketplace as more nimble competitors take advantage of this new enabling technology. The business value that SOAs provide is so great that organizations are set to spend billions of dollars annually in just a couple of years on software and services to achieve these benefits.

Working through the steps of identifying a specific business problem, determining an approach to solve it, realizing ROI, and then moving on to the next business problem is a method that customers understand and prefer when purchasing technology and services. This approach is forcing the strategy to shift away from the practice of customers simply purchasing middleware, a database, management tools, or even general services from a single vendor, to customers demanding solutions based on IT components with the right combination of technology and services to solve specific business problems. Vendors that can't adapt to this new culture will have problems. They must improve themselves to sell large quantities of components and assets that fit into a defined ecosystem - based on industry standards - and scale these components to address additional business problems.

Customers need to approach building an SOA based on the needs of the business. A company, or more specifically an IT department, can't guess what new technology (such as Web services) will add the greatest value, so a detailed identification and prioritization of the services a business needs to develop or expose in order to support improved business processes must be developed. Once a business has determined its priorities and those priorities are understood and shared by the company's business and IT leaders, the next step is to agree upon a systematic approach that will help them build a roadmap for implementing an SOA. In order to migrate to an SOA that will generate the greatest results in the most efficient manner, there are certain questions that must be addressed. In a recent paper, Ali Arsanjani, PhD and IBM's chief architect for IBM's SOA and Web Services Center of Excellence, outlined the following points for best practices in migrating to SOA.

• Adoption and maturity models. Where is your company at in the relative scale of maturity in the adoption of SOA and Web services? Every different level of adoption has unique needs.
• Assessments. Have pilots been conducted? Have you dabbled into Web services? How good is the resulting architecture? Should you keep going in the same direction? Will this scale to an enterprise SOA? Have you considered everything you need to consider?
• Strategy and planning activities. How do you plan to migrate to an SOA? What are the steps, tools, methods, technologies, standards, and training needed? What is the roadmap and vision, and how do you get there? What's the plan?
• Governance. Should existing API or capability become a service? If not, which ones are eligible? Every service should be created with the intent to bring value to the business in some way. How is this process managed without obstructing business goals?
• Implementation of best practices. What are some tried and tested ways of implementing security, ensuring performance, complying with standards for interoperability, and designing for change?

Layer 1: Operational systems layer. This consists of existing custom-built applications, otherwise called legacy systems, including existing CRM and ERP packaged applications, and older object-oriented system implementations, as well as business intelligence applications. The composite layered architecture of an SOA can reuse existing systems and integrate them using service-oriented integration techniques.

Layer 2: Enterprise components layer. This is the layer of enterprise components that is responsible for realizing functionality and maintaining the quality of service of the exposed services. These special components are a managed, governed set of enterprise assets that are funded at the organization or the business unit level. As enterprise-scale assets, they are responsible for ensuring conformance to SLAs through the application of architectural best practices. This layer typically uses container-based technologies such as application servers to implement the components, workload management, high-availability, and load balancing.

Layer 3: Services layer. The services the business chooses to fund and expose reside in this layer. They can be discovered or they can be statically bound and then invoked, or possibly, choreographed into a composite service. This service exposure layer also provides for the mechanism to take enterprise scale components, business unit specific components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions. Thus, the enterprise components provide service realization at runtime using the functionality provided by their interfaces. The interfaces get exported out as service descriptions in this layer, where they are exposed for use. They can exist in isolation or as a composite service.

Level 4: Business process composition or choreography layer. Compositions and choreographies of services exposed in Layer 3 are defined in this layer. Services are bundled into a flow through orchestration or choreography, and thus act together as a single application. These applications support specific use cases and business processes. Here, visual flow composition tools can be used for the design of application flow.

Layer 5: Access or presentation layer. Although this layer is usually out of scope for discussions around an SOA, it is gradually becoming more relevant. I depict it here because there is an increasing convergence of standards, such as Web services, for Remote Portlets Version 2.0 and other technologies, that seek to use Web services at the application interface or presentation level. You can think of it as a future layer that you need to take into account for future solutions. It is also important to note that SOA decouples the user interface from the components, and that you ultimately need to provide a complete solution from an access channel to a service or composition of services.

Level 6: Integration (ESB). This layer enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, and is often described as the ESB. Web Services Description Language (WSDL) specifies a binding, which implies a location where the service is provided. On the other hand, an ESB provides a location-independent mechanism for integration.