Tuesday, July 26, 2022

The iPhora Journey - Part II - Domino, the Little Engine that Could

The iPhora Journey - Part I  - Reimagining Domino

We have been working with Notes and Domino since 1995, back when it was still called Lotus Notes. The name "Domino" did not come into the picture until a few years later when the Notes server was renamed. Our company, ReCor, provided computer-based training Notes and Domino, and our course offerings included training for application development, administration, and end-users. After the early 2000's, demand for new installations of Notes and Domino began to decline, along with the demand for training. 

At this point we decided to start a new company, one that focused on IT Support and application development, but with an emphasis on Domino. This is how Phora Group began. Our initial problem was that all of our customer contacts were for training, and while the ReCor customer base was extensive and included many very large companies, those customers were already supported by either internal staff, IBM, or IBM Business Partners. Therefore, our focus had to be on new customers and figuring out what new customers needed.

Our new customers tended to be smaller than what we were used to, but there were many of them and we did not have to contend with internal IT and development staff. We created a digital workspace -- although that term did not exist then -- called the Integrated Business Framework and this was a Notes client-based solution. It included a number of standard modules, including CRM, sales order, inventory, technical support, project management, workflow, and others. As our customer base grew, we added more modules to provide support for an ever-increasing range of business functions.

Over time, support and scalability became a problem because each new module meant changes to the design of multiple databases to accommodate the new features. This is because all modules had to be selectable from within any other module. We resorted to using features like embedded views, which soon became a nightmare to manage.  Moreover, the Notes client is something of a UI beast, and it is extremely difficult to create the kind of user interface that non-Notes users expect. Customers had already become familiar with UIs from other software and even from web applications. For a long time, Chris Blatnick maintained a blog called "Interface Matters" where he described different approaches to improving the look and feel of applications running on the Notes client.


During that time, we created some exceptional Notes client interfaces like the one above, but each one required a massive amount of work. With traditional Notes development, the UI elements and business logic are contained within the form and the data is stored in a document, and the integration between form and document is so complete that it is almost impossible to conceptualize one without the other. Not only that, but there is no centralized place within a form for the UI and logic. They could be in a set of Action buttons or hotspots or agent calls or even in events, such as the QuerySave event. Some code might run on the client and some on the server.

With the rise of web applications, XPages was introduced as the preferred method to take Domino applications to the web. However, XPages was still dependent on complete integration between form and document, an approach that became more and more cumbersome to maintain.

This binding between the form and the data may have worked in the Notes client, but that is not how modern web applications are designed and the linkage makes it extremely difficult to apply the latest web technologies to Domino. It became clear -- at least to us -- that the link had to be severed in order to move forward.  Separating the form and the data allows the developer to more easily create the UI and manage the data. It also means abandoning the Notes client. For us, all applications would now be web applications. This was a watershed moment.

We started by experimenting with an API-driven model rather than the client/server model used with the Notes client. All interaction between the web client and Domino server would be through server-based agents. This was easier to maintain and made the data more manageable. 

This leads to the obvious question of why use Domino if the focus is only on web applications? There are plenty of platforms out there that are faster, newer, more web-centric, and in many cases open source. For example, you could design a web application using a combination of Nginx/Express/Node/MongoDb. So why use Domino? 

First, it is important to look at the essential components of a web application:

  • User and Data Security
  • Web Engine
  • Business Logic
  • Database

As we mentioned in part 1 of this blog series Domino excels at:

  • Data Security
  • Master-to Master Replication
  • Integrated Web Application Server

If we went with the Nginx/Express/Node/MongoDb combination, there would be no built-in user security or data security. It would fall upon us to create it. With the current climate of hacking and malware, we would need an entire staff to develop and maintain just the core security features. With Domino that core security responsibility is handled by HCL, which means that we don't have to spend precious resources creating and maintaining that security infrastructure,. Not only that, the Domino security model is already highly granular, including user-level, database-level, document-level, and even field-level security. No competing web database technologies have anything similar.

Domino also includes an integrated web application server, which frees us from having to create all the code that is necessary to connect the different components: web server to security infrastructure to database. Domino brings all that is needed into one cohesive platform that can literally be run on even the smallest of server. Because of Covid, we downsized our offices and the server box pictured was our operational Domino server. In many cases, a single-server Domino web application is fully sufficient for a small businesses. It represents a complete solution.



If you have ever shopped for a house, you would have probably heard the phrase "good bones" used to describe a certain property. This refers to an older house that may have some appearance/image issues but is solidly built. Well, Domino is like that. It may not the first choice that springs to mind for a web platform, but it has great bones. It is the little engine that keeps on chugging.

So, is it possible to take what Domino has to offer and transform that into a modern web application platform? Can we extend the Domino access and security models to provide an even more secure platform focused exclusively on web access? Could we implement a new vision for Domino, a vision that includes:

  • Web API-based with JavaScript SPA
  • JSON-based application engine
  • JSON-based database
  • Flow-based processing engine
  • Graph API
  • Security fidelity even higher than what Domino provides
  • Portable to other platforms

So that was our quest. Taking Domino from the Little Engine that Could to the Little Engine that Can.

Next time, The iPhora Journey - Part 3 - Creating an Integrated UI Framework.


Tuesday, July 19, 2022

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

Thursday, July 7, 2022

CollabSphere 2022, October 19-20, 2022, "Our Community, Our Stories"

 


I am please to announce that CollabSphere 2022 will be held October 19-20, 2022. Registration, sponsorship and abstract submission will start the week after next. New for this year is the addition of the CollabSphere Discord channel where the conversation and learning starts before and after the conference. All attendees are invited to join us. We will have online activities on Discord so make sure you join. The conference is about you and your story and we want to hear your story. More about this in the near future. The cost for CollabSphere 2022 will be $150 USD with a discount of $150 USD for the total cost of $ 0 USD.

Thanks again to the folks at Prominic.net for hosting our web site.

https://collabsphere.org

CollabSphere 2022 Presentation: COL103 Advanced Automation and Cloud Service Integration for your Notes/Nomad Applications

Our presentation for CollabSphere 2022. Learn how to quickly add workflow automation into Notes/Nomad applications using No-code tools that ...