Browse DevX
Sign up for e-mail newsletters from DevX


The Time Has Come for the Decentralized Application Architecture : Page 3

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

How to Decentralize
To date, companies have attempted to decentralize in the following two ways:
  • Partitioned data sets—Perhaps the easiest approach to breaking the dependency on a centralized database is to break that database into multiple pieces. Organizational requirements may lead to this approach and often necessitate re-centralizing the database in the form of a reporting database or warehouse to allow reporting for management. In fact, many organizations evolve into this model without necessarily planning for it, but it results in multiple systems that tend to drift apart over time. Web services allow these "drifting systems" to remain connected, but at the cost of creating applications that are even more dependent on the network and even more likely to be unable to run disconnected.
  • Brute-force synchronization—Today, the next generation of an application often promises some sort of support for mobile access. Nearly all mobile solutions today are plagued by several flaws, including hand-built and fragile synchronization code and a dumbed-down, limited-function flavor of the application. This type of brute-force synchronization is reinforced by the variety of mobile devices, each suggesting a new approach.
  • Bi-directional Replication for Distributed Databases
    Today's new heterogeneous bi-directional replication technologies provide a much better approach to decentralizing. They provide a powerful way to distribute databases across the enterprise. Because these technologies are available as general-purpose software, they enable a new approach to building distributed software solutions. Their heterogeneity enables companies to use any combination of databases. Because they are bi-directional, they enable companies to create redundant architectures populated by replicated systems.

    The products featuring heterogeneous bi-directional replication technology can eliminate the manual programming and integration efforts that are so common when building complex synchronization infrastructure. Once a product offering supports hundreds or thousands of deployed sites, software developers can rapidly deliver applications that support distributed deployment (see Figure 1) .

    Figure 1: The Distributed Enterprise

    Often software vendors find that once they build support for distributed deployment, they are able to address a much larger marketplace and provide competitive differentiation by delivering a new class of applications.

    This new class of distributed database applications does not eliminate the need for large centralized databases. It provides a robust environment in which data can be distributed across an enterprise, providing end users with better quality of service and eliminating the dangerous single point of failure inherent in centralized database application architectures.

    The Early Adopters
    Retail is one of the early areas of adoption for this type of replication technology. Instead of centralizing point-of-sales (POS) systems and polling the systems, retailers are deploying distributed databases so all of their POS systems are local, but dynamically linked. This means that even if the network goes down, the retailer can continue conducting business as usual: capturing customer information, processing transactions, and even viewing sister stores' inventory.

    Field force automation is another area of early adoption, especially in the area of field maintenance for complex systems because it is so data intensive. Service systems can be built for devices like jet engines, providing service technicians with direct access to complete history, specifications, and even expert systems that help diagnose and perform complex repairs—regardless of whether the system technician has a full-time network connection.

    Application and business requirements will often limit the amount of time a worker can operate without network connectivity. For a sales force selling very large and complex products, configuring an order directly with a customer may be an important requirement, but confirmation of acceptance of that order may need to wait until it has been transmitted to the central system. An application may need to account for this change in order-processing behavior, and once it does can provide a significantly improved sales experience over a multi-step review process necessary when a salesperson must return to their office to do final configuration of an order.

    In the healthcare industry, application developers are finding they can employ devices on existing desktops to provide superior authentication solutions at very low cost, supporting legislated security requirements even at individual doctors' offices.

    Let's Not Do the Time Warp Again!
    As organizations gain experience with distributed deployment, they discover secondary benefits that are often just as valuable to an organization as the improved quality of service for end users. For example, a distributed system that has not only applications but also data maintained locally provides a level of resilience not possible with traditional application architectures. Properly deployed applications can survive virtually any failure—including even the loss of the centralized database—for an extended time without any loss of service to most end users.

    It's time for business applications to get out of the centralization time warp. Developers should take a long, hard look at their applications and evaluate the benefits that might be delivered by distributing both execution and data. Would end-users benefit if your applications could continue to operate disconnected from a central database? Do you need to provide mobile workers full-function applications but see no way to do it in a world dominated by centralized databases? Can your business process be modified to provide a better experience for a customer and support distributed processing? Do new low-cost authentication and encryption technologies provide adequate security for your data? Examine your application architecture, and you may find that the assumptions you have made about data are no longer valid.

    In a world where advanced bi-directional heterogeneous replication technologies let you move data to the user, and keep that data synchronized without writing complex application code and without having to build a reduced function application, the centralized model seems as archaic as its forebear: the mainframe architecture. This concept of distributed data may seem new today, but technology evolution, combined with market opportunity and competitive pressure, will make it commonplace tomorrow. And at that point, end-users will expect all their critical applications to run disconnected from the network.

    D. Britton Johnston, Chief Strategy Officer at PeerDirect, holds a wealth of enterprise database and open source expertise. He has more than 18 years experience in delivering software products to enterprise customers. You can reach him at britt@peerdirect.com.
    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