The key pillars of an SOA’s success

Although a wide variety of factors determines the success of enterprise’s SOA strategy, four (4) pillars for success can be underlined and highlighted.

1. Organizational Alignment

The extent to which an organization has aligned their business and technology strategies is a key determinant of SOA readiness. It is important to evaluate the business strategy for well-defined business services and processes, and it is also critical for the success of an enterprise’s SOA strategy to secure a budget and to have an organizational alignment with respect to a funding model. Organizations with funding models that facilitates cross-unit cost sharing are typically much more successful in migrating to SOA enabled space than those with more inflexible funding models.

A flexible funding model is required and needed to compensate for initial overheads caused by applying SOA principals. Overheads are caused by different factors. The project team members have to familiarize themselves with new SOA standards, patterns and processes. However, the initial overhead is caused by the efforts required to increase reusability.

In addition, the choice of a suitable project piloting the implementation of the enterprise SOA is a critical factor for the success of an enterprise’s SOA strategy. It is very important that chosen project should be as visible as possible. However, this does not necessarily mean that it has to be prestigious. Ideally, the SOA projects should run no longer than one or two years, with a first delivery after six months.

2. Setting Up a SOA Swat Team

Such a team should focus exclusively on how best support and establish the SOA in the organization. The SOA Team will therefore have to contain evangelists whose task it is to explain the benefits of an SOA to the different departments and this initiative includes helping target audiences to gain an understanding of key SOA architectural principles, concepts, best practices, and technologies as well as the support in the actual implementation of these principals.

3. Methodology and Process

Adoption of an iterative methodology is critical to support quick, efficient, service-oriented analysis and to design lifecycle activities that complement SOA. Also, formal governance and operations
procedures make an organization more likely to adapt to SOA. New techniques for model-driven architecture (MDA) that heavily involve visual business process and service interaction modeling approaches are beginning to emerge, and are also important to evaluate. Examples of SOA success factors pertinent to methodology and process include:

• Governance Model — Policies and procedures for the identification of necessary services,
  coordination of complementary or conflicting service development efforts, and full lifecycle management of services from proposal to support
  
• Model-Driven Architecture (MDA) — Familiarity and/or usage of emerging approaches and technologies that enable development of service-oriented models to facilitate interaction and communication of requirements and logic between business analysts, architects, developers, and testers.

4. Technology and Tools

SOA success is highly correlated to the choice of technology and tools utilized in both design-time and run-time environments, as well as the way in which those technologies and tools are designed to interplay to deliver a true service-oriented solution.

• In the design-time environment, SOA readiness is impacted by how well the integrated development environment (IDE) extends to support rapidly emerging SOA implementation standards, especially Web services protocols. Design, development, testing, and deployment tools must support unique protocols and attributes of SOA, and critical infrastructure is necessary to support publication and discovery of new and existing services.
• In the run-time environment, SOA readiness demands an infrastructure that supports secure, interoperable, and reliable messaging between services, and is capable of orchestrating service interactions to support business process demands.

Choosing the appropriate tools and technologies is not sufficient to achieving SOA success alone. The use of appropriate design and message exchange patterns is critically important. These enabling patterns allow organizations to deliver and utilize services in a repeatable manner to ensure consistency and adherence to best practices necessary to scaling SOA across the organization.

Recommended approach

Any organization’s strategy for moving to SOA should involve the following four (4) major activities:

• Education — Gain an understanding of key SOA architectural principles, concepts, best practices, and technologies.
• Assessment — Determine the current state of your organization’s readiness for moving to SOA by identifying existing best practices and gaps, as well as major opportunities for realization of benefits from SOA.
• Planning — Develop a phased SOA migration plan that makes sense for the organization, mitigating business and architectural risks while measuring and delivering significant return on investment (ROI) through increased flexibility and responsiveness to changing market demands, as well as decreased design, development, integration, and support costs.
• Execution — Deliver prototypes, pilots, infrastructure, and services consistent with the phased SOA migration plan, seeding and embedding SOA perspective and best practices
  throughout the business and technology groups within the organization as well as among key customers, partners and suppliers.

Hidden SOA Challenges

The service-oriented architecture (SOA) is not new, but it is rapidly emerging as the premier integration and architecture framework in today’s complex, heterogeneous computing environments. While the concept of SOA has existed for years, there were few standards that enabled open, interoperable, non-proprietary integration solutions.

Today, many software vendors are moving at a frenetic pace to support SOA. Web services and SOA are not equivalent; however, SOA realized using Web services is generating new found excitement in the integration world. Additionally, organizations must understand that SOA is not realized by merely flipping a switch or porting your existing services to some vendors software platform. For long-term success, companies must put SOA in their IT “DNA” and develop an overall SOA strategy that aligns their IT and business goals.

Since SOA is based on open standards and is frequently realized using Web services making sense of the WS-Specifications, which may add to the confusion of how to best utilize SOA to solve business problems. Additionally, many companies face the challenge of how to best utilize SOA to solve their business problems.

Organizations should be aware of several important SOA realities to dispel any myths or misunderstandings regarding the best approach to a smooth transition to SOA, including:

