For example, the telecom customers would have their own legacy systems/applications in place, which would dictate the details about the services and the service contracts. It would be required in these cases to align the new definitions of the services and the service contracts with the already existing ones, and the flexibility to reuse something already existing reduces this drastically. In other words, only green-field customers can reuse the SOA components to a large extent.

In a legacy environment, it is required to "wrap" the legacy applications that provide the services, in appropriate SOA wrappers that can expose a service view of the existing legacy applications. It is also required to define appropriate service contracts to provide an indication of the details for service invocation.

Myth #11: Services in the context of SOA are not explicit
Services are autonomous, and they are explicit with specific boundaries defined for each. These services are built to perform specific tasks or to provide specific functionality. Services are discovered using service contracts, and are invoked using the information in the service contract. Each service has a specific life cycle, as shown in Figure 7.

Initially, the services are identified along with the customer. Once the services are identified, they need to be defined, built, and deployed. The federation of services is basically the collaboration between the various services that results in a composite service that provides an aggregated functionality. The services are used extensively once they are deployed. Subsequently, when the reuse level of the services drops or a newer service replaces an already existing service, then the service enters the withdraw phase. At this time, it is possible to reshape the service, which might result in the identification of a new service.

Myth #12: SOA is applicable only to specific industrial domains such as Internet Data center
SOA is an architectural concept, and does not have any dependency on any specific industrial segment. Though it has evolved in the context of an e-service-based industry or an e-commerce-based organization, it is equally applicable to any other industry. The concepts of an SOA can be applied to a telecom domain, financial services domain, and so on. For more details on HP's SOA approach, see http://h20219.www2.hp.com/services/ cache/242475-0-0-225-121.html.

Myth #13: SOA can be sold to customers as is
While SOA is bound to help in the sales of several software products and best practices, it is preferable to tie it up with practical examples and case studies, enriched using the business processes. Because it is not possible to sell a theory in isolation, SOA needs to be coupled with a set of practical examples and products before it can be successfully demonstrated to customers.

Summary
In today's context, it is good to understand clearly what SOA can do and what it is. There are perceptions about SOA that are not always accurate. This article is an attempt to clarify those perceptions and put things in proper perspective. Once the concept of SOA is clear, it helps both the field teams to sell it appropriately and the delivery teams to set the expectations as to what exists and what can be reused.