One of the questions we frequently get asked is “When should I use client-side integration instead of server-side integration?” Typically, we provide a list of scenarios where client-side integration is the only viable option:
- You’re planning to deprecate the application and don’t want to spend money on it anymore.
- You didn’t write the application, but it doesn’t have an integration layer or it’s integration layer doesn’t provide access to the functionality you need.
- You wrote the application, but you don’t have anyone with the skillset to modify it or you don’t have the source code.
- The application doesn’t have a backend. It’s client-side only.
Today, however, I’d like to make an argument I don’t think we make enough. For many scenarios, client-side integration is the best option, even when viable server-side options exist.
When?
When you’re trying to make your users more productive.
Why?
Because you’re spending your money making what they do easier.
You’re not spending your money exposing integration points for user oriented tasks. You’re not spending your money writing a new user interface that wraps or embeds older functionality. You are automating tasks. You are eliminating errors. You are making your user experience better.
In our industry we are accustomed to thinking that there is only one way to solve user productivity problems: a new user interface. Typically, this means jamming as much functionality as possible into a single window using mashups, portlets, frames, tabs, etc. Now you’re users don’t have to switch between different windows to do their job.
But was that really the problem? Instead of multiple windows, they now have everything in one place, either smashed together or separated into tabs or frames. They now have a new user interface to learn rather than the one they were accustomed to. Moreover, you’re application developers are now spending their time creating portlets, web services, etc. rather than adding new functionality.
But what if the user interface you already have is the best one for that particular business function. It was designed for that specific function. It has been through multiple improvement cycles. It does what you need it to do. Were you really unhappy with the user interface or were you unhappy that you have to switch back and forth when you copy and paste? Or that your workflow requires you to look up the user in three different applications? Or that it takes too long to place an order because the wizard was designed for the public website?
Why are there still so many host systems in the enterprise when windows alternatives have existed for thirty years?
Because their faster than windows systems so your most productive, expert users don’t want to let go of them.
Why are there so many windows systems in the enterprise when web alternatives have existed for 10 years?
Because their user interfaces are more rich than web systems so your most productive, expert users don’t want to let go of them.
When you’re trying to make your users more productive, server-side integration is a sledgehammer when you just need a hammer. Your server-side architects and developers should focus on the big integration problems: synchronizing data, backend transactions, exposing web services for your partners. User productivity is a different kind of problem that requires a different kind of solution.
OpenSpan allows you to improve user productivity without changing all of your applications. It allows your users to be more productive without having to be trained on an entirely new system. It allows your users to do what they always did, but faster and with fewer errors. It allows your application developers to focus on new features instead of integration. It not just the only solution, it’s the best solution.