Legacy Integration: A Critical Part of SOA by Ron Nunan July/August 2006 Today’s enterprises are making substantial progress in moving enterprise applications to a highly flexible distributed architecture. Commonly referred to as a Service-Oriented Architecture (SOA), this movement leaves behind the silo or monolithic approach to solving business requirements and has become a requirement for staying competitive in a turbulent market. SOA is now a fully accepted architectural approach that has re-defined the look of new enterprise applications. Drivers for the SOA movement include the need to: • Be responsive and flexible to continuously evolving business needs • Overcome the challenges introduced from shorter technology lifecycles, which yield incompatible, heterogeneous software systems as business applications outlive the technologies with which they were created • Address the pressure to extend business services to broader audiences. The benefits associated with an SOA are complicated by the massive existing inventory of older applications; most enterprises have an inventory of reliable and functional applications that weren’t designed to participate in an SOA. The challenges of accommodating these existing applications are twofold: • Older applications built with a different generation of technology from those typical of an SOA; many based on legacy or mainframe systems • Application dependencies and the behavioral context the application assumes. The legacy application challenge can be solved using any of several available integration technologies. The application dependencies can’t be solved simply through the use of integration technology. That problem will be solved only when the implementation of an integration technology correctly accounts for the behavioral requirements of the integrated applications. The key is in the implementation of the integration effort. While getting the applications to a common technology is the first step, the next step is assuring that the extended workflow of the finished solution doesn’t break the legacy application. SOA Integration Enterprises for several years have invested in and built out SOA projects. This includes pulling disparate information systems together through common technologies and integration efforts. Legacy systems are often perceived as roadblocks to implementing SOA because these systems don’t share the aspect of common technology that’s fundamental to tying together the applications when SOAs are built. To the typical SOA application developer, the legacy applications are just an unknown black box of business functionality. To get past this perceived roadblock, the legacy systems need to be represented in SOA-understood technologies. This is an integration effort that’s most successfully solved through service wrapping. An assumption of SOA is the use of granular reusable services that can be made and re-made into composite applications as required. Legacy applications can quickly and easily be wrapped, letting them be seen from the broader enterprise as just another set of reusable components. Specifically, this lets monolithic applications be seen and used as a set of small reusable components that are granular slices of the original application. This task is where modern legacy integration tools excel. Using SOA technology- based integration, almost any user can service-enable functionality already available from legacy applications for use in various SOA-based initiatives. Benefits include: • Non-intrusive process: Legacy integration shouldn’t require application changes. An SOA-based approach eliminates the need for architectural changes and reduces the likelihood of downtime. It also enables integration of applications using various methods: the user interface, application logic, and directly to the data. • Lower risk: With legacy Web integration, the first project is often completed in a matter of days, and further integration can occur iteratively, as experiences and ROI from the first integration accrues. That way, enterprises can try out new opportunities at a much lower risk than traditional methods allow. • Time-to-market: Even complicated integration projects can be completed in weeks rather than months or years. Businesses can gain competitive advantage by leveraging the functionality trapped in existing applications faster than competitors can. Legacy Integration Tools When evaluating legacy integration, organizations should investigate solutions that can deal with strategic applications that convey functionality resident in mainframes and other legacy systems, or business process exposed through Web interfaces and homegrown Windows applications. The solution should support a wide range of industry standards to ensure that solutions developed today work tomorrow. This is critical, as an SOA isn’t a set of Web Services; it’s a set of services. How the services are built, and with what technologies they’re built, depend on the desired business outcome. For legacy access, it’s best to not tie the integration to a specific technology. A tool that supports the definition of a service as an abstract that can then be turned into any appropriate technology, such as a Web Service, will have a longer life than any tool that’s technologically specific. When looking for a legacy integration solution, consider a solution that offers: • A rapid approach for reusing legacy functionality abstract service creation • The ability to expose created services as any type of component or technology (The more abstract the service, the more reusable it will be over time.) • A graphical, simple point-and-click process for abstracting required legacy functionality in component form that doesn’t disrupt the underlying legacy application • Functionality that insulates developers from the intricacies of legacy technologies • The ability to create clear layers of abstraction, producing solutions that don’t require re-engineering existing applications to access the underlying functionality. Dependencies The issue of dependencies isn’t always an obvious one. This has everything to do with the context of the involved applications’ business requirements and the applications’ original architectural approach. SOA isn’t about creating services; it’s about building distributed applications from reliably reusable services. That’s why SOA has at its foundation a set of attributes that need to be employed. If we look at a few of them, we can see a possible issue with the use of legacy applications: • Services are stand-alone with few dependencies • Services should be loosely coupled • Services are location-independent. The goal of an SOA is to offer every function as a low-level or granular operation within the service (see Figure 1). Services, in a proper SOA, are typically granular enough to be devoid of any specific business context; having this level of granularity lets the services be used and reused in larger combined or composite services. If a base-level service were to be built to meet the needs of a specific business workflow, then its reuse for other business needs would be curtailed. For legacy applications, enabling technologies solve the issue of creating low-level granular services. What they don’t solve is the dependency limitations on how they can be used, including the activity of composing larger, coarser-grained services with business context. SOA With Legacy Applications Many legacy applications were built with the assumption of strong control over resources. This is easily seen when thinking about a transactional application. While this type of application necessitates some technical detail, the result is best practices that benefit the successful SOA. Consider a legacy application that governs financial information, for example. To be completely sound, the application must ensure activities at the business level happen completely or not at all, regardless of how the application components are used. This requires a high level of trust in the use of components. For legacy applications, implementing discreet pieces of legacy software to perform as a single unit of work is essential to many of the embedded businesses. The common expression for this is “transactional control.” Typical methods used for transactional integrity by legacy applications force the use of locks on the underlying components—the pieces of the application that actually perform the work. To guarantee a successful outcome and keep the application performing up to expectations, these locks and the duration of the activities are tightly controlled. Again, this is a common method employed in legacy application design. This practice typically centers on short-lived operations—processes where the result, success or not, is quickly known. Unfortunately, this is at odds with a well-behaved SOA, which prefers services loosely coupled without tight control. Developers often find that SOA transactional controls and specifications aren’t designed to bring transactions into the Web Services world. While SOA technologies let developers make many new changes to existing applications, they don’t remove the basic legacy needs and requirements these applications depend on and need to accommodate. Using legacy components as lower-level operations or as services in an SOA puts the burden of understanding the legacy application’s workflow on the SOA developer. It alleviates the need to know legacy technologies, but not the legacy application. For example, developers with SOA initiatives that use legacy assets need to remember to: • Focus on architecture rather than a technology. Envisioning everything that can be done to a legacy application with SOA technologies isn’t the road to success. • Understand the needs of the application. If the legacy application is mapped directly into an SOA technology, the risk of not building in business context is high. This curtails the basic SOA benefit of reuse. Conversely, a solid understanding of the legacy application is important when designing the services to ensure their use won’t harm the source legacy system. If this is the case, then a more tightly coupled, less reusable implementation may be necessary. • Collaborate across teams. Cross-departmental understanding, especially with the legacy application architects or developers, is necessary. Politics and a lack of common ground between legacy and SOA development groups is a real barrier to realizing a successful SOA project. Legacy-based services should dictate development understanding across team boundaries. Involved groups should span legacy understanding and SOA skills. • Account for legacy assets: To succeed with an SOA in most enterprises, legacy assets need to be correctly accounted for. Doing that requires engaging resources literate with the involved legacy applications and then leveraging the readily available yet unique set of tools that create the needed services out of the legacy assets. Conclusion By making legacy integration a critical part of the SOA infrastructure, companies can share computing resources more efficiently across all organizational units and get the most out of their SOA investment. Whether driven by business needs, user requirements, or customers’ service expectations, enterprises that have built their business on reliable legacy systems realize their strongest competitive edge with SOA lies in their legacy assets—data and business logic. Organizations have discovered that by leveraging their existing legacy resources to serve new SOA business requirements, they can achieve immediate ROI and gain a competitive edge. By adding legacy integration software to the SOA technology mix and planning, companies can create new opportunities to innovate with fewer technological constraints, maximizing legacy and SOA investments. Service-oriented legacy integration software is the key to successful SOA adoption. By leveraging legacy integration solutions with existing SOA integration and Web Services technologies, companies can decentralize legacy resources, enable the development of connected systems, services and composite applications, and place legacy data and applications on equal footing with modern technologies. About the Author Ron Nunan Email: Ron.Nunan@attachmate.com Ron Nunan is a chief strategist with Attachmate and a strong proponent of SOA. He seeks avenues to help customers address current integration needs while helping build a foundation for future initiatives. Together, Attachmate host integration solutions and SOA empower companies to embrace emerging technologies such as SOA, speeding real-time business initiatives while helping reduce IT complexity and cost.