Develop a migration strategy from a legacy enterprise IT infrastructure to an SOA-based enterprise architecture

Introduction to SOA

Service Oriented Architecture (SOA) and Enterprise Service Bus (ESB) are terms that have been around for a few years, since they were introduced by the research firm, the Gartner Group [1]. However, the actual level of details sufficient for applying SOA approach has emerged just recently.

So, what exactly is the Service Oriented Architecture? "SOA is a component model that inter-relates the different functional units of an application, called services, through well-defined interfaces and contracts between these services" [2]. Defined as such, SOA is a collection of patterns for building an enterprise-level integration layer between applications while abstracting those applications as services. SOA approach advocates the use of open standards, while not ruling out proprietary technologies where they are appropriate, when integrating applications.

SOA relies on exposing application functions as services that can be invoked by external parties. The commonly agreed aspects of the definition of a service in SOA are [3]:

• Services are defined by explicit, implementation-independent interfaces.
• Services are loosely bound and invoked through communication protocols that stress location transparency and interoperability.
• Services encapsulate reusable business function.

Services may exist on different levels and provide different granularity. The following levels of services are usually recognized [4]:

• Technical functions (for example, logging)
• Business functions (for example, getCustomerInfo)
• Business transactions (for example, openAccount)
• Business processes (for example, processOrder)

Some degree of composition may be required between each granularity level. At each level of granularity, it is important that a service definition encapsulates its function in such a way that it is reusable.

Exposing application functions as services allows for efficient decoupling of applications, which is one of the SOA requirements. A function may be exposed as a service through an interface that creates a façade to that function. Such interfaces may be created by either modifying the application directly, or by creating an adapter that transforms requests into application-specific calls.

When application functions are exposed as services, it is important to establish a mechanism for routing messages between service consumers and providers. SOA approach relies on using Enterprise Services Bus (ESB) to meet this requirement. Enterprise Services Bus is a sort of message broker that provides a connectivity layer for heterogeneous service requestors and services providers and ensures appropriate routing of messages between the two. Service requestors are components that call services exposed by service providers in order to fulfill internal logic.

While the most important role of the ESB is providing a connectivity framework, it also provides suitable service levels and manageability as required by modern IT. In essence, the ESB allows for the integration of services in an SOA-based infrastructure and provides "a single point of management over distributed mediation capabilities between service requestors and service providers" [4].

Providing loose-coupling between service requestors and providers, the ESB allows for substitution of one service implementation with another, with no effect to the consumers of that service.

While ESB provides connectivity between services, other SOA components provide support for exposing, discovering, and invoking services. These components include Business Service Directory, Business Service Choreography, and ESB Gateways. However, the deployment of these components needs to be dictated by actual business requirements. For instance, many smaller enterprises may find that they do not really need ESB Gateways and, therefore, will not overcomplicate the infrastructure by establishing them.

Business Service Directory provides service routing information that the ESB is relying on, while supporting communications between service requestors and providers. However, the main role of the Business Service Directory is providing details of services that are available for performing business functions supported by the infrastructure. Essentially, the Business Service Directory is a place where service consumers need to go to find services supporting their operations.

While Business Service Directory provides information about existing services, the Business Service Choreography component allows composing new services out of existing lower level services. For instance, a new business transaction may be created by defining a workflow involving several lower level business functions. Such workflows become new services and get published into the Business Service Directory.

Back to top

Developing an SOA migration strategy

A lot of large enterprises providing multiple services find today that their IT has been heavily departmentalized. This primarily happened because a lot of enterprises opted to allow each business department to take care of its IT needs, instead of relying on a centrally managed IT organization. Therefore, a lot of departments ended up creating applications in isolation from other departments. Often, a company may have several billing, account management, and alike systems supporting different aspects of business. Moreover, a lot of companies tend to install the "best of breed" software without considering integration with other applications. They later find that special arrangements are often required for making a new application a part of the IT infrastructure. Figure 1 below is just an example of an IT infrastructure that might be found at some enterprises today:

One of the IT challenges that could be noticed from the diagram above is that most of the applications communicate directly to each other. Such dependency may become a real problem when an application needs to be modified or phased out. Any modification may lead to updating each unique communication line in its own way. Therefore, such changes may become a costly endeavor. This situation is called tight coupling between applications and is becoming a real head-ache for some enterprises.

On the other hand, SOA puts loose coupling as one of the main principles for successful application integration on the enterprise level. Opposite to tight coupling, loose coupling is:

restricting the number of things that the requester application code and the provider application code know about each other. If a change is made to any aspect of a service that is coupled, then either the requester or the provider application code (or, more likely, both) will have to change. If a change is made by any party (the requester, provider, or mediating infrastructure) to any aspect of a service that is decoupled, then there should be no need to make subsequent changes in the other parties. [5]

