Occasionally connected computing architectures.

As the price/performance of notebook computers ant other mobile platforms grows ever more compelling, the desktop computer's days are numbered as the dominant business-computing platform.

This trend has interesting implications on the future of enterprise application architectures. Today's centralized architectures require persistent connectivity. Even in a world with stationary employees and desktop systems, this architecture has been rife with problems due to the performance and latency issues inherent in accessing centralized applications. In a world where employees and systems are mobile, this architecture simply doesn't work any more. Persistent connectivity is impossible in a mobile world, which means it is also impossible for employees to access their enterprise applications when they need them most--when they're in the field doing their jobs.

Intel's recent Centrino launch has added considerable momentum to the mobilization of business computing, by making mobile and WiFi platforms far more affordable than was previously possible. As part of this launch, Intel publicized the notion of "occasionally connected computing"--that is, applications that keep working productively even when there is no network connection--and encouraged application infrastructure vendors to deliver products to support this new vision. After all, a mobile-enabled platform loaded with "immobile" applications (those that require persistent connectivity) is not mobile at all.

Because most business applications and databases today are centralized, they are wholly unsuitable fur occasionally connected computing. If network connections drop or become unavailable, most applications can no longer operate. Access to the application and its underlying data is lost, as is any user work in progress.

For example, think about the typical SFA, CRM or ERP application. Once you remove persistent connectivity from the equation, they are rendered useless. Even applications that claim support for offline operations fall far short of providing true occasionally connected computing capability. Roaming between connected and disconnected modes causes cryptic error messages, exposing connectivity transitions and interrupting use. Worse yet, these approaches may require the user to re-login under a different mode of operation.

Imagine instead if that same application operated independent of connectivity, much like Microsoft Word or other typical desktop applications. You could roam between connected and disconnected states without interfering at all with application functionality. The synchronization of data occurs in the background when there is connectivity, but to the user this has no impact on the availability and performance of their applications. This is the essence of occasionally connected computing.

So, what are the choices for providing occasionally connected access to business applications? Historically this has required the development of expensive special-purpose versions of the existing application--versions with stripped down functionality, such as read-only access to information or the application requiring a manual switch to an "offline" mode. This approach is expensive, due to the requirement for extensive customer development and support, and the resulting applications are typically extremely limited versions of the original.

With the advent of inexpensive mobile PCs enabled by technology such as Centrino, and the continuous price plummet of both storage and processing power, the centralized application architecture no longer makes sense for most organizations. Workers have enormous power in their note book computers, but the centralized architecture only uses a fraction of it, because all processing and storage is centralized.

At the same time, this architecture exacts a price on end-users by forcing them to be online to use their applications and anchored in their offices, and plaguing them with frustratingly poor performance due to network latency and the inevitable outages that occur when connected to the Internet. The fact is, workers today bring their laptops with them everywhere--the meetings, customer sites and to their homes, etc.--and they need to be productive no matter where their physical location may be.

A new kind of application architecture is required to optimize the capabilities of today's mobile computing platforms. An architecture that enables workers to use applications at locations other than their desk at work. An architecture that fully utilizes the storage capacity and processing power on today's notebooks, while truly mobilizing workers by eliminating persistent connectivity as a requirement. What's needed is architecture to support occasionally connected use.

Requirements for an Occasionally Connected Architecture

The first requirement for creating an occasionally connected architecture is, of course, to distribute the business logic. Anyone who understands client/server architectures also understands that distributing business logic is nothing new. And in the context of occasionally connected computing, it is relatively simple to do.

The second requirement of occasionally connected architectures is the hard part: distributing data. This is a new problem and for the most part, a problem that most application architects have yet to completely figure out.

Distributing data may not seem like such a big deal, until one considers the realities of occasionally connected computing. When persistent connectivity is no longer an underlying assumption, applications must be built to rely upon local resources. But with applications and data deployed across all of your end-users' mobile machines (and with those users drifting between connected and disconnected mode and using their applications unimpeded in both modes because connectivity becomes a "background" concern, not a requirement) how does one keep all of the data in sync? How does one prevent a nightmare of constant conflicts as users make thousands of changes to their data in disconnected mode during their workdays?

One approach would be to use XML caching. However, this is only suitable for "lightweight" applications that use small data sets. This approach breaks down when you try to deploy enterprise applications on mobile platforms. For example, you can't move an entire aircraft technician's knowledgebase onto a mobile platform using XML caching. Additionally, there is no support for structured relational data using XML caching, which again is a barrier to deploying true enterprise applications on mobile platforms.

Indeed, if one wants to move a knowledgebase onto a mobile device ... one should simply move the knowledgebase onto the mobile device. With the price of storage now below $1 per gigabyte, it is entirely economical to do so. The problem is, what happens to the data once it is distributed across multiple mobile platforms and mobile workers start using it in disconnected mode? When a technician enters a new case into the knowledge base, how do other workers gain access to it? And how do you avoid the "nightmare" scenario mentioned above, where everyone is working off the same application, but with radically different data?

The answer lies in a powerful technology known as bi-directional heterogeneous data replication.

Realizing the Potential of Occasionally Connected Computing

Initial attempts at mobile application deployment have shown that traditional one-way data replication tools are suitable for updating a centralized database with information gathered in the field, but little else. This relegates mobile applications to being rudimentary information-display or capture devices, rather than true disconnected versions of the same enterprise applications. And it certainly does not support the type of application described earlier: occasionally connected aircraft maintenance.

The new breed of bi-directional, heterogeneous data replication technology available today solves many of the tricky problems mentioned about distributed databases. By providing full read-write bi-directional replication capabilities, this technology makes it possible to deploy enterprise applications on mobile devices and to enable full access to application data, even in disconnected mode. In the background, there is a replication network that communicates any changes to data to all of the other databases. If a database is not online at the moment, it will be updated when it does come online. This, in effect, creates an application architecture in which there can be thousands of dynamically linked databases, all communicating change to one another as needed. When implemented, this powerful capability provides "network transparency" to the user, as the application is free to roam between connected and disconnected modes without affecting functionality.

This capability changes the role of the Internet in application architectures. It relieves the Internet from having to do something it is not good at--providing flawless high speed connectivity to distant data centers--and instead changes the role of the Internet to something it's quite good at: communicating occasional changes.

To illustrate the power of the occasionally connected architecture, following are two real-world examples of occasionally connected computing in action. These are based on real deployments:

Aircraft Maintenance: A large jet engine manufacturer wanted to make its service technicians more efficient by freeing them to service aircraft wherever they may be located--on the runway, in remote airfields, etc. Historically they could only service planes when they were in the hangar, because that was where the centralized maintenance application was located. And when their work on the jet engines was done, they would often sit idle while other workers performed maintenance on other parts of the plane.

The manufacturer wanted its highly skilled jet engine technicians to be able to service more planes in the average working day, which meant freeing them to bring their maintenance application with them wherever they went. They also wanted to eliminate the connectivity problems at remote airports, where technicians often suffered from frustratingly poor application performance.

The company achieved its mobility goals by using bi-directional replication technology to decentralize its maintenance application. Now, instead of being tethered to a centralized system in a hangar, technicians have their entire maintenance application, along with the entire service knowledge base, on their notebook computers. This means they can service more jets each day, which, obviously, means a more efficient enterprise.

Retail: Occasionally connected computing architectures do not just apply to mobile applications. They are also highly desirable for traditional desktop applications, because they provide superior performance and availability when compared to centralized architectures.

For example, a regional retail chain wanted to eliminate connectivity as a requirement for its point of sale systems. Network outages and anomalies often brought systems down, or slowed them down, which compromised customer service and per-store revenue. The company used bi-directional replication teleology to decentralize its point of sale systems, and instead create a broad network of dynamically linked point of sale systems.

Today, the systems never go down. Even when network connectivity is out, workers can continue to process customers, check inventory at sister stores, and do anything they normally do with the system. Customer service can never be compromised by slow or unresponsive systems. This means that the point of sale system has been eliminated as a "point of failure" in the chain's operations--no lost sales, and no lost customer goodwill can be attributed to system problems.

These are just two examples of the power of the occasionally connected computing architecture. One can imagine any number of business applications that would benefit from support for occasionally connected computing, eliminating the application's requirement for persistent network connectivity.

And, as more and more applications are decentralized, end-users will develop new "pain thresholds" for application performance and availability. It will no longer be acceptable to have applications stop with no warning or Web pages to fail to paint. Users will expect the same performance and availability from their enterprise applications that they get from their desktop applications.

Furthermore, occasionally connected computing architectures will enable companies to realize substantial productivity gains by deploying applications that are always up and always available when workers need them, where they need them.

www.peerdirect.com

D. Britton Johnston is chief technology officer at PeerDirect Corporation (Bedford, MA)