There is still enough hype around service-oriented architecture (SOA) that it's difficult to get a handle on the realities of implementation. While most IT managers now understand what an SOA can do for IT, many still need help figuring out how to get started. New questions about management, reuse, and legacy applications are also emerging as more and more companies think about how to adopt SOA solutions.

The myths and mixed messages surrounding SOA hinder companies from starting on their path to SOA adoption, and in many cases actually prevent companies from realizing that some SOA principles may already be in place. Here are some of the questions that we have been addressing with our customers to help them move from thinking about SOAs to actually creating a plan.

What do I need to get started - services, software, hardware?
SOA is not a "rip and replace" strategy; rather, it is a way for enterprises to leverage existing investments, manage them better, and become more flexible and aligned with the real needs of the business. This journey is not facilitated simply by buying a new set of products or adopting new technologies. Realizing the value of SOA requires expertise and governance from the formal design process through implementation, provisioning, operation, and change - i.e., the entire life cycle. The vital starting point, therefore, is not technology, but rather identifying the business-specific services in an organization.

Due to the different focus - business-driven tops-down rather than technical bottoms-up - many customers require SOA expertise in the beginning of the process in order to map out a strategy that makes sense for the particular company and its goals. This is why so many large vendors like HP are offering services specific to SOA as a part of their offerings. The appropriate management tools that link the development life cycle to the operational life cycle become essential as an organization embarks on SOA-based projects.

How would implementing an SOA benefit my company?
A key benefit of adapting an SOA approach is the alignment of IT investments with a company's business strategy. As a result, companies can preserve legacy systems by exposing them as business assets without the need for replacement or significant modifications. SOAs also facilitate a company's ability to develop new business capabilities at lower cost, thereby meeting the needs of the business in the required time frames when change is driven by required change or new opportunities.

How difficult are SOAs to manage?
Because of the loosely coupled nature of SOA, an SOA implementation does bring additional management concerns to the forefront. Among them: managing the service integrations as well as the component parts; managing security across organizational or implementation boundaries; and managing policies for deployment, execution, and life cycles. Management is critical to realizing the business benefits of SOA and addresses the nonfunctional aspects of SOA, which are where the majority of the costs lie (security, configuration, financial, and QoS). Managing the nonfunctional aspects of SOA also extends to issues such as compliance and IT governance, which are also critical as SOA is adopted more widely across IT and reuse and integration cross organizational boundaries.

If I am already using Web services, do I need to think about SOA?
There is a relationship between Web services and SOA, but the use of Web services does not constitute an SOA or deliver its benefits. SOA is an architectural approach, while Web services are an implementation choice for adopting an SOA, in which interfaces are based on standardized Internet protocols. The service-oriented approach does not limit interoperability to Web services - it can be implemented using any kind of service-based technology. In that way, full interoperability is only possible through an SOA, and it's the only way to fully realize the benefits of implementation.

Am I going to be able to justify this adoption from a business perspective?
The key to justifying SOA adoption is to realize that the business justification is not tied to the architecture, but rather to the ability to serve customers faster, address compliance requirements efficiently, and to become a more agile in supporting the business objectives and goals using IT. One starting point is to evaluate which business processes generate the most return on investment for your company and prioritize your SOA deployment to make these processes more efficient and more customer-aware. Also, because SOAs are not built upon a "rip and replace" strategy, investment is not geared toward buying more and more technologies, but instead leveraging existing assets and investments for better leverage, standardization, and governance across the business.

Now that I'm planning for SOA, can I incorporate legacy applications into the plan?
Because of the cost and inflexibility associated with legacy systems, they usually need to be "modernized" to be incorporated into an SOA. An evaluation will be needed to determine if the code should be refactored, modularized, or if the application could be replaced with a commercial application. Additional design work will then need to follow to build out a modernized application that is agile enough to integrate with other applications within the SOA.

Can SOAs solve all of my integration problems?
No. Ultimately, it is the information integration strategy underlying an SOA that solves integration problems. The SOA itself is not the true solution; rather, it's a better way to achieve a desired goal. Integration problems are solved through a number of actions related to adopting an SOA: carefully planning for an SOA, assessing business requirements, establishing governance, and enacting an underlying information integration strategy. It is only when these steps have been taken that an enterprise can expect to have its integration problems solved.

Are all SOA solution components completely reusable?
One of the major benefits of the set of architectural principles that define an SOA drives organizations towards a greater level of reuse and consistency. The amount of achievable reuse increases over time once newer services are designed using existing services in an organization. Determining which services are the most appropriate for reuse is where having insight into which business processes align the business goals most closely with IT is crucial.

In the end, IT professionals need to be armed with the most accurate information available to determine how to begin the SOA journey. While the complexity of SOA can raise questions, it's worth the time to investigate how this architectural solution can bring new power to your enterprise.