Figure 1 also demonstrates a practice employed by some enterprises, when an application with the required functionality is deployed in several business areas (for example, Application 1 and Application 1'). Often, the application is slightly modified with each deployment to meet unique requirements of a specific business area. While there are no obvious disadvantages to having multiple applications with the same functionality, their existence may indicate the following:

• Potential existence of data duplication in the enterprise, which compromises operational data accuracy. This is caused by most of such applications relying on the same data sources and storing portions of that data locally for performance or other reasons.
• Higher cost of maintaining multiple applications than the cost of supporting a single solution
• Special care needed when such applications are consolidated to reduce impact on applications that have been interdependent with the phased out solutions.

These challenges can be addressed by applying SOA principles for a successful integration of applications on the enterprise level.

It is worth noting that when an enterprise is not heavily departmentalized, applying SOA may be a reasonable task. However, when a number of IT departments within a company are big and the number of applications that they host is even bigger, implementing the SOA-based Enterprise Architecture may become a challenging task that requires careful planning.

Splitting a complex and heavily departmentalized enterprise into a number of separate domains may make things much easier. First, each domain may be decoupled from the rest of the enterprise by exposing specific application services through the ESB, and, second, applications within a domain can be later SOA-enabled without affecting the rest of the enterprise.

Such partitioning into domains may be organized according to a business function (for example, Sales, Account Management, Customer Services, and so on) or implementation (such as Mainframes and Unix servers). However, essentially, a domain would contain applications that are connected tighter, and would therefore have greater dependencies to each other then to the rest of the enterprise.

The following criteria may be used for determining if a set of services belong to a separate domain:

• Functional domains are selected based on a business function. Services in these domains consume a limited number of services from the outside of the domain and expose a limited number of services to the outer enterprise.
• Technology-based domains are selected based on a set of technologies they utilize. These may include mainframe applications, distributed applications, and so on.
• Application-based domains are tightly coupled collections of applications. e-Business applications or a collection of mainframe applications that share the same database may be an example of such separation.

Initial separation into domains may also be purely conceptual, allowing for identification of application functions that need to be exposed as services to the rest of the enterprise.

Once services are identified, domains need to be separated from each other by establishing clear boundaries enforced through use of gateways and firewalls. Such separation allows for better control over application interactions and further flexibility for making changes to applications without dramatically affecting the rest of the enterprise. Such separation may be achieved through several different approaches:

• Defining business functions that expose functionality of a domain as a coarse grained service: Business functions are driven by needs of the enterprise, rather than internal implementation details. Business functions may call finer-grained technical services within the domain internally, providing a service to external consumers. The main goal of defining business functions is limiting interactions between domains to well-defined points.
• Adding gateways that translate assumptions of one domain into assumptions of another domain: Gateways also allow establishing clear separation between external entities (business partners, for example) adding better control capabilities. Often, gateways may be combined with business functions into a single logical entity. However, adding a gateway is dictated by business requirements and may not be needed if domains share the same assumptions. Gateways could be implemented using one of the following approaches:
  • Transparent/Proxy Gateways expose domain services in such a way that a consumer believes that it interacts with a business function directly. Such gateways may also perform transformation of incoming and outgoing messages based on enterprise infrastructure requirements. Transformation may be required when domain data is stored in a very specific format that is radically different from enterprise-wide conventions. For example, domain-specific binary data may need to be transformed into an XML per enterprise policies.
  • Firewalls allow for enforcement of the domain encapsulation. Although, they do not perform any transformation, firewalls limit consumer access to only predefined points in the domain boundaries. Also, introduction of a firewall allows detection of services that do not follow encapsulation policy of a domain.

When analyzing application functions to be exposed to the outside of a domain, one may find that the actual service is a combination of a finer grain functions. One mechanism to achieve such orchestration of application functions into a business services is to introduce a Local Service Bus (LSB), with the addition of a Service Choreography component into such domains.

Local Service Bus is an instance of an Enterprise Service Bus that provides connectivity support for a single domain. Being extended with the Service Choreography component allows the domain to compose higher level business functions that get consumed by the ESB.

Below, Figure 2 demonstrates the infrastructure that may result from following the above steps:

Once all domains are encapsulated and business functions are exposed, it becomes easier to integrate them through the ESB and to employ Business Choreography to create higher level Business Processes and Transactions. Once the ESB is in place and the enterprise is functioning, the migration of legacy applications within domains may be performed with less impact on the rest of the enterprise.

The sample work breakdown structure below (Table 1) describes major steps that an enterprise may need to take in order to migrate from a legacy infrastructure to the SOA-based Enterprise Architecture. Although, the actual list of tasks is specific to a particular enterprise, the list below gives an idea of things that need to be taken into account.

Table 1. Work breakdown structure

Back to top

Conclusion

The phased approach to the SOA-based Enterprise Architecture allows for easier mitigation of risk associated with changes to an enterprise IT infrastructure. Often, a company realizes that supporting an old infrastructure is too expensive; however, drastic changes are risky. Splitting the enterprise into domains and introducing the concept of Local Service Bus mitigates the risk and allows migration to a newer infrastructure in well controlled phases.

It is useful to keep in mind, though, that the approach can be effectively applied in diverse environments only. Homogenous environments are unlikely to benefit from such a strategy.

Resources

• Notes within article:
  1. Gartner Group Web site
  2. New to SOA and Web services Web page
  3. "Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture" (developerWorks, June 2004)
  4. "Using Business Service Choreography In Conjunction With An Enterprise Service Bus" (IBM, 2004)
  5. "Patterns: Implementing an SOA using an Enterprise Service Bus" (IBM, July 2004)
  
  
  
• Browse for books on these and other technical topics.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the author

Comments

Back to top

Trademarks

Table of contents

• Introduction to SOA
• Developing an SOA migration strategy
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

We want to know you!

Update your My developerWorks profile and start connecting with others

Special offers