Integrating applications -at least at the enterprise level- is today generating the same amount of work, or even more than building new ones. In fact, it can be argued that as far as corporations keep exposing their business processes as cohesive and autonomous services, integrating them in new configurations is a way of producing new applications.

However, Service Oriented Architecture adoption is still timid and it is primarily been adopted in new development, whereas just a small portion of old corporate solutions are wrapped with a service layer than can be exposed by using standards. In many scenarios, making applications interoperate takes more work and means rewriting parts of the applications. Let's take a quick look at the several approaches that are available to integrate them.

While most of the time we try to integrate at the back-end, at the business-logic or database levels, sometimes this is too difficult to do, mostly with old-style applications that doesn't have properly isolated components or tiers. This may sound like heretic after so many years of talking about n-tier development and even SOA, but consider how many core solutions running on mainframes are working since decades, before the idea of separating the logic from the UI came along.

For this cases, there is a series of well-established patterns by now for front-end level integration. Indeed, several toolkits or frameworks are available to make easier to automate UI to be able to use it programmatically. In this cases, a framework allows to do screen-scrapping and input injection for old TTY consoles, adding a layer that allows to automate menu selection, data entry, and then screen reading, even contemplating error or warning messages, so you can expose a service for some operations that are actually performed by using the old terminal interface running on a non-visible server emulator.

Sounds sloppy? Well, it is, but you know the distance between what's ideal and what's possible can be really large. Sometimes you don't have access to the code of these legacy systems, or they are running on platforms where the technology to isolate and expose services from the core -not from the UI- is not readily available.

While you have to be careful about this idea, properly dimensioning the usage load to avoid hogging the legacy systems, the benefit of this approach is that you don't need to touch it at all. Actually, the system is never aware of been used from a non-human consumer.

Indeed, this approach is also extended to improve efficiency in multi-application scenarios like -typically- call centers. There the typical user interacts with customers and has the need to access many different corporate applications depending on the task. They could need to access the CRM, a sales order entry system, a claiming or trouble-ticket application, account balances, statistical or historical information, or related systems owned by subsidiaries or even merged companies not yet unified.

In such scenarios we are seeing an increased adoption of composite desktops, where the user can host several different applications (from terminal consoles to windows to web interfaces) into a unified (generally tabbed) container. The advantage of using this kind of container is that it can react to specific UI events, like messages, alerts, refreshes and so on, and make them converge into a unified experience.

Moreover, applying different interaction techniques for different applications, the container can replicate certain actions, saving manual synchronization effort to the user. One implementation fo this concept is found in the Customer Care Framework from Microsoft. Based on the foundation of the Composite UI Application Block (CAB), it provides a hosting environment for different types of applications and allows scripting to orchestrate the user interfaces by means of the appropriate mechanism in each platform. Thus, when the user enters a customer code in the application having focus (let's assume it is a windows CRM), the container can forward this code (even translating it if the underlying systems have different codes) and search the same customer in a second application (using the HTML DOM for a web app, for example) and do the same for a third one (using the keyboard buffer for a console app, for example).

These kind of tools provides all the abstraction to read or write from several different UI sources (screen scrapping, DOM, windows handles and controls, even Java applets), and then they build on top of that, providing higher level services like single sign-on, where the operating system credentials are converted into the proprietary user/password combinations needed and send trough the different clients in a secure way, plus messaging, state saving and forwarding, and so forth. It also allows to easily integrate the contained applications with devices like a PBX or other caller-id mechanism, and more.

Of course, this is a mid-term solution, and it should never been taken as a replacement for real systems integration, which is better done on the back-end. But when you are automatic the user experience rather than clearly-defined business processes, this is an option to take in consideration.

Integration is such a broad topic that I hope to go back to it and talk about other part of the problem soon. By now, I just wanted to comment on an often overlooked alternative, which can be faster and cost effective, although it is usually a short-term solution while you work on the longer plan.