Moohar Archive

Why Domino?

27th January 2024

I'm a Domino Developer. While that has not been my official job title for some years, I continue to use Domino to develop web applications to this day. It's certainly not a popular option and when it comes up in conversation people are mostly confused. Some had assumed Domino was a retired product no longer in use while others have never even heard of it. I get the impression some of my non-technical friends are still trying to work out what pizza has to do with computers.

In May 2021 to coincide with the release of version 12 of HCL Domino, I started writing an introduction to Domino for those who had never considered it as an application development platform. I was going to explain how I used Domino, what parts I liked and which bits to avoid. But as usual I got distracted, never finished and the moment passed.

With my plan to explore what it would take to build a replacement for Domino, it seems a good place to start would be to complete that post explaining what I like about Domino and make it clear what I'm trying to recreate and what I'm trying to avoid.

What is Domino?

Let's start by clarifying what Domino is. Back in 1989 the Lotus Development Corporation released Lotus Notes. In 1995 IBM purchased Lotus but the branding and the name remained unchanged. In 1996 a server add-on called Domino was released for Lotus Notes 4 which allowed the rendering of Notes applications as web pages. When version 4.5 was released, the web engine was integrated into the server and from this point on the client was referred to as Lotus Notes and the server as Lotus Domino. In 2012 IBM dropped the Lotus branding so it became IBM Notes and IBM Domino. Then in 2019 IBM sold the product to HCL and we arrive at the current names, HCL Notes and HCL Domino.

Personally I tend to drop the company name and mainly use "Domino" in conversation. I use this as it has less stigma and is technically correct for the way I use the product. When I do use the term "Notes", it's because I'm talking about something specific to the client.

My experience

I started using Domino in 2001 when I worked for IBM. I was part of the support team for the internal Domino environment hosting mail and applications for all the IBMers.

This team had no involvement in the development of Domino. We occasionally got a preview of the new version, but mainly we were treated as an internal customer. I stress this to make it clear I had no influence on the direction of the product. In fact since leaving IBM and becoming a paying customer, I've had a louder voice.

I carved out a niche for myself writing tooling and automation to assist with various tasks and projects. However I wanted to do application development full time, so in 2007 I accepted a position in another company as a Domino Developer.

My new role was to develop, maintain and support Domino applications that were used in the day to day running of the business. When I started, most of the applications used the Notes client, however the effort to move these to web based applications had already started and that was part of the reason I was recruited.

I spent the next six years writing web applications in Domino. I'm proud of the work I did and the applications I developed, I've had some very complimentary feedback over the years. It seems the company was also happy and in a misguided attempt to clone me, they promoted me to team leader so I could develop people in addition to applications. Results have been mixed, but development has continued and still in Domino.

Domino's replacement

In 2014 the company I worked for was purchased and integrated into a larger organisation. As you can imagine, this integration caused lots of changes to the IT landscape.

It wasn't long before we migrated email to Exchange/Outlook. The simple document repositories and Quickr sites slowly moved over to SharePoint. Sametime hung on for a while longer but it was eventually replaced by Skype For Business which was quickly replaced with Teams.

The custom applications though were a different story, there was no obvious easy replacement. Not long into the integration it was my job to present an overview of how we were using Domino and what applications we had developed. I got the impression our new colleagues initially dismissed Domino as a poor email system, but were then taken aback at how widespread its use was and how critical it was to our business.

It's not an exaggeration to say Domino was supporting most parts of the business. An abridged list of what we where using Domino for at this time includes:

Including the simple document repositories and typical workflow/approval apps, we had well over 100 Domino applications in active use.

There was however still a resistance to continued use of Domino, partly because at the time IBM seemed to be neglecting the product, and partly because it was unknown to a large part of the wider organisation. My task now was to review alternatives to Domino and detail what a migration plan would look like, or justify why we should continue application development in Domino.