• SOA is an architectural approach that has been around for years (eg: JINI, DCOM). While there are new ways to realize SOA, including the use of Web services technologies, leveraging the experience of a services organization well-versed in SOA is essential to understanding technologies and techniques necessary to gaining the business benefits of SOA.
• SOA is more than just developing and deploying software. Organizations must evaluate their funding and governance models, analysis and design techniques, development methodology, deployment and support plans.
• Web Services (XML/SOAP) are the preferred way to realize SOA.
• Moving to an SOA enabled infrastructure should be done incrementally, but requires a shift in how we architect and compose services-based applications while maximizing existing technology investments and this requires a shift in how we compose service-based applications while maximizing existing IT investments.
• Software Vendors have recognized the challenges customers face in moving to SOA and have developed several SOA service offering that leverages years of experience in delivering enabling technology solutions that met the unique needs of each customer.
  

Recommended Approach

Any organization’s strategy for moving to SOA should involve the following fourmajor activities:

Education — Gain an understanding of key SOA architectural principles, concepts, best practices, and technologies

Assessment — Determine the current state of your organization’s readiness for moving to SOA by identifying existing best practices and gaps, as well as major opportunities for realization of benefits from SOA

Planning — Develop a phased SOA migration plan that makes sense for the organization, mitigating business and architectural risks while measuring and delivering significant return on investment (ROI) through increased flexibility and responsiveness to changing market demands, as well as decreased design, development, integration and support costs.

Execution — Deliver prototypes, pilots, infrastructure, and services consistent with the phased SOA migration plan, seeding and embedding SOA perspective and best practices throughout the business and technology groups within the organization as well as among key customers, partners and suppliers

Understanding SOA

Looking around we see the term or acronym SOA becoming widely used, but there's not a lot of precision in the way that it's used. The World Wide Web Consortium (W3C) for example refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. We see similar definitions being used elsewhere; it's a very technical perspective in which architecture is considered a technical implementation. Although the concepts behind SOA have been around for over a decade now, SOA has gained extreme popularity of late due to web services.

A service-oriented architecture is an information technology approach or strategy in which applications make use of (perhaps more accurately, rely on) services available in a network such as the World Wide Web. Implementing a service-oriented architecture can involve developing applications that use services, making applications available as services so that other applications can use those services, or both.

The components of a Service-Oriented Architecture include:

• Service providers. A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs.
• Service consumers. A service consumer is a set of components interested in using one or more of the services provided by service providers.
• Service repository. A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided.
  

Figure 1. Service-oriented architectural components

What are the implementation Challenges of SOA?

While designing and implementing a service-oriented architecture, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:

• Service identification. What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service?
• Service location. Where should a service be located within the enterprise?
• Service domain definition. How should services be grouped together into logical domains?
• Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services?
• Service orchestration. How are composite services to be orchestrated?
• Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain?
• Service governance. How will the enterprise exercise governance processes to administer and maintain services?
• Service messaging standards adoption. How will the enterprise adopt a given standard consistently?
  

Why SOA?

There are many reasons for an enterprise to take an SOA approach, and more specifically, a web services-based SOA approach. Some of the primary reasons in my opinion are:

• Interoperability. The SOA vision of interaction between clients and loosely-coupled services means widespread interoperability. In other words, the objective is for clients and services to communicate and understand each other no matter what platform they run on. This objective can be met only if clients and services have a standard way of communicating with each other -- a way that's consistent across platforms, systems, and languages. In fact, web services provide exactly that. Web services comprise a maturing set of protocols and technologies that are widely accepted and used, and that are platform, system, and language
  independent. In addition, these protocols and technologies work across firewalls, making it easier for business partners to share vital services.
• Scalability. Because services in an SOA are loosely coupled, applications that use these services tend to scale easily -- certainly more easily than applications in a more tightly-coupled environment. That's because there are few dependencies between the requesting application and the services it uses. The dependencies
  between client and service in a tightly-coupled environment are compounded (and the development effort made significantly more complex) as an application that uses these services scales up to handle more users. Services in a web services-based SOA tend to be coarse-grained, document-oriented, and asynchronous.
• Flexibility. Loosely-coupled services are typically more flexible than more tightly-coupled applications. In a tightly-coupled architecture, the different components of an application are tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it difficult to evolve the application to keep up with changing business requirements. The loosely-coupled, document-based, asynchronous nature of services in an SOA allows applications to be flexible, and easy to evolve with changing requirements.
• Cost Efficiency. Other approaches that integrate disparate business resources such as legacy systems, business partner applications, and department-specific solutions are expensive because they tend to tie these
  components together in a customized way. Customized solutions are costly to build because they require extensive analysis, development time, and effort. They're also costly to maintain and extend because they're typically tightly-coupled, so that changes in one component of the integrated solution require changes in other components. A standards-based approach such as a web services-based SOA should result in less costly solutions because the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because services in an SOA are loosely-coupled, applications that use these services should be less costly to maintain and easier to extend than customized solutions.
  

Service-oriented architectures are rapidly being accepted by the IT world as a sound, modularized approach for building and deploying services across the extended enterprise. However, practical implementation of these architectures requires careful planning. Interested enterprises must first make sure that they're geared up to implement and support them in the long-term.