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.
Comments