SOA: Separating myth from reality

There is still enough hype around SOA that it's difficult to get a handle on the realities of implementation.

While most IT managers now understand what a service-oriented architecture can do for IT, many still need help figuring out how to get started on what is a journey. 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 around 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 but 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 lifecycle. The vital starting point, therefore, is not technology, but 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 lifecycle to the operational lifecycle, 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, meeting the needs of the business in the required timeframes 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 – e.g. managing the service integrations as wells as the component parts, managing security across organizational or implementation boundaries, managing policies for deployment, execution and lifecycles. Management is critical to realizing the business benefits of SOA and addresses the non functional aspects of SOA that are where the majority of the costs lie (Security, Configuration, financial and Quality of Service). Managing the non functional aspects of SOA also extends to issues such as compliance and IT governance, again 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 a 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 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. And because SOAs are not built upon a “rip and replace” strategy, investment is not geared toward buying more and more technologies, but leveraging existing assets and investments to 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 re-factored, 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 – 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.

Mark Potts is a fellow and chief technology officer within HP’s management software business. Prior to joining HP, Potts was the founder and chief technology office of Talking Blocks, which HP acquired in September 2003. Talking Blocks was a software company that provided products for managing SOA and Web services.