We reviewed open source options, we looked at Microsoft's offerings, we looked at SAP, we looked at other products from IBM, we reviewed half a dozen application builders. We spent two years on and off reviewing alternatives but none of them seemed suitable replacements.

I was honestly eager to escape Domino and all its quirks and frustrations. After years of being told how terrible Domino was I was expecting to find a variety of superior replacements. I was surprised to find out Domino is peerless and replacing it would require a combination of products and bring a whole new set of challenges and frustrations.

Domino, it turns out, is a good application development platform. Like everything it has pros and cons, but its advantages are in areas businesses care about and its disadvantages can be managed. It helped that IBM eventually partnered with HCL and we got a new version but ultimately I feel we stuck with Domino for three reasons: security, being a complete package and cost.

But the UI is so bad

Some of you who have used Notes/Domino before are probably now thinking I've lost perspective, after 24 years I've become brainwashed. I'm guessing you have some real horror stories about how bad Notes is and would be more than happy to tell me how I'm wrong.

The thing is I agree, the Notes client is a mess. It's a user experience nightmare and I actively discourage its use. Fields don't look like fields. It has three different types of tool bar. It has three types of search that don't seem to work properly. There is a fiddly little property box which is essential for some things and hidden when you need it. The keyboard shortcuts are weird. And it's slow and always hanging.

Being an apologist for a few moments, version 1 was released for DOS and OS/2 in 1989. The intention was for Notes to be consistent across all platforms and the standards for GUIs were thin on the ground in 1989, I therefore assume Lotus took the best ideas at the time and came up with their own standards. Then as subsequent versions have been released a key goal has been to maintain backwards compatibility. As almost all the content in Domino is custom applications, the GUI components could not be modernised without giving all the existing customers a ton of work to do, testing and potentially re-developing their apps. So those components stay looking as they did 35 years ago.

The Notes client was probably amazing by 1989 standards. While the prioritisation of backwards compatibility explains some of the odd visuals it does not excuse the lack of progress in other areas. Like why is the property box still so tiny? Why can't I reorder tabs on my workspace? Why can't I map a keyboard shortcut to deselect all documents?

Who needs the client

The good news is you don't need the client any more. As I mentioned before, starting with version 4.5 in 1996, the server now supported HTTP and would serve applications as web pages. The truly impressive thing is this worked with no additional development. Build your app in the designer client as normal and all the forms, views, actions and navigation would be automatically converted to web content by the server on the fly. Low-code web development in 1996!

The problem is the pages looked, and still do, like web pages from 1996 and any user interaction requires a full page load. JavaScript is used but very sparingly and there is no CSS. The technology was impressive at the time, today it looks and functions terribly.

Not to worry, Domino provides various ways to inject your own custom HTML into the pages to make them look and work as modern web apps do. You can do this for small parts of the page and let Domino generate the rest automatically, or you can disable the automatic generation completely and develop the web front end as you would with any other technology. With JavaScript and CSS library support, you have complete control over your user interface and all the goodness of the Domiono back end, which I'll get to in a moment.

This is how my company developed its web applications. We built a library that initially mimicked the functionality of the Notes client but with a modern look. We then expanded that library with a framework for single page applications.

IBM were having similar thoughts because with version 8.5 they introduced XPages. This provided a way to build modern looking single page web applications with Domino as a back end. It was based on JavaServer Faces and used Dojo for the front end. I believe the intent was this would replace traditional Notes client and "classic" Domino web development, however it would require the re-development of applications, so adoption was very slow and the older technology would need to be maintained for backwards compatibility.

HCL has also introduced a variety of ways of accessing Domino without using the Notes Client. In version 10 they introduced a new Domino Query Language (DQL) and added support for node.js to query Domino applications. They have also been slowly expanding on the REST API. The implication being that you can use any front end that talks HTTP.

One of the biggest complaints about Domino, its user interface, can be neatly side stepped by using the web instead. The question remains, why use its backend.

The database

