In my last post I covered some of Red Pill’s thinking as to why we recommend to our customers not to rush to migrate. Ultimately organizations will move away from Notes databases simply because IBM is showing no signs it has plans to invest any further in the platform and hence will eventually discontinue support. So the question is not one of migrating versus not migrating, but one about how quickly any migrations should take place. When our customers ask us what they should do, we ask where would they rather invest their money at this time?
It is now pretty clear that thick desktop clients such as Notes, Flash, and (even) Outlook, are rapidly losing favor. IT departments almost universally favor delivery of desktop applications via a Web browser.
There has long been something of a myth that data silos are created as a result of having a mixture of DBMS. Almost every IT department I have worked with since started in IT back in 1980 has been on some sort of mission to migrate all its existing applications to a standard platform. Back in 1980 it was IBM’s IMS. In 2016 it is to a much wider range of choices that includes a wide range of SQL and no-SQL products. I see no evidence that consolidating databases into a single platform does much to reduce data silos. Nor have I seen a lot of evidence that data warehouses do much more than create an even bigger mess. What seems to matter most is where an application goes to get its data. Too many applications, including almost all Notes applications, go to the database itself which means the decision is hard-baked into each and every application and difficult to change. It also means that any change to the underlying database can often break the applications.
In 2016 it is becoming quite clear that the best means to achieve data independence is through the adoption of REST APIs. When applications talk to a REST Service they no longer need to care where the data actually resides. They need not care if some of the data they are requesting originates from a different source to the rest. Nor do they care if the data is held in a SQL Server database, and Oracle database, MongoDB, IBM Notes or a combination of these.
REST APIs are relatively simple to write using a wide range of programming languages. For Notes databases the options include Domino Data Service (DDS) or Java. When looking to integrate data from both Notes and non-Notes databases products such as DreamFactory can be an attractive option for Notes developers to quickly generate REST APIs for non-Notes databases.
Red Pill Now is quite impressed with the concepts behind schema.org in building universal definitions for commonly occurring objects. When used in conjunction with REST APIs the opportunity exists to create a domain-wide set of APIs to service the needs of all applications to access data. If an application has the need to access vendor information, there should exist a single set of “vendor” APIs that provide the needs for all applications needing vendor details. That API alone has a need to know where that data resides and how to get it.
The architecture outlined above applies just as easily to Notes databases as it does to others. REST APIs can be developed today that draw data for key business objects from Notes databases and then slowly over time the data can be moved with minimal disruption to the underlying applications. New client applications can now be built using modern interfaces that source the data via a REST API. Once developed they become independent of the source or structure of the underlying data and hence require no changes when your organization becomes ready to migrate the data from Notes to something else.
If you have a significant investment in Notes applications it seems that it is possible to have your cake and eat it to….
Perhaps the most compelling argument for adopting the above architecture is that not only does this approach provide a strategic future for your applications it also allow you to continue to use your existing Notes applications. New applications have time to be developed and gaps in their initial functionality can be filled by using the existing Notes applications. The Notes application provides a fall-back should bugs appear in the new applications. Functionality that is difficult to replace and/or used by relatively few can deferred to a later stage. Employees resistant to change are not compelled to move away from the Notes client until they feel more comfortable in doing so.
Using this approach the Notes client is replaced when people stop wanting to use it. This will mean that the web applications developed will have replaced the functionality that is needed. This may not be all the existing functionality, but your users will vote based upon what they prefer to live with. A kludgy old client with 20+ years of outdated functionality or Web browser that is easier to operate that provide the key things that get the job done.
When it comes to the data, the use of Notes databases will come to an end when none of the REST APIs make reference to the data they hold. The need for data that is duplicated across multiple databases will be the first to go. Data that is infrequently used or low value may never be able to justify the development of REST APIs. Important data held in Notes databases will exist as long as it makes business sense to do so. And when it comes time to do so the architecture allows the option to migrate data into different platforms such as SQL and Graph.
Ultimately it is likely to cost an average of $20,000 to modernize or replace a typical Notes applications. If you are a developer, IT manager, or CIO you may want to consider carefully how and when you chose to take on that expenditure. A data migration almost always forces that expenditure to be brought forward at the same time as introducing significant business risk. A co-existence with existing Notes databases can buy time, reduce risk and allow a gradual move to a more strategic architecture that greatly increases the flexibility of database options as well as breaking down those data silos. Perhaps then we can focus less on migrating data and more on modernizing the user experience.