Open Standards: The Base of Modern App Architecture - Ideas2IT

Open Standards: The Base of Modern App Architecture

Share This

A huge wave of digital transformation started in the mid-2010s and took over all business sectors. Businesses rebuilt their legacy systems to leverage modern technologies to offer better services to their customers. While we all are still in the midst of the first wave, the business world stands at the brink of the second wave of digital transformation. This wave would be more focused on strategy, architecture, and interoperability. In the past few years, the role played by enterprise applications in driving businesses has increased. Customers are complimenting this trend by preferring to use digital devices to access your business’ services.

These rapid changes brought about a revolution in how businesses leverage technology to deliver the best customer service. This paved the way for a modern application architecture along with a new approach towards problem-solving.

What is Modern App Architecture?

Application architecture today is very different from what you would come across in legacy systems. To explain it in one sentence, modern-day architecture is based on event-centric thinking and legacy systems are usually built on data-centric thinking.

To further understand event-centric architecture, let us consider an example. It is 10 pm on a rainy day in 2005. You are working late at the office. You have decided to call it a day. You step out and look around for a cab to take you home. You wait around for 15-20 minutes for a cab to pass by, and as it is raining, and waiting any longer isn’t helping. So, you pull out your fancy flip phone and go online to search for a cab service company. After about 10 minutes of effort, you get their number, dial them, and dial yourself a cab to take you home. Millennials and Gen-Z, who never knew that era would wonder, “Gosh! Why wouldn’t I just call myself an Uber?” Cut to the present day and anyone with a smartphone would be able to book a cab with relative ease. 

If you compare how one booked a cab in 2005 viz a viz how it is done today on Uber, it’s easy to see the difference between event-centric and data-centric architecture. Let me elaborate.

The 2005 web application, let’s call it X has all the contact details of call-a-cab service providers. You go online, get the contact number (data) and dial a cab. So, you basically used the application database to get the data you needed to solve your problem. This is a classic example of a data-centric app architecture.

Now, if you look at Uber, it also has a similar kind of database with contact details of registered cab drivers. But the app does not stop with just giving you a database and expecting you to take things forward. The application detects your location and matches you with cab drivers nearest to you. It also prompts the driver to pick you up. The application collected the relevant data, processed it, and solved your problem. The application reacted to the event of the availability of cabs and made your life convenient. This is an example of an event-centric app architecture.

All modern applications are built with event-driven business logic in mind and this modern architecture is called event-driven architecture.

Why event-centric applications?

As we all are aware, during the initial advent of computers and the internet, all applications were focused on data. The app architecture and logic revolved around the sole aim of preserving data and making it accessible to the end-users. Data-centric architecture was effective when the size of datasets was manageable, and data extraction, as and when required, was simple.

As the datasets got bulky, data processing began to get more complex. Data storage and management needed a separate solution. At the same time, digitization was no longer limited to a particular field of work or segment of the office. Today, right from the end customers to the back office, all are linked through digital chains to automate operations. Also, processing data and reacting to events to offer services became crucial for enterprises than merely accumulating data on the event.

For example, Zomato used to be an application on which you could look up all the restaurants around you and the cuisines you could try. But, with time, it started letting you book tables and order food right from the application itself – it transitioned from a data-centric architecture to an event-centric architecture.

Enter: Open Standards

The socket you plug your device into, the USB port for your flash drive, the WiFi signal that your devices connect to – are all examples of open standards. It means that these are globally accepted standards that all manufacturers adhere to and ensure interoperability.

Similarly, there are open standards for information technology. To be precise, there are three types of standards in information technology:

  1. Proprietary standards
  2. Open standards
  3. Defacto standards

Proprietary standards, as the name goes, are software formats that are owned and maintained by a particular organization and are not free to use for all.

Open standard software is free to use for all and used by most applications that exist today. Open standard software follows all the guidelines laid down to keep technologies “open” and allow free sharing of all data types with perfect fidelity. Open standards help prevent vendor lock-in and thereby enhance interoperability across applications. The Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) are two organizations that set these standards for software technologies using open and well-documented processes. These standards keep changing as new technologies emerge. For example, the USB Type-B is presently an open standard for USB cables, and soon, the USB Type-C may take its place, considering its popularity today.

A few examples of open standards are:

  • JSON for the transfer of structured data
  • XML for validation of structured data
  • HTTPS and HTTP for requesting content on the web

There are a few rules that a software, technology, or coding language has to follow to be accepted as an open standard.

PrincipleExplanation
AvailabilityOpen standards are available for all to read and implement.
Maximize end-user choiceOpen standards create a fair, competitive market for implementations of the standard. They do not lock the customer into a particular vendor or group.
No royaltyOpen standards are free for all to implement, with no royalty or fee. Certification of compliance by the standards organization may involve a fee.
No discriminationOpen standards and the organizations that administer them do not favor one implementer over another for any reason other than the technical standards compliance of a vendor’s implementation. Certification organizations must provide a path for low or zero-cost implementations to be validated, but may also provide enhanced certification services.
Extension or subsetImplementations of open standards may be extended, or offered in subset form. However, certification organizations may decline to certify subset implementations and may place requirements upon extensions.
Predatory practicesOpen standards may employ license terms that protect against subversion of the standard by embrace and extend tactics. The licenses attached to the standard may require the publication of reference information for extensions, and a license for all others to create, distribute and sell software that is compatible with the extensions. An open standard may not otherwise prohibit extensions.
Open standard rules by Bruce Perens

There are some proprietary standards that do not follow the rules mentioned above but are still used as a universal standard. They ended up becoming so popular either due to their effectiveness and usefulness or due to the lack of an alternative or both. They are called the De Facto Standards. The Adobe PDF document format .pdf and the Microsoft Office file formats like .doc, .xls, .ppt, are some of such de facto standards.

What makes Open Standards so crucial for event-centric architecture?

As explained before, open standards are universally accepted standards that all applications use to enable interoperability.

Let’s go back to the example of booking a cab using an application. When you open the application, the app will first use your phone’s GPS services to pinpoint your location. The app will then place your GPS coordinates on a map to determine your address. It will use your phone’s voice input or text input functions to let you enter your destination. Once it collects this data, it will look for cabs closest to your GPS coordinates. Using the navigation functionalities of the map application, it will determine which cab is likely to reach you at the earliest, and then it connects you to the driver.

Now, the app you are using to order a cab should be able to leverage the GPS of your phone, send and receive data from Google maps, and also connect to the driver app on the other end. So, when the cab booking application was built, it was designed in a way that it could communicate with other applications as well as your device. All this wouldn’t have been possible without the interoperability that open standards bring in.

What if the maps application refused to use open standards or the cab booking application refused to share data with a third-party application. If there are no open standards, we would end up with isolated proprietary applications, all separated by incompatibilities. The applications would be able to collect data but would not be capable of processing it efficiently to get the desired result.

This would be like the standard railway gauge is different in each state. The process of transporting cargo from one city to another within the state is quick and simple. But, when it comes to transporting cargo to another state, it would take a lot of loading and unloading efforts to get it done. The same goes for software systems. Open standards are more like standardized railway gauges.

In the absence of the interoperability offered by open standards, we would have software systems that could have excellent capabilities of enabling automation and delivering the desired results. Still, those capabilities would be limited within their own arena, forming separate islands of automation. The systems can keep evolving and building new features and adding more automation, the scope of which would be limited to the island of automation. Such islands of automation would eventually restrict global-level interaction. This is fine if you plan to build an application for a specific group of people operating within a single virtual island itself—for example, an application for internal communication and collaboration of employees of an organization. But in the case of a business application, that may not be feasible. Also, if all software systems turned into islands of automation, the internet would just have several small-sized networks interacting only within themselves. The World Wide Web (WWW) would become Disconnected Worlds on the Web (DWW)!

Open Standards Open Minds

A lot of us may remember those old flash player-based websites, games, and video players on the web back in the early 2000s. The flash player has lost the favor of modern browsers. As of 31st December 2020, Adobe has stopped support for the flayer player and completely retired it.

98% of enterprises used to rely on Flash Player in 2010. But, it is proprietary software and Adobe had the sole authority to its future enhancement, pricing, etc. Its limited interoperability caused tech giants to start looking for alternatives. With time, it was replaced by HTML which is an open standard technology. All enterprises that used the Flash Player back in the day replaced it with HTML web technology. When this transition happened, most organizations were not aware of the benefits that would follow. They merely upgraded their applications to stay abreast with the changing times.

Enterprises today are constantly looking for ways to offer their best services to customers across all platforms. That means their applications should have the best customer experience as well (CX). Your organization may have the capabilities to engineer the best application, but the only way to unlock the full potential of your enterprise application is to build it with open standard technologies.