Welcome to the third and final part in the series on lessons learned replacing Lotus. In the first part I made some subtle (and not so subtle) suggestions abut the issues associated in replacing Lotus. I then used another (similar) example in part 2 to discuss how technology is often a disrupter that can influence strategy and how careful preparation can help with that strategy. Now I would like to turn specifically to Lotus software and some very specific lessons I have learned over the years. Some are obvious. Some lessons have been learned the hard way. All are (IMHO) valid depending on the specific needs of the project or situation. Lotus applications can be replaced and many people are doing it. It might not be exactly the way you had hoped. Certainly not the way many people promise with some variation of the magic button that delivers a perfect results within a magic timetable. But it can and is being done.
Notes Is Dead (Or So They Say)
Let’s start by dealing with the 800 lb (363 kg) gorilla in the room. Is “Lotus Notes” dead? Well technically yes, because the official name has now been changed to IBM Notes. Many people, including most of us at Red Pill Now, have been heard to claim this is true even if it perhaps it is not an entirely true statement. But its not entirely fake news being spread by the dishonest mainstream media. Red Pill Now estimates that Notes as an application platform has fallen from a peak of 20 million applications to around 10 million today. Of those who remain on maintenance with IBM, we believe 60% are for both mail and applications and 40% for applications only. So people are moving away from Notes as a mail client much faster than they are as an application platform. Thick clients such as Notes and Flash have lost popularity over thinner web clients. It is pretty clear that Notes market share is falling. In response to this IBM have reduced their investment in Notes, but certainly not stopped investing. Likewise IBM have indicated that Notes will be supported for AT LEAST five more years with no plans to discontinue the product.
So while it is clear many people have moved away from Notes and many more are looking to follow, Notes is a little like my 2011 Lexus. Many of those who purchased a Lexus in 2011 have already replaced their car, others like me are deciding to hold on a little while longer until it makes sense to make a change. I have presented about this previously noting that 80% of financial transactions are still run on COBOL. Nobody is suggesting COBOL is a programming language for the future. And yet it has remained long after its supposed use by date had expired. It is often difficult to justify replacing something that still works as needed. The business value generated often simply don’t justify the cost and risk.
There are a growing number of things you could or should be doing with your applications that Notes (especially the notes client) cannot do. The real question is what are the smart choices for addressing these needs. So lets start with strategy….
I often hear the expression “We need to get rid of Notes”. This is not exactly what I would call a great software strategy for any company. In other cases it seems to be more a political decision rather than a practical oneI. To me the Lotus Notes debate sounds a lot like the 2016 US election in which we had a battle between a whole bunch of people who hated Trump up against another group of people who hated Clinton. What we ended up with was a president and congress that wanted to get rid of Obamacare but no idea about what they wanted for Health Care. I think most people on both sides would agree “we the people” would have gotten a much better outcome if we had focused on debating about WHAT we wanted for our country rather than WHO we didn’t want to lead it. So let’s not make the same mistake with Notes. What I would prefer to be hearing in this important debate is not about the products and brands I don’t like but what is needed from an application platform in 2017. Define your business needs clearly to allow us to better identify the best paths to follow.
The world (and technology) has changed a lot since many of those Notes applications were first developed. In 1989 there were a lot fewer choices for automating business processes. Many Notes applications were developed outside of IT and hence viewed as not costing the company anything to develop. The cost to replace these Notes applications is significant and something that usually falls on the IT department to budget. I can tell you from experience the worst type of application development project to be assigned is the one that starts with “I need you to replace …”. The requirements are often poorly documented and the full functionality often not well understood. The developer is often roasted over a naked flame for every little variance between the existing system that devoted users are reluctant to relinquish and the projects frequently run significantly over budget in both cost and time.
With all the changes in application technology since 1989, the central question to ask in 2017 is to what extent are applications a key competitive advantage to your company? There are many companies who should seriously be considering getting out of the application development business and purchasing 3rd party solutions. Sharing the cost of development for software that automates a non-strategic component of your company often makes more economic sense today than the cost of maintaining an in-house solution. For example, unless your are Hertz or Avis you probably don’t need a custom in-house fleet management application to manage your fleet of cars (even if they are all Lotus). Unless your are IBM, or Microsoft you may not need a custom help-desk ticketing system for your IT department. At Red Pill Now we have NO in-house applications even though we have some pretty handy developers on staff that could develop almost any system I might care to dream up.
Even if you decide your company does have proprietary processes that it wants to automate as part of custom applications the chances are that many of the existing applications you have are not delivering a competitive advantage. It is these applications you should consider finding a 3rd party solution that might provide a lower cost approach in the long run. But don’t do it the other way round. Don’t look for 3rd party solutions that can replace your existing Notes applications. If the existing application contains support for proprietary processes not easily duplicated in a 3rd party solution, no matter how small, your rush to replace Notes might give away important competitive advantages for your organization.
Rule 1: Focus on the applications that deliver a competitive advantage for your company.
Retire, Retain, Renew, Replace
While it is something of a simplification, the key choices that can be made when looking at a strategy for individual applications are Retire, Retain, Renew or Replace.
If your assessment is that an application no longer has any business value, or its value is less than the cost of following one of the other strategies the best thing to do is simply to stop cluttering your application attic with junk and just throw it out. Note: There can be danger if you rely on usage statistics alone to determine if an application should be retired. It is not unusual for a useful application to stop being used simply because the original owner moved on and nobody explained to the new people where the application was and how to use it. It might also be that a worthwhile application has stopped being used because a key bug (which could be easily fixed) was never addressed. If you do decide to retire an application you may decide to archive the data is some way such as a PDF first. But again, only do this if you really think there is a chance the data would be needed. Most companies will survive quite OK without a record of who registered to attend your 2003 IT Christmas Party or the discussion threads for that Y2K project!
In some cases you might decide that the application is doing what is needed and no further action is required. This might include applications whose end of life is nearing that doesn’t warrant any further investment. It can also include scenarios in which you are quite happy with Lotus Notes and the Notes client and have no need to make any changes at this time. Regardless of the reason it is usually a good idea to set a review date for every application based upon its strategic importance to come back and review the strategy again at that time. The business value and technical alternatives can and often do change over time.
There are a lot of situations in which a review identifies that an application is not meeting its full potential for the organization and/or its users. Lotus Notes is not unique here. Even my 1989 Lotus would start to perform badly for me if I didn’t bother to take it in to be serviced on a regular basis or ensure it was washed, polished and waxed the car from time to time (or filled it up with gas!). Because so many Notes applications just keep working it can often be hard to justify investing in regular enhancements to keep them in sync with modern best practices such as a mobile interface or touch screen support.
Renewal can come in many forms. It could simply be to modernize the look and feel of the Notes client application to, for instance, apply a UI that is consistent with the corporate brand, replace those Navigators with Outlines, or replace BMP image files with PNG files. It could involve replacing the Notes client with a modern Web interface or replace a HTML or XPages (Web) interface with a more modern interface. Renew can also involve improving the UX with additional business functionality that has long been needed but never addressed. All have the ability to improve the user experience without replacing the underlying Notes database.
The final option is to replace the application. This could include replacing the application with third part solutions. Discussion databases can be easily replaced by persistent chat clients such as Slack. Document libraries can be replaced with file storage systems such as One Drive, Box, or Connections Files. Specialized solutions such as Help Desk, Fleet Management, Expense Tracking, CRM, ECM, and ERP all have a wide range of third party solutions that should be considered if these processes are not proprietary.
For proprietary applications in which it makes sense to have a custom application it might make financial sense to move the solution away from Notes completely to another platform. This is especially true of large Enterprise applications where it is decided that it would be a better choice to maintain the important business logic in a language other than LotusScript. The other reason might simply be a decision to move away from Notes to something such as SalesForce, O365, or .Net. Whatever the reason Replace is often very expensive and includes the additional risks associated with having to cutover the data to the new platform. A step which is usually a one way street.
Rule 2: Don’t generalize. Set a strategy for each application based upon the specific needs of that application.
Strategies developed for individual applications should take into account the role the application plays within your organization. Personal applications are those that are used by one or two people whereas departmental applications are typically used by a larger group of people located within the one department (which might span multiple geographies). For Personal and Departmental applications we should consider careful the extent to which there is a need for a low-code environment to sustain the application moving forward. If those applications are being (and/or will be) maintained by citizen developers rather than trained professional developers, the skill set of those citizen developers needs to be considered carefully.
For Enterprise applications, those used across the organization or across multiple departments or of strategic importance, it is important to have a clear strategy of both the architecture, and current platforms that will be supported for all these applications. Moving away from Notes is simply not a good enough strategy for these types of applications. You need to have a clearly defined strategy of what you are moving to. These will usually be the responsibility of IT to maintain and should be developed in a way that matches governance standards such as documentation, testing, audibility, security, change control, DRP etc.
Sometimes the timetable for moving away from the Notes client, or away from Notes/Domino doesn’t always coincide with the effort required to move everything to the target platform, even for Enterprise applications. If that is the case don’t lose sight of the end goal. Plan an interim step that gets you to where you need to be in the short term and then plan to make the final jump as part of a second stage.
Rule 3: Focus on Enterprise applications first. Have a clear strategy of where you want these applications to be.
Jumping from the Frying Pan Into the Fire
When pursuing Replace strategies in particular, it is important to learn from the past and keep track of what the business objectives are, and the root cause of any technical failings. If you feel the need to move away from the Notes client because you are concerned with the level of investment IBM are making in the product and the wisdom of maintaining important business logic in @formulae and LotusScript (two proprietary programming languages that have a shrinking base of skilled developers), does it make sense to move those applications to another platform that is supported by an even smaller company with an even smaller budget for product development or is based on an even more obscure programming with an even smaller following? When we move Enterprise applications to a new platform we should chose one that supports open standards backed by programming languages for which there is a large base of available developers. Migration costs may be a significant expense in the short term but often represent a small part of the total investment that will be made over the lifetime of the application. What happens when the next big technological change comes about. How sure are you the new platform is going to be any better prepared to solve those needs than IBM was with Notes!
Rule 4: Don’t let a lower cost of migration dictate your application strategy
While there are usually a great many applications within an organization they typically fall within a small number of usage patterns. Each of these can have specific strategies applied.
Applications which have a small number of editors but a large number of viewers. This includes applications such as bulletins, newsletters, policies and procedures, and documentation databases. For these applications it may be possible to follow a Retain strategy for the edit capabilities and implement a Renew strategy for the viewer capabilities. As a result you might be able to get 80% of the users of the application off the Notes client by focusing on the 20% of functionality (and 20% of the cost) needed to support just this subset of users.
Red Pill Now focused on this model with the early versions of its Red Pill DIG product because we felt confident we could deliver a read-only interface to an entire portfolio of Notes applications much faster if we focused on Read-only and search functionality first before tackling the much deeper issues of providing a generic edit capability for Notes applications. This was one of many lessons learned from the GBS Transformer project.
Rule 5: It can be a lot more expensive to replace the Notes client for 100% of your users than 80%.
Central Workflow Model
Applications which have a large number of document creators but only a small number of document editors. This includes applications such as travel requests, legal documents, and help desk. In this case it may be possible to build a modern web form to handle the creation phase and then fall back to the existing Notes client functionality for the workflow.
When there is a small number of users (readers and editors) it is often hard to justify doing much with these applications, especially if there is a lot of code involved. If the application is of high strategic importance or the users are politically important (e.g. C-level) then there may be no choice but to develop a strategy for these applications other than Retain. Third-party solutions and low-code platforms can sometime be a target strategy for these types of applications.
Applications which have a high number of editors (and optionally a high number of readers) are often the most challenging to address. I have no specific advice for these outside of those general strategies discussed in other areas.
Know Your Applications
Forensics products such as Application Insights or TeamWorkr Analytics can often be a good way to get an initial assessment of your applications. But be careful, there are often a lot of traps in relying on this type of analysis. I have already mentioned the dangers of assuming an application is not being used based upon usage data alone. When it comes to getting down to the details of the code itself Forensics can be even more dangerous. I would estimate that at least 90% of all Notes applications start by making a copy of an existing application. I would also estimate that as many as 90% of these don’t have the code cleaned up to remove all the copied elements and code that weren’t used from the original database. As a result you will often get statistics that suggest many of your applications are very similar when they are not. You will also get an exaggerated level of code that is simply not used. That’s even before we get to the scenarios in which applications over time retire functionality that is no longer used but remain in the code base.
The bottom line is that nobody knows your applications as well as the users (especially those who supervised the original development) as well as the developers who may have spent the most time writing and maintaining the code. They can attest to how important the applications truly are, how well they meet the current needs of the organization, and to what extent the application itself (or its processes) are strategic to the organization. They may also be useful in identifying changes that are coming down the pipeline that may change any of these.
Rule 6: Forensics is good but knowledgable users are much better
If your application strategy is to Renew or Replace and you have more than a handful of applications you may decide to start looking for that magic button that is going to do the work for you. Having worked at GBS for two years on Transformer and four years at Red Pill Now, I can assure everyone that button does not exist. There certainly are tools that can help in certain ways. And there are a few shortcuts that can be taken (see below). But for custom Enterprise applications especially there is a lot of hard work that needs to be done.
At Red Pill Now we now believe the average cost to Renew Notes applications (spread over the entire portfolio) averages out at $US 25,000. For Replace strategies that increases to $30,000. So for the average company which has 200 applications for which the Renew strategy is assigned to 25% and the Replace strategy assigned to another 25%, that equates to a total investment of $2.75 million. There are a number of analytics tools that will help you. Often they are based upon an assumption that all the code in the database needs to be renewed or replaced! These typically work by taking the number of forms and views and multiplying by a complexity score to get a final cost. The numbers will vary significantly application by application. But I have found over a large portfolio of Notes applications the formula can be simplified to Complexity Score = $30,000 / (Number of Forms + Number of Views).
One of the great things about Excel is that is will accept the data and formulas you provide and calculate an answer. I can build a financial model for my company that shows investors how they can get a 100% return on their investment in no time. All I have to do is find some credible way to achieve those sales growth forecasts that drive the outcome. Excel is not going to challenge those numbers but a smart investor might. The same is very true when it comes to creating a budget for your Modernization project. If somebody is suggesting they can do it for much less than $25,000 per application seek hard evidence they can achieve that. And if they can then do it please let me know, as I would love to hear about it.
Rule 7: There is no magic button. Plan accordingly.
If you have more than a handful of applications and a small core of developers at your disposal the chances are you will have a project that runs somewhere from 2-5 years to complete. Even when there is an acknowledgement that the magic button doesn’t exist, the next flaw in many project plans is the magic timeline. Nobody is EVER going to take a portfolio of 1,000 Notes applications and migrate them away from the Notes client inside a year yet there are plenty of companies that try to do just that. The number of Notes developers that would be needed to theoretically do this would be so high there would be massive coordination failures between them that very little would ever get done. Unless you engage a special team just to do this work, the chance are the developers, managers, project managers, QA teams etc are going to be distracted with a whole bunch of other work over and above this work.
Run the numbers very carefully and don’t start the project until the stakeholder have a clear understanding of just how long this is going to take to achieve. Unless you are adding new functionality to these applications your users are not seeing a lot of immediate business value for these projects. Your taking what they already have in the Notes client, and at best, giving the same thing back to them on another platform, which may include a Web/mobile interface. If its starts running over budget, behind schedule, and causes disruption to existing business processes you will probably have a major PR issue to address in order to win your customers back. Also keep in mind that when IT departments migrate from one technology to another they usually use that as a time to review the technical teams that they have supporting those applications. This is not a project you want to fail when you are trying to convince people of your ongoing relevance to your employer. Don’t set yourself up to fail by making these projects seem simpler than they really are. Yes, its often a thankless task which is why its important to establish the sound business reasons for taking this on in the first place.
When the timelines become multiple years it can often be worth implementing stop-gap solutions to cover short-term needs needs over the life of the project. For instance, even if your goal was to migrate all your Notes applications to a combination of O365 and K2 over a 3 year period you may want to look at solutions for providing Mobile or Web interfaces for all your existing applications to cover the application that don’t get migrated in the first six months.
Rule 8: The term “wrestling with a greased pig” originates from the very first Notes migration project. Schedule accordingly.
Having established a strategy for all your Notes applications, the order of execution can have a significant impact on the success of the project. There are several options worth considering.
Perhaps the worst strategy to follow is the one in which the easiest applications are selected first followed by applications of growing complexity. It might sound like a good idea to start with the low hanging fruit, right? The problem is that you are assuming the strategy, budget, and timeline are all correct. The easy applications are rarely the ones that are going to cause problems. If you are going to have a failure it is often better to fail fast than it is to delay the failure until a significant proportion of the budget and time has been invested in that approach.
Most Complex First
The opposite approach is to start with your most complex application work. If for any reason the strategy doesn’t work you will have invested a modest amount of time and money to find out. If the strategy works but ran over budget or time it may be possible to refine the strategy or revise the process to be applied to those that follow.
Rule 9: If you are going to fail, then its better to fail fast
Simple First, Most Complex Second
In this approach we chose one of the simpler applications to use as a learning exercise. This allows us to complete the process once and refine it before applying it to a much larger project.
Most Value First
Across an entire portfolio of applications we usually find a level of diminishing returns. A few applications can provide a high return on the investment while others provide much less or even negative returns on the investment made. By starting with the applications generating the highest returns we make the biggest business impact early on in the project. If for any reasons budgets become an issue or resources get reassigned to other projects we will have gotten the highest return from the amount of time and money spent.
If one of the goals is to eliminate the Notes client the fastest way to start getting people off Notes is to focus on the applications with the highest numbers of users. This process can be further refined by looking at the people who only make use of one (or two) Notes applications and focusing on the applications that are most frequent amongst those. If 10% of your Notes users only make use of one Notes application and that gets renewed or modernized in the first month then 10% of your users can uninstall Notes very quickly.
Rule 10: The order of execution can deliver tangible results faster.
Bring In Outside help
OK, so you’d expect a consulting company to make a pitch for consulting services right? But seriously, if you have a project that is costing you $1 million or more it doesn’t take a lot of advise to be given to improve the return from the project. We would suggest investing anywhere between 1% and 5% of your projected project cost to get advice on developing the initial strategy and high level project plans. When it comes to execution of the strategy there are a number of options worth considering. A project like this is likely to come on top of an existing workload so it may be that you need to expand your team in the short term to cope with the extra workload. If that is the case either hire somebody or engage one or more contractors that have experience with the type of migration and/or technologies that you are going to start using. Another approach worth considering is finding experts in the new technology and have them work on the first application to create a good example for your own team to work from. You might then use those experts in the role of mentors for the next few projects and later have them on call to help out when problems arise with later applications.
Rule 11: Find smart part and use them as often as you can
Of course it’s a little more involved than that. For architectural reasons we may want to find a clever way to expose the agent via a REST service. We also need to make sure we have isolated out any UI aspects of the business logic and dealt with it in a different way. But once this is done we will have found a way to reuse a lot of the existing code significantly reducing the conversion costs and greatly reducing the chances of introducing bugs into the application.
Rule 12: Find smart ways to use the code you already have, its cheaper and safer
Another major savings in cost and time comes from making the effort to identify the origins of all common code. If you can recode a solution once and apply it many times the returns can be significant. Some databases may share the exact same code. They don’t always define what that template is or the template may be difficult to locate. Be careful though. Changes to one or two lines of code can be significant enough to make two applications distinctly different so check the differences closely. There are some excellent tools out there for doing this such as TeamStudio Delta.
We often see the same design elements shared across multiple applications. But remember, most applications usually start by copying another database. So a lot of the code might be shared but not used in the second application. It is often a good idea to document confirmed links by establishing template inheritance at the design element level with a view to again coding the solution once and implementing it many times. And even better still to get rid of all that duplicate code that isn’t actually used.
Once the project has started you will soon start to recognize a number of patterns in the code that trigger attention. This may be because the pattern represents an issue that needs a lot of extra thought. It also might be a pattern for which a common solution can be quickly applied. As these patterns are identified you may want to use a tool such as Application Insights to help you find exactly how many places these patterns occur. These occurrences can often help in the budgeting and project management processes because their presence can either add (or subtract) to the effort for the applications involved.
Even if you are not planning to implement a strategy for Replacing Lotus now. There is never a better time to start preparing for this well in advance.
One of the best places to start is the development of an application catalog that defines all the Notes applications within your organization. Identify the key users of each applications that may help you down the road answer questions. Try to identify the original developer and the current developer for each application. Now would also be a good idea to start identifying the appropriate strategy for each application to make it easier to build a rough estimate of the size of your modernization project.
The Microservices tactic outlined above can be started at any stage allowing you to get a jump on the modernization projects ahead of time. Start with any new applications you might be building along with those receiving major enhancements. Should time permit, start going back into the existing code.
Source Control (SCM)
Before you start making any changes to these applications it is always a good idea to make sure all the code as it currently exists is backed up into a Source Code repository. This will ensure if something goes wrong (and it almost always does) you have a safe way of returning your application back to its original functionality.
There is no real need to wait until a modernization project starts before you start discarding applications that are no longer being used. If your code has been backed up into a SCM you can also start cleaning up all those backup and test databases that are often left lying around. Within each application work can also start on getting rid of any code and design elements that are no longer being used. A lot of time can be wasted rewriting business logic that is simply not used. I usually took a pretty aggressive stance with applications I managed. Once I had the code in SCM I would start deleting anything I though was not used and wait to see if anybody complained. If I got a call it was usually a quick process to restore the code from SCM. If I didn’t I probably helped save a few hours of wasted time in the project.
The overall application strategy is perhaps the single most important part of what you may do with your Notes applications. Start working on it now. Becomes familiar with the options that exist out there and decide on an architecture that works best for your organization. Revise it over time as technology changes so that when you are asked to do something abut those Notes applications you will have a clear idea of where you are heading and not just “Get me off Notes”.
Rule 13: Never get in a car with a stranger unless you know for sure where he is taking you
Hopefully the above provides some useful tips for those looking to Replace Lotus. If you drive a yellow 1989 Lotus you may need to wait for a later blog article for help on that. This article provides a part of what we at Red Pill Now have learned over the years. If you would like to know more, please feel free to reach out to me or any other member of the Red Pill Now team.
Lessons Learned Replacing Lotus: Part 3 (Lotus software)