At the core of Domino is a database. The NSF (Notes Storage Facility) is a NoSQL, document oriented, distributed database. It was ahead of its time and offers security features I've not seen available in any of its contemporary rivals.

I find document oriented databases particularly good for supporting workflow applications, replacing paper based forms and in general modelling the kind of data business need to store. It is useful to have the flexibility of a document oriented database in the real world where business requirements are always changing. As a result I find it much quicker for the kind of development I need to do. The rise in popularity of NoSQL databases like MongoDB show I'm not alone in this view.

The strongest feature of Domino's database is its security. This starts with the Access Control List or ACL. The ACL offers seven broad levels of access with options to refine this for specific actions like creating and deleting documents. It supports explicit names, hierarchical names and groups. It can distinguish between servers and users. You can set the access level for unauthenticated users differently from authenticated but otherwise unlisted users. You can map names and groups to roles. It can do a lot.

There is an often overlooked dual level to the ACL, you can classify data and design elements in the application as public, then control access to these separately. This is particularly useful for public facing applications where you might want to give an anonymous user access to the landing page of an application and a few key documents but not the majority of the app.

Where Domino security really distinguishes itself is the document level security provided by the readers and authors fields. Add a readers field to a document and only those users (or groups or roles) listed in that field will have access to that document. You can add as many readers fields as you like and they can be computed or user editable. With this system it's really easy to create a security model for even the most complex scenarios.

A practical example of where this shines is a yearly appraisal system. Each appraisal needs to be seen by the employee, the manager, the local HR team and the global HR director. No two documents in the database are going to have the same list of people who need to access it. In Domino this can be achieved by making the employee and manager fields reader fields. Then adding a computed readers field which works out the group name of the local HR team based on the employee's location. Finally add a computed readers field with a static value of the HR Director role.

Obviously there are ways to do this on other platforms. Relational databases offer row level security but it tends to be role based which would not work in this example. A common approach is to then add the security logic to the application and generate a query to only return the appropriate records. The problem here is if someone were to get direct access to the database, accidentally or maliciously, they could see all the records.

MongoDB has a redact aggregation feature that can achieve something close to what we require. However, as I understand it, this is similar to a query in a relational database and there is nothing stopping the developer from accessing the document collection via another method without that security logic.

My point is that in every other platform I've seen, this type of security is achieved by adding a layer between the database and the user. Every layer is potentially a point of failure and it is not always the case that the only way to access the data is via that security layer. In contrast, Domino has this security baked in at the record level. Readers fields are easily added to a document and once added are always honoured. This makes it very hard for a developer to make a mistake and leave open a path to these documents.

It's not infallible and we still need to audit our work. Compared to other solutions however, once audited you can have a higher level of confidence the data is secure as there are less places it can go wrong. In a business context this is a highly desirable feature and in my opinion one of Domino's killer features. It's one of the reasons we are still using Domino today.

The development tools

Domino applications are developed using an IDE (integrated development environment) called Domino Developer. This sits in a space that crosses both low-code and pro-code development.

Historically, Domino applications were simple and developed using a tool set aimed at business users, what today we would call citizen developers. For example, forms are built in an editor very similar to a rich text document editor. If you're comfortable with Microsoft Word, you're most of the way there. It's not the drag and drop style editor lauded by modern low code platforms, but it is similarly intuitive. You also don't need to design the database separately, when you add fields to a form, Domino will do the rest for you.

Domino moves from no-code to low-code with its Formula Language. Computed fields, view columns, view selections, actions etc. all use this Formula Language. It is sometimes called "at-formula" because all of its functions start with the @ symbol. It is similar in complexity to the formulas you would find in a spreadsheet and so still aimed for use by citizen developers.

Later versions of Domino introduced LotusScript. This is a general programming language with syntax similar to Visual Basic. It supports procedures, functions and object-orientation and comes with a complete class library for manipulating Domino applications. It is far better suited to more complex tasks or where reuse is required. It is also where we start to lose citizen developers and need professionals.

