The Story of Open Standards and the Subsequent Evolution of IT Interoperability
Even with so much proprietary software in the world, open standards are still a key part of futureproofing and easy integration.
Join the DZone community and get the full member experience.Join For Free
In my previous blog, I discussed the importance of open standards while choosing a tech stack while developing your enterprise application. But the idea of open standards for IT is still a bit new to many people. So, here, I discuss how open standards evolved and why they are so important now.
“Open standards for information technology” seems to be a new term that everyone is talking about recently. But, as a matter of fact, open standards have been here for a long time. The socket and the plug that you use for charging your electronic devices, USB cables that fit perfectly into the given slots, or the WiFi signals that your devices connect to — all of these adhere to open standards. Standards are everywhere, whether you acknowledge them or not.
In the case of software, there are 3 kinds of standards — proprietary standards, de facto standards, and open standards.
As the name suggests, proprietary standards are the ones that are “closed” — those which are compatible only with a few specific configurations.
Open standards are the publicly accepted standards that make any software application “open.” These standards are a set of specifications that are publicly available and developed by an open community and affirmed by a standards body, namely, IETF and W3C.
There are a few principles laid down by Bruce Perens that open standards have to follow.
There are a few proprietary standards which do not follow these above-mentioned principles but have become popular over time because everyone just happened to use it, probably because it was implemented in a product that had significant market acceptance or there was no other alternative to it initially. These standards are called the de facto standards. The Microsoft Office file formats like .doc, .xls, .ppt, and the Adobe PDF document format .pdf are some of such de facto standards. The major problem with a de facto standard is that it is controlled by a single vendor who can change it whenever the vendor decides to do so.
During the years when software technology was in the initial evolving phase, proprietary standards easily turned into de facto standards due to a lack of similar alternative technologies. But, with time, the software market grew and got more competitive. Gradually multiple software technologies were developed by different companies with similar functionalities. That, in turn, gave rise to proprietary or custom systems isolated by incompatibilities. This kind of software systems may have excellent capabilities of enabling automation and delivering the desired results, but they become islands of automation. Addition of features and expanding the scope of automation within the system itself is a cakewalk. But, when it comes to integration of technologies belonging to a different system on another island of automation, it is either a tedious task or not possible at all.
Having an island of automation restricts global level interaction, which is fine if you are planning to build an application for a specific group of people operating within that island itself, but in the case of a business application, that may not be feasible. Also, when there are several islands of automation all around the internet, the result would be the formation of small-sized networks interacting within itself all the time. This would be like the distance between the rails is different in each state. Transporting cargo from one city to another within the same state is very fast and easy, while it is difficult to transfer it from one state to another.
Just like the distance between the railway tracks is the same everywhere and is treated as a standard to enable seamless transportation of goods from one station to another, there are standards for software systems, too. Software standards enable systems to easily work with each other and transfer data seamlessly.
Therefore, to facilitate interoperability among software systems running over the internet, technology leaders, and organizations around the world came to an understanding and laid down voluntary standards that can keep any software technology “open.”
Now, one may ask how a business benefits from adopting open standards and thereby developing a business application that is interoperable.
Why Modern-Day Applications Need Open Standards
In the present scenario, for any business application to offer a complete service, it needs to have several third-party integrations. An isolated stand-alone application will not be able to do the job. For example, consider a taxi booking application that people access from their smartphones. In order to book a taxi, the application needs to detect your location by accessing your phone’s GPS. Then, it needs to locate you and give the driver the directions to your location. This functionality of navigation is added to the application by integrating a mapping service — say, Google Maps. For enabling easy payments, integration of a payment gateway is required.
Avoid Vendor Lock-in
When one application needs to work with diverse systems having services distributed across multiple domains, there is a need to have a connecting link for the swift transfer of data. Application Programming Interfaces (APIs) make this connecting link possible. Here is where interoperability steps in. If your business application adheres to open standards, there are standard based APIs that one can use to connect with any system. But, if your application follows proprietary standards, the choices are limited and one needs to develop custom APIs for the same. This leads to vendor lock-in. You are stuck with using a system owned by a specific vendor. Due to this, the shortcomings of that systems affect the efficiency of your application as well. Instead, building an application with open standards means you are not tied down by any vendor or its shortcomings. If your application is interoperable, you can easily avoid vendor lock-in.
A business application generally needs to be so designed that it is compatible across various systems and varied screens. If the application follows closed standards, this is only possible when each compatibility is individually addressed. One may need to design extensive proprietary interfaces for enabling compatibility with each system thus, limiting interoperability. On the other hand, open standards will pave way for a fully interoperable business application that has a simple plug and play set up for all systems across all devices. Thus, you save a lot of man-hours spent on developing custom interfaces or offering extensive integration services to customers.
By saving man-hours, you reduce the time to market. Again, when your application is up and ready in a short time span and integration service needs are non-existent, you also save a lot on development costs. With low development costs and no vendor lock-in, the total cost of ownership of the application is low as well. In the present-day, there are new technologies emerging at a very fast pace. Taking this into consideration, it would be preferable to have an application that can readily catch up with all the advancements in technology. This is possible if the business application is interoperable. So, by adhering to open standards, one can futureproof the business application.
Above all, by having a business application that is interoperable, you facilitate broader adoption of the application. It also eliminates the possibility of the application failing in the market due to lack of compatibility.
All these benefits of interoperability clearly depict how significant open standards are while developing a business application. That is why software developers today stress so much on adhering to open standards while developing enterprise-grade applications.
What You Can Do as An Enterprise Owner
If your enterprise is dependent on a legacy application for all its functionalities, it more likely to not follow open standards. To modernize your application, you have 2 options:
- You can choose to rebuild your legacy application from scratch and modernize it completely thereby making it flexible and scalable enough to meet the present day requirements.
- You can choose to use a low-code app development platform that allows reuse of core business logic and modernizes other portions of the legacy app using open standard technologies out-of-the-box. This gives you a quick start and a minimally invasive way to modernize enterprise applications.
Considering the hurdles faced during enterprise app modernization, it is advisable that you weigh the pros and cons of both the alternatives and make a wise choice.
Opinions expressed by DZone contributors are their own.
Transactional Outbox Patterns Step by Step With Spring and Kotlin
The SPACE Framework for Developer Productivity
Implementing a Serverless DevOps Pipeline With AWS Lambda and CodePipeline
Essential Architecture Framework: In the World of Overengineering, Being Essential Is the Answer