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.

We seem to be in the verge of an important change on computer interfaces. The mighty keyboard dominated the human-to-computer interaction from the last 50+ years. Indeed, since its beginning, in the form of a teletype first, then in a more direct way. Output was more complicated, and moved ahead a bit faster with the jump from cards to printers and finally to the still dominating (but slowly fading) Cathodic Ray Tube.

Anyway, computer history is not linear, but logarithmic, and while the mouse started shaking its tail just a mere twenty-something years ago, it became so ubiquitous as his cousin keyboard, and certainly more fashionable.

But in the last years we are seeing a lot of wanna-be interfaces trying to win over this dynamic duo. Technology declared obsolete the CRT and it is being replaced by LCDs, which are maybe in the process of being replaced by OLEDs, but the important thing is that this sparked a myriad of new screen formats, from 19" notebooks to 2" portable video players. In one corner, multi-monitor setups are gaining adoption, while many of us have several tiny screens where we keep up with our schedules, calls and videos.

Pointing at screens with a stylus first and then with a finger is so common, than many are pushing for the next step which is allowing you to use as many fingers as you want, as in the talked-about-ad-nauseam iPhone to the still niche Microsoft Surface. But really, if you try any of this devices (I played with a prototype) you see there is a lot of great uses it can enable.

Still, I can't see touch screens of any kind wining over the mouse any time soon. I can't imagine having to touch my notebook screen all the time. The small arrow has the nice property of not hiding anything, and your hand can move the mouse over the table, so you don't get tired too soon. But someone smarter can figure out a better way than the mouse, maybe...

The keyboard seems a more difficult rival to me. Even if voice recognition improves a LOT, and even if you are a lousy typist as I am, I guess the keyboard is more practical. For people who mostly write prose document voice can be a great complement, but I can't imagine how to edit text easily with voice commands. And definitively, I can't think of programming with voice... can you? Just try to read a piece of code aloud...

In any case, these innovations and additional input and output devices will be increasingly common, if they still can't beat old Querty and Mickey. And we as developer have to start thinking on them more seriously. I guess the days of the pop-down menus are over. Even desktop application interfaces are sliding off them. Look at Office and their ribbons. Even if you don't like them too much, I think they are more effective than the previous polluted menus.

Well, maybe what we have to think more and more about is separating the interface from the logic, but this time for real. While we got accustomed to tiered applications, we still have a tendency to think in menus and data entry screens as the UI when we think in our domain model. It noticed that some time ago when I had to provide an IVR interface (phone-based, with a mix of voice and button commands) for a system. My team have to make some changes to the business objects to make them more usable from something different than a windows or a web page.

Windows Presentation Foundation, and now Silverlight, as Flash is doing from some years ago, makes the need for this separation more clear, and we can see separated tools, with some capabilities in the middle, for both interaction designers and programmers. And I avoid saying "graphic designers" on purpose, because there the web was full of graphic designers producing nightmarish interfaces because they were not prepared. Interaction design is much more than that. I guess this could be the next hot area for the upcoming generations, together with our now old profession.