The all purpose hero of automation in Domino applications are agents. These are self contained units of code that can be triggered from actions, events, the web or on a schedule. It is agents that turn document repositories into workflow applications and beyond. Predictably they can be written using Formula Language or LotusScript. They can also be written using Java, and you can import any custom or 3rd party libraries you need. This really raises the bar for what you can code in a Domino application.

As mentioned previously you can (and should) override the default HTML generated by Domino when an application is accessed via a web browser. This adds HTML, CSS, and JavaScript to the mix of technologies in use. The skill set required to develop a modern Domino web application is not too dissimilar to other full stack developers. Web technologies for the front-end, LotusScript and/or Java for the back end, Domino for the database.

It can be argued that Domino is the original low-code development platform, I've heard some people actually argue that. While true for some simple types of application, it's not really true for most. When I started Domino development it was described as Rapid Application Development or RAD. I prefer this term because it more closely describes the situation. Domino makes some common development tasks as easy as point and click, which in turn makes development surprisingly quick. However, it also comes with the tools to go full pro code when required.

Domino Designer is installed alongside the normal Notes client, it shares all the same authentication and connection profiles, as a result it requires almost no additional setup. You don't need to worry about installing plugins or connecting to project repositories, it just all works out of the box.

It's not all roses however, the IDE is ageing and in desperate need of some upgrades. It is largely based on Eclipse with some editors that have been lifted from the older pre-Eclipse version. It has some interesting bugs especially with how some of the side panels are rendered. Most annoyingly for me however is the JavaScript editor does not support ES6 and refuses to save valid JavaScript because it fails its outdated validation.

When introducing new developers to Domino, particularly graduates, the state of Domino Designer is a cause of much embarrassment. When compared to modern text editors and IDEs it does not fare well. The lack of a dark mode is almost a show stopper for some grads. It takes months before they can see past the quirks and issues and recognise Domino's value.

Domino's RAD development approach is a genuine advantage and an important part of the product. However RAD development is not unique to Domino and the outdated IDE lets it down. Therefore in my view, it is not one of the killer features, but certainly an honourable mention.

Self-contained

A feature I particularly appreciate is how Domino applications are self-contained in a single NSF file. Documents in a Domino database can store anything, normally this is a collection of fields, however it could also be binary data. The application can therefore store its own design including all the forms, code, images, libraries etc. There is never a question of where the logic for an application is, it's in the same database as the data.

This is the reason why the terms "database" and "application" are often used interchangeably with regards to Domino. They have the same scope and are mostly the same thing.

It has several advantages from an administration point of view. For example, to backup an application you need to copy one NSF file. This will give you all the data, logic and meta-data required for that application to run. If you need to move an application to a different environment, just copy over that single file. Normally the only extra thing you need to consider are users and groups, which by default are also stored in a Domino database, just a centralised one used by all the applications.

This also makes application deployments a breeze. Any NSF can be marked as a template and Domino provides a system to synchronise design elements between templates and other databases. Upgrading an application is a simple process of creating a template and triggering a design refresh. Rolling back requires restoring the previous template and triggering a design refresh. All the effort really goes into template management which just requires a little bit of discipline.

When deploying an application, there are no extra steps to link the application to the database, by design they are already linked. In fact the database, the web server, server side engine, scheduled tasks, email, user authentication, everything you need to run an application is all provided by Domino. Obviously some of these require configuration when the environment is first set up, but come application deployment time it is extremely rare if you have to do anything other than the design refresh.

Deployments only become a chore if you also have to manipulate the data as part of the upgrade. With Domino being a document oriented database, my experience suggests this is the exception and not the norm.

As a result the operational part of Domino has a very low cost and depending on the company set up, it's quite practical for developers to be responsible for operations. When DevOps started to become a thing, I was pleased to discover I'd been using the new paradigm for years, I just didn't know it had a name.

