In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.

Once upon a time

For a long time, the basic building blocks of enterprise applications were easy to choose:

  • a programming language
  • a distributed component model infrasturcture
  • a relational database management system
  • and a ui library

The database often resided on a dedicated database server, an (app) server hosted the business logic, and the ui was put on the client. The client usually was a Windows-based pc, running apps written in C++, Java, Basic, Pascal, or any other language the developer saw fit, the only prerequisite being access to some graphical user interface toolkit. Conceptionally, each enterprise application lived in its own world. Exchange of data with one of the few other applications was neither planned nor wanted. Why would department a share its information with department b?

And then came the problems

Throughout the years, business processes became more complex. What once was done in one department, became a shared effort among several business units, requiring the use of several programs. Consequently, the users wanted the applications to cooperate with each other.

And then came the complaints

Rolling out client software became expensive, time-consuming, prone to error. Building the user interface was said to be expensive, too. As was the necessity of frequently updating the hardware: more programs on the pc required more ram, bigger hard drives, faster cpus, networks with higher bandwidths. The solution seemed simple. If rolling out the ui is expensive, why roll it out at all? If upgrading the pc is expensive, why do an upgrade at all? The rise of the web brought a browser to every client (pc). Hence, wasn’t it natural to use it as a runtime environment for the ui?

Let us stop here for a moment. As I have said at the beginning, enterprise applications used to be distributed: different layers ran on different pieces of hardware. Usually the ui layer (a program on a desktop pc) communicated with the business logic layer using some binary protocol, for example IIOP, RMI over IIOP or T3. The amount of data that needed to be transferred depended on the interface the business logic provided. If it was well designed, only small amounts of data had to be transmitted. And that data was just… data.

As we shall see in the second installment, this was going to change…

This is a (slightly updated) repost of a piece I published on my blog Tommi’s Blog. I deleted the blog in the wake of the GDPR, so the original version is no longer available, or only through the WayBack Machine of the Internet Archive. Please note: code usually has not been updated, so language feature reflect the time the original post was written.