Browse DevX
Sign up for e-mail newsletters from DevX


The Time Has Come for the Decentralized Application Architecture

The business application architecture many companies use is as archaic as the decades old centralized mainframe model. Companies would be better served by a decentralized architecture in which their applications and databases are distributed across regional locations and local devices.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

usiness applications today are stuck in a time warp. Web-based applications offer ubiquitous access, but the business application architecture many companies use is still locked into the decades old centralized mainframe model—a model where end-users often access a single instance of the application and almost always access a centralized corporate database.

Applications have moved from the client/server paradigm, to the multi-tier architecture, to Web-based GUIs, to application servers, to open-source platforms, and now are embracing Web services. Yet all of these changes have left the database layer of the application architecture largely untouched.

This is why, for example, a sales rep in Tokyo might have to connect over the Internet to a sales force automation application in New York to get information on a customer located half a block away. If the database administrator (DBA) in New York has taken down the database for some midnight maintenance, the sales rep in Tokyo—who's in the middle of her workday—is back to writing notes on paper for later data entry into the application. It's just like the 1960s.

Even when the database system in this example is up, the sheer distance to a server halfway across the world would cause delays, making the user experience poor. On top of it all, the investment her company made in providing sales staff with powerful laptops and PCs is largely wasted because the centralized application architecture uses these platforms as nothing more than browser-based terminals—just as mainframe architectures used dumb terminals.

All of this raises a number of questions. Why do we continue to lock applications into a centralized database model? When you take an inventory of your critical applications, can they run without connectivity to a centralized database? Are users forced to work around applications that they cannot run disconnected? Is the sales rep in Tokyo frustrated because she cannot access important facts about her account unless she is online? And even when she is online, is the quality of service she experiences at the level she needs to be successful?

The flaws of the centralized model in this example are clear: both the sales person and the New York-based DBA would be much more productive if the application and customer database were deployed in her local office or on her laptop. Each could do their job without dependence on the other, each would be more productive, and the existing resources of the enterprise would be used more effectively.

The Value of Decentralization
Most business applications are interactive in nature and are a bad match for the centralized deployment model. Whether it's a sales person in the Tokyo sales office, a maintenance technician on an airfield in Paris, or a national retail chain store manager in Omaha, all would be better served by a decentralized architecture in which their applications are deployed across regional locations and local devices, rather than in a distant data center.

Microsoft Word is an excellent example of the value of decentralization. Asking workers to connect to a centralized data center to access Microsoft Word would make no sense. Productivity would take an enormous hit, because people wouldn't be able to use their word processor offline, and outside of corporate headquarters, network latency would be so frustrating that typing pools probably would be reinstated.

The fact that field workers and distributed business locations today must be online and connected to access their applications is equally incongruous. Field workers need access to rich data when they're in the field driving business, not just when they're in the office connected to the Internet. And workers in a retail store in Omaha need to be able to capture customer information, view inventory, and serve customers efficiently, even during network outages. That being the case, why are so many business applications centralized and available only online, when more and more workers are remote or mobile?

The answer is that managing distributed applications in remote and disconnected offices has historically been difficult. Today, however, emerging heterogeneous bi-directional replication technologies make distributed applications practical.

I know what you're thinking: "I'm already doing this today with my Palm and my PC and my synchronization software." Well, you're wrong. The advanced synchronization technology available today can cope with very large databases—databases with hundreds of tables and millions of rows—while ensuring that only data required by the end users is transferred. The technology can preserve complex interdependencies between data (often the basis for business transactions) and restart a partial synchronization effort without skipping a beat. All this can be done with any application. This is a dramatic contrast to the typical brute-force comparison of all data available, as is typical with most first-generation mobile platforms.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date