Consider a similar application with Microsoft technology. You'll need SQL Server for the database, IIS for the web server, AD for user and group management, Exchange for email, DevOps Server for package management and deployment (I think) and Visual Studio for the actual development. Each of these are their own discipline, with their own installation processes, individual set up, separate tools and training courses. Developers need to understand the different APIs and how these applications wire together. Administrators need to maintain multiple products, or in my experience I'll need multiple admins each specialising in a different product. Operations are more time consuming, requiring updates to multiple products and maintaining the links between them.

Domino in comparison is installed as a single product and administered as a single unit. With some rare exceptions all the configuration is stored in Domino databases that can be edited using either the normal Notes client or an advanced client called Domino Administrator. It can get complicated for larger environments, but in comparison it is relatively low effort. For example when you configure the security in Domino you have secured the database, the web server, email, everything in one go. With other platforms you may have to repeat that process for each product.

Domino's all-in-one approach also makes it more reliable. For example you don't need to worry about dependency management. There is never going to be a time where the database gets upgraded to a version the web server does not support. You're not going to need to spend time diagnosing why product A has suddenly stopped talking to product B even though no one claims to have changed anything.

Ultimately Domino being a single platform saves time and effort, it improves security and increases reliability. Developers can spend more time on development and less time context switching between technologies. Administration requires a minimal amount of resource, and there is no need to spend time linking databases to web servers and server side backends. What company doesn't want to have its staff focused on the value add and avoid non-productive time? For me, Domino being a complete package is killer feature number two.

The alternatives

There are other solutions which claim to be modern replacements for Domino.

Microsoft SharePoint is often cited as a replacement and while it is fine for simple document repositories it is not an application development platform. For SharePoint on-premise you used to be able to use tools like InfoPath or SharePoint designer to customise it, however both of these have been discontinued. There are third party tools like Nintex you can also use to customise it. However it might be easier to abandon SharePoint and develop a traditional .NET app instead.

For SharePoint Online you very quickly end up realising what you should be using is PowerApps. And maybe Microsoft Dataverse. This then starts to look suspiciously like Microsoft Dynamics 365, and you start to wonder if you should use that instead. It may all have Microsoft branding and be available via Microsoft 365, but you are back to the problem of needing to use multiple products. It's also not entirely clear which products to use when and if you are even licensed to use them.

For application development, a better fit seems to be the various no/low code platforms. Nintex seems to be slowly detaching from SharePoint and marketing themselves as a stand alone no/low code platform. K2 was in this market until Nintex purchased them. Outsystems and Mendix are also marketed as no/low code application development platforms. HCL even has Volt MX.

I feel that no/low code is a misleading marketing term as it's not strictly true. For tools that are genuinely no or low code and intended for use by citizen developers, you very quickly hit a ceiling of what can be done with the tool. You end up trying creative, often time consuming, workarounds to build the logic required. At this point the tool is more hindrance than a help and the logic could have been described far more clearly and quickly with a few lines of code. It seems that any sufficiently mature no/low code tool has already arrived at a similar conclusion and provides a way to enter code when the point and click interface reaches its limit.

This is not unlike what I previously described with Domino Designer, where initially the tool may have been intended for business users but over time has expanded to support professional developers. Nintex, K2, Medix, Outsystems and Volt MX all fall somewhere on this spectrum and therefore, at least from a development point of view, are potential replacements for Domino.

Another way to view these platforms is "low admin". What they do well is take all the various components you need to run an application, package them up and provide them as a single installed program or online via SaaS (software as a service). All the various configuration, dependency and security problems I was discussing in the previous section are absorbed by the platform. What administration is left is all done though a nice portal and development is completed via an IDE.

The big problem is these systems can get expensive, especially the SaaS ones. I can't give exact numbers, quotes depend on many factors, but they are at least an order of magnitude more expensive than what we are paying for Domino. In Microsoft's case this is in addition to the licence we already have for Office, SharePoint, Teams etc. For most of the other products, we would also need to licence a database to be used by the system as that is not included.

It would seem the reason Domino is cheaper for us is the way it is licensed. We buy a utility server licence, this is basically a per server licence that considers the speed and number of processors the server has. The other solutions are based on either the number of users and/or the number of applications. If you have a lot of apps and/or a lot of users, this very quickly adds up.

HCL also offers per user licensing for Domino. They have for many years now been encouraging customers to switch models. Every time I renew our licence, our HCL Business partner say we should switch and after reviewing our user numbers come back with a per server quote anyway. My own estimates with publicly available data put the costs inline with the other platforms, somewhere between ten and hundred times more expensive. If we were using all of Domino's features and our users were using the Notes client we would have to switch to the per user licence. Having developed all our applications to be accessed via a web browser and only using the application development and hosting features means we can just licence the server.

It's very hard for a business to justify the increase in expense when comparing Domino to one of the other solutions. Ultimately sticking with Domino is the wise choice. This in my opinion makes Domino's per server licensing model killer feature number three.

What HCL are up to?

HCL announced they are discontinuing per server licensing.

The announcement describes this as "License Simplification" and how per server licensing is "based on Processor Value Unit licensing, an old license metric no longer relevant in a modern Cloud / Kubernetes world". You can read the full blog post here.

I'm sure for some customers this is a non event. I guess it depends on how you use Domino. We've been told that the switch should be cost neutral, but I've never had that in writing and I'm still waiting on a quote using the new model. I know what the normal per user cost is and what we are currently paying and the maths doesn't work. It's going to be a tough pill to swallow when our licence is up for renewal, and I'm going to have to once again justify Domino to management.

HCL purchased Domino in 2019 and since then have continued to invest in the platform. There has been about one release per year. Beyond the bug fixing and what I imagine is a massive technical debt that needs addressing, HCL have released a few big ticket items.

For example, HCL released the Nomad client for Apple, Android and the web. This allows you to run Domino applications on mobile devices and in web browsers without any additional development. Applications look and work as they do in the normal Notes clients. This is a fantastic option for organisations who haven't already re-developed their application to work on the web, either using traditional Domino development or XPages. For us, it's of very little use as we already did the hard work.

HCL have also released Domino Leap (originally Domino Volt). This is a web based low code IDE that uses Domino as a back end. We've been trailing this for some time with business users who wanted to develop their own applications. In a familiar story the users quickly tried to do things the tool could not support and mostly gave up. Except for one user who found you can add your own JavaScript and has gone wild developing their own thing. To HCL's credit the release cadence for Leap has been about every 6 months and the product is much improved from when it first landed. Leap is however licensed as an add-on for Domino, so as useful as it might be, I can't use it to justify the increase in cost of the base product as I have to pay extra for it anyway.

There have been some improvements to the Notes client which generally I'm not interested in except they replaced the tiny properties dialog. Sort of. They actually added a second "advanced" properties box which can't replace the original as it only covers some of the original's functionality. So now I have two properties dialogs.

From a developers point of view I think the biggest updates have been a JSON parser in LotusScript and the new REST API. Domino 14 which was released in December 2023 included a new JavaScript editor, unfortunately when editing JavaScript libraries it still triggers an old validator on save that rejects ES6 syntax and refuses to save. They have also released a version of the Domino Designer that runs in the web browser in the same way the Nomad client works. This is marketed at those that wanted a Domino Designer client for Apple or Linux. I admit I've not tried this client yet but am curious to see if it fixes the JavaScript validation problems and rendering bugs with the properties panel still present in the version 14 Windows client.

As I struggle to recall what improvements we've received in the last four years which have made a noticeable impact to our usage of Domino, I realise this alone is not enough to justify a significant increase in cost.

Honourable mentions

I've not covered everything I like about Domino, this post has gone on long enough but before I conclude here are some honourable mentions.

The Domino database supports replication. This was more important to me than it is now. In the 00's when networks were slow, expensive and far from always on, we had a Domino server in each office and used replication to keep everything in sync. Today I have all my apps hosted on one server so I don't need replication, but it's there if my situation should change. Clustering is also supported, and as application usage grows I have started considering this as an option to add some load balancing and resiliency.

