Skip to main content

The iPhora Journey - Part I - Reimagining Domino

Domino, which is currently owned by HCL Technologies, is one of the most enduring application platforms ever built. It owes its existence to Ray Ozzie, who was heavily influenced by his use of the PLATO system, a pioneering interactive/educational network at the University of Illinois. The first version of Domino (then called Lotus Notes) was released in 1989, and Domino applications from 1989 can still run on the newest version (12.01). You can build Domino applications for deployment on the Notes clients, mobile devices, or Web browsers, and for programming and customization, you can use Nodejs, Java, LotusScript, and Formula language, or any combination of them. Regardless of which programming languages are used, a typical application is usually represented by a single Domino database.

However, the IT landscape has changed significantly since Domino was a dominant player in the market. The migration to web and mobile applications using cloud-based solutions has led to the steep decline of traditional client-server architectures. This, combined with the rise of no-code / low-code development tools for web and mobile applications, has made Domino more of legacy system than a cutting-edge platform. Easy integration with external services via APIs is now a must, and deployment time is now measured in minutes, not days. Companies are implementing digital workspaces, allowing users to browse through the offerings in an application store, select, pay (if needed) and deploy the application to their workspace all in less time than it takes to get a cup of coffee.

Over the past few years, HCL has made a number of great improvements to the Domino platform, which can now be deployed on Docker and Kubernetes. However, the application development process, whether for Notes clients or Web browsers, really has not changed much at all. Fifty percent of all Domino development still centers around Notes client applications. This is fine for the existing Domino community, but having to install a large client is a very hard sell to new customers.

If we are to reimagine Domino, the first step is to identify the things that Domino excels at. These happen to be the same things that Domino did well from the beginning:

  • Data Security
  • Master-to-Master Replication
  • Integrated Web Application Platform
  • Multiple programming tools with tight integration to data stores

As a fully integrated application server, Domino provides an advantage in ease of deployment and manageability. Of course, this can also be an Achilles heel when it comes to upgrading to the latest versions of critical technologies like Java. The tight integration makes it more difficult to upgrade the individual components that make up Domino.

The next step is to identify new features and capabilities that are desirable to customers today:

  • No-code/low-code development
  • API-driven platform
  • Web and mobile client support
  • Easy private/public cloud deployment
  • App store delivery
  • Easy integration with external services

These are the features that are needed in order to keep Domino relevant in the future. Competitive database solutions, such as MongoDB, RavenDB, and Couchbase, all interact well with a variety of UI and server technologies to achieve these capabilities, while Domino struggles with such integration because of difficulties upgrading to the latest versions of critical components or simply lacking support for certain capabilities. By the way, as NoSQL solutions, all of those database products owe a debt of gratitude to Domino, which pioneered that technology in the corporate world.

This is part one of a fourteen-part series describing our long journey in redefining the Domino platform and how to use it to meet the expectations of today's customers -- specifically new customers. Our focus is totally on what new customers are looking for, not what existing Domino customers expect.

Domino may not be the ideal platform for a modern web application, but at least it provides a solid foundation built on security, data storage, and replication, all nicely integrated. Like all technologies, Domino has many shortcomings. The questions we had to ask ourselves are these: Do the shortcomings outweigh the benefits? Are there workarounds to mitigate the shortcomings, or even turn them into advantages? How can we apply industry best practices for web design to the existing Domino architecture? During this journey, these questions and many others came up again and again.

We discovered early on that it was necessary to abandon all existing notions of what an application is in Domino. The traditional Notes client application is simply not compatible with modern web technologies. A new design approach and a new application definition was needed, one that focuses on web/mobile deployment. With that in mind we started our journey.

Next time, Part II - Domino the Little Engine that Could

Labels:

Comments

Pradeep Bhat said…
Waiting for the next part...
July 19, 2022 at 9:45 PM
Post a Comment

Popular posts from this blog

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select
Post a Comment
Read more

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a
Post a Comment
Read more

The iPhora Journey - Part 4 - JSON is King - The How

  The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework The iPhora Journey - Part 4 - JSON is King - The Why The iPhora Journey - Part 4 - JSON is King - The How As we mentioned yesterday, in reimagining Domino, we wanted Domino to be a modern web application server, one that utilized a JSON-based NoSQL database and be more secure compared to other JSON-based NoSQL platforms. A Domino document existing within a Domino database is the foundational data record used in iPhora, just as it is with traditional Domino applications. But instead of just storing data into individual fields, we wanted to store and process the JSON in a Domino document.  However, text fields (AKA summary fields) in Domino documents are limited to only 64 KBytes, and that is a serious limitation. 64 KBytes of JSON data does not even touch what the real world typically transfers back and fo
Post a Comment
Read more