Where do the majority of apps fall that you see in your quadrant framework? The question nearly every Enterprise customer asks me during my speaking engagements & executive briefings.
They say: "The tools look good, the framework is good, the process is good, now… tell us the typical breakdown of applications for the majority of your customers".
I answer the question the same each time as we have some good statistically relevant data on this topic from our worldwide focus groups, meetings with hundreds of customers, analysts, partners & by analyzing a TON of apps.
In the end, with high confidence we are able to say:
As in focus groups, analyst briefings, partner mtgs & customers engagements we heard & saw the following:
A good example of this comes from an IBM slide on their environment shown @LotusSphere (Title: ID119, IBM Lotus Notes and Domino @ IBM). It states “Out of 100,000 Notes\Dom Applications…” ~65k are custom Notes apps [Quad 3/4]; ~30k ‘TeamRooms’ [Q2]; ~10k other ‘standard’ templates [likely a Q1 or Q2]”. That means IBM’s environment breaks down into 10% Quad 1, 30% Quad 2, and 65% Quads 3 & 4.
In the end, you likely will have a ton of Notes apps that are just not accessed or used anymore & a unique percentage of apps in each quadrant. Using the Application Analyzer will begin the process of helping you to understand your unique environment and plan for your company’s future.
I'm sorry, but I have to say that you are playing fast and loose with these numbers. To start with, I have been involved with a few different organization who did audits of their Notes apps, and never did they find over 25% unused or inactive. 60% is pure wishful thinking. In addition, the vast majority (more than 90%) of those unused applications were the Quadrant 1 & 2 "easy apps". Typically, somebody created a TeamRoom or document library or, most common of all, a discussion database because they are so darn easy to create with a template, and then it never got used. But the real kicker is, what possible difference does it make what percentage are being used? Imagine a company with 1000 Notes applications. Even if you accepted the 60% number for unusued applications, which I certainly do not, the vast, vast percentage of time, energy and money has gone into the other 40%. Nobody ever thought it would be hard to deal with apps that were not being used. It is an irrelevant point. In fact, a person could go create an extra 1000 applications in a day using standard templates, and they would all show up as both unused and Quadrant 1/2, but the task facing a company would be no smaller, even though you could now say that over half their apps were not used. I respect you guys for trying to create tools to analyze a customer's actual needs, but you need to watch your bias. In general, companies should not be undergoing masss migrations from any technology to any other. They should focus their efforts on appropriate coexistence between the technologies so they can continue to use both, and focus new time, energy and money on whatever business needs really exist. It does no one a service, and makes Microsoft look bad, to act as if it is really sensible to plan on migrating hundreds of apps for no good reason. .Net will work with Notes/Domino. Sharepoint will integrate with Notes/Domino. Why in the world should people take working applications and migrate them at all? It is a huge waste of time, energy and money, no matter how you try to spin these results.
good points Ben. few things I'll address:
- ~60% unused apps is relevant when customers begin the evaluation phase of a transition. We would hear things like "its going to cost x or cost y to move a customer", we would ask why and would hear, "well they have 10,000 apps"... after engaging we would find out these #'s were often inflated not in absolutes but rather usage; so in this context, doing this part in the analysis, is important as it helps the customer (and often the partner) properly assess the work in-front of them.
- coexistence vs. migration: I agree completely the focus should be on the adoption of the new technology to help customers meet their business needs, not necessarily one of migration or coexistence. However, as customers make the decision for technology or platform change\adoption; doing this the most cost effective way is often the driving force. In that context customers need to ask, what is more cost effective; connectors & coexistence or migration. Our strategy is we support both, the decision is theirs...
I wanted to chime in since I bloged about co-existence/migration several weeks ago. (here) (Also since it is late Friday and find this topic interesting.)
My take is that coexistence comes into play often because A> someone needs to bridge the time of a migration, B> or when there is not an overlap of features with the new technology and C> or if the cost/value of a migration is not just not worth it.
In these cases coexistence just makes sense and is a fine approach. I worked with several companies that were completely successful with a coexistence strategy for the Domino applications with a plan to leave applications on Domino for their life-cycle.
OK, so what about migrations? Well it comes into play when there is a good feature overlap PLUS some new/added value that makes the cost of moving data (and functionality if needed) worth while.
So the first key is a good understanding of the options and what is better for your environment. (If you were to migrate, what would it cost? If you were to co-exist, what applications are high-touch that you would need to expose in a portal, or what is
near it end-of-life, etc.) Anyway, that is the intent of the analysis phases that we are blogging about.
The second key is understanding both coexistence and migrations are integral to any new technology adoption. Not to ignore one or give one more importance, but to understand their role and how/when they are to be used. I just released the updated mail-connector
last december aimed completely at providing a directory and mail co-existence. I figure if I can make some good co-existence tools, and reduce migration costs with good migration tools then both bases are covered. Hence my day job.
Erik - I agree with you. The hardest part comes in being objective, and that is hard for all parties. Too much of the time, the benefits of migrating are overstated, and the costs are understated. That is not just for Notes -> Sharepoint, but for almost any migration of an application from one place to another. There is just too much incentive for both the company owning the potentially destination technology and the consultants who could make money off the migration to recommend migration over coexistence. That is not to say there are not excellent candidates for migration from Notes to Sharepoint or another MS technology. I am sure there are. I am also sure there are excellent candidates for migration from Sharepoint to Notes, because each technology has its strengths. But I would caution anybody looking at either migration to see if there isn't a way to get the benefits of the other technology using a bridge or connector or tools such as those Proposion sells to coexist, at least for a little while. It often becomes more clear over time that there are higher priorities and better returns for not migrating existing apps, or clear that this is an app that could really use the full migration. I am just worried when I see either IBM or Microsoft, or other technology companies, who push a little harder for the migration that is really warranted, often with the collusion of the consultants and migration specialists who know there is lots of money in that process. Companies should take these recommendations with a grain of salt.
Taking those things into account, the question becomes whether a migration is a re-write or a re-design (i.e., a port or a new project), and that is another whole kettle of fish. I think the ideas you folks are working on are good, but I have certainly seen examples already of how they can be misused. I urge you to be transparent and trust the process you are creating, because even some of your colleagues are likely to be tempted to misuse the tools you are creating. If used well, I think they could be very valuable. I am glad that you are releasing the tools and the documentation, instead of just letting the consultants use the tool, as that level of transparency does allow companies to verify the results and do some of their own analysis. When companies take on this responsibility, no matter what they decide, it seems a better process than when they delegate the decision making to admittedly biased participants.
Thanks Ben for the comments, especially around the value of co-existence. I sometimes feel that the co-existence options is often overshadowed by the big M word. One of the reasons I have been pushing both internally and now externally the PPCM model where co-existence is a valid/good option and backing this model with tools. This is something that I have stressed and will contiune to stress.
Also you are right on about keeping our process/tools as transparent as possible. To me, the more/accurate information/data we can get directly in the customers hands the better.