Domino is very backwards compatible. Applications that were written over 20 years ago for Domino 4.5 would still work today. In theory you can go back further, I've just never tired. In my experience the only problem we regularly get when upgrading Domino is the default fav icon is reset. Otherwise we take care to test anywhere we have broken out of Domino to access other systems or tools but the core Domino functionality keeps on working. This makes keeping up to date almost trivial and keeps our security team off my back.

Wait a second, what about email?

You may have noticed that I've not really discussed email. This is because I view Domino as an application development platform where one of the things it can do is email, and one of the out of the box applications is an email client. This is not how a vast majority of users see it, for them Notes is a bad email program that can also do other things. I understand their point, for a while Notes was marketed and sold as "just" an email solution, so many users only used it for email.

While the email functionality in Notes is comprehensive, it's different. Emails are (or were) referred to as memos, revealing Notes' age and a nod to the paper based internal memos Notes was replacing. This might have made more sense in 1989, but it's confusing for new users in the 21st century. Other terminology was similarly unintuitive, insteading of sending and receiving mail, you replicated your mail file. While technically correct and hinting at the much wider scope of the Notes program, for some uses it's simply confusing.

Add these usability issues to poor user experience with the client in general, it is easy to understand why anyone who had to use Notes just for email has been scared by the experience. For anyone still using Notes just for email and calendaring, despite the recent improvements, I argue you are using the wrong product.

Final thoughts

I'm not sure if the way in which we use Domino is rare or fairly common. Based on the features HCL seem to be focusing on, there are a lot of companies still using the Notes client and a lot using it for email and calendaring. This is backed up by the feedback I see in the Domino ideas portal. So on the surface of things we are a special case.

Anecdotally however there are also lots of companies who have migrated away from Domino for mail and instant messaging and simple document repositories, but are still using Domino for bespoke application development. This is sometimes because they could not find a suitable replacement or because they could never justify the resource required to migrate. It would therefore seem we are not unique in using Domino only for application development and hosting.

I'm curious to see if HCL reverses their licence decision, or announce a new additional model that works better for us. I guess that depends on how many companies push back on the change.

Meanwhile Domino's other strengths are still there. Security is second to none. Its self contained nature with design and data in the same database brings so many benefits to development, operations and administration. It is also one of the few options that does not require a separate licence for a database server. I therefore maintain it is a good platform for application development and none of the potential replacements quite measure up. Despite what happens to the cost, this may be the conclusion we reach at work, add in the effort to migrate and Domino is likely to stick around for a while yet.

I would however struggle to recommend Domino to a new customer. It has not aged well and there are way too many quality of life issues and quirks. This is especially true with Domino Designer. While these are largely minor problems that I've gotten used to or have workarounds for, they are barriers of entry for new users. For new members in my team, I can support them for the first few months as they get used to Domino, this is not the case for a third party and so I cannot confidently recommend it.

I hope HCL continues to make updates to Domino, address the bugs and quality of life issues and generally bring it up to modern standards. It would be nice if they could pick up the pace a little bit, the most popular requests in the ideas portal are now five years old.

I shall continue to watch and evaluate the alternatives. The focus on low code is a mistake in my opinion, it limits the scope and capability of the platform. Instead I'm looking for a professional development environment with tools to help speed up or automate the common standard tasks. I want a platform that lets me focus on development with administration and operational efforts as low as possible. Finally every time I realise I need to plug the platform into an independent SQL database server, my heart sinks.

I believe there is a gap in the market. Domino is good but in a desperate need of a tidy up and modernisation. The alternatives are getting better but are not complete. It is entirely possible I'm the only person who wants this exact combination of features which is why it does not exist. Then again, maybe I'm right, but that exact combination is really hard to put together.

Either way my next step is to have a go for myself. Let the learning commence.

TC