As software grows, software grows old. Time has an impact on everything. It is inevitable, even for intangible things as software. Sooner or later the beautiful piece of software you are working with today, will start to fall apart. Maybe the aging will start to show in the user interface. Little wrinkles will show that the GUI isn't able to keep up with 'fashion'. Maybe you'll notice the product getting a little slow in understanding, having a hard time to grasp the latest standards, trends and concepts.
But the real aging of software lies under the skin, in the code that gets clogged up with more lines and lines of extra code where maybe a re-write was in order. Quick fixes, not exactly written as they should have been, but that no one dares to touch again afterward. Little modifications in the code to close that sales deal with customer x. Some extra lines to make everything go smooth on platform y. An extra call to avoid a crash if z occurs. If you have been involved in software development, you know this is all inevitable.
So sooner or later any software needs to be replaced. There is no way around that.
I believe it is clear that many of the existing (proprietary) BI/DWH tools on the market have reached the point where there product needs (or needed) a rewrite. Some examples include the following.
Probably there are few more examples out there, but already these three share some striking similarities:
Indeed, many customers have invested so much into these technologies that they cannot or dare not imagine a life without this software. But are these customers truly locked in by the years and years of investment in this software, IF the upgrade really is a migration? If you need to migrate, why not migrate to another platform.
Almost 2 years ago we published a white paper (that is still available on our website). This paper showed the cost differences in proprietary (Oracle, Microsoft) versus open source (Pentaho) data integration software. (( I believe we were slightly ahead of Mark Madsen, although our study was only a three pager of course ;) )). Anyhow in this study we also discussed the migration scenario. (Read the white paper if you want the details.)
Basically we discussed 3 scenario's:
Basically the conclusion back then was that often the best scenario was to go for open source along side closed source because a rip and replace was too expensive. Basically the migration cost for rewriting your ETL jobs (or reports) - that is, the effort of your IT resources (or even off-shore resources) - makes a business case for rip and replace very expensive (on the short term). In the long run, rip and replace is the cheapest, but where's the CIO that will go for a project that has the best ROI only after 5 years?
I believe it is clear to everyone that in the case of the "painful upgrade", the above charts change a bit. Due to the fact that the upgrade really is a migration cost, we'll see the red curve as well as the purple shifting up in the first two years. Remaining with your proprietary vendor will cost a big effort from your IT resources, just as migrating to a new software would. In that case, clearly option number two, rip and replace, becomes the best scenario.
So, please, if you are one of those customers, that feels cornered by a company proposing you a product upgrade which actually is the release from hell. Consider a real migration as a serious alternative option.
But the real aging of software lies under the skin, in the code that gets clogged up with more lines and lines of extra code where maybe a re-write was in order. Quick fixes, not exactly written as they should have been, but that no one dares to touch again afterward. Little modifications in the code to close that sales deal with customer x. Some extra lines to make everything go smooth on platform y. An extra call to avoid a crash if z occurs. If you have been involved in software development, you know this is all inevitable.
So sooner or later any software needs to be replaced. There is no way around that.
I believe it is clear that many of the existing (proprietary) BI/DWH tools on the market have reached the point where there product needs (or needed) a rewrite. Some examples include the following.
- Business Objects have rewritten their immensely popular reporting product from the ground up. Business Objects 6.5 was the last "old release", Business Objects XI is the new release.
- IBM have (finally) rewritten Ascential's Datastage (after their acquisition of the product at the beginning of this century). They have integrated it into the IBM Websphere family. Datastage 7.5 was the last release of the old breed. Infosphere Datastage 8.0 is the new product release.
- Oracle is coming up soon with a new version of their data integration tool. Oracle Warehouse Builder will cease to exist after 11g and will be replaced with Oracle Data Integration (a cross over between OWB and Sunopsis).
Probably there are few more examples out there, but already these three share some striking similarities:
- All of the existing products have been around since before the year 2000, became very popular, even market leaders in the BI or data integration market segment, and gained a large customer base;
- In each case the vendor has done a complete or significant product rewrite in order to assure they have a product that can keep up with market demands;
- Marketing wise, none of the vendors really choose to position the new product as such on the market, they all positioned the new software as an upgrade of the existing product. IBM choose to maintain the product name and even version numbering, Business Objects kept the name and went from version 6.5 to XI. Oracle positions the rewrite of OWB as a merging of the best features of OWB and Sunopsis, while in reality not much will be left of OWB;
- Last but not least, in all cases the 'upgrade' scenario doesn't drill down to an actual upgrade, but rather results in a costly (and painfull) migration scenario to a new software;
- In all too many cases customers blindly accepted the upgrade and paid for costs.
Indeed, many customers have invested so much into these technologies that they cannot or dare not imagine a life without this software. But are these customers truly locked in by the years and years of investment in this software, IF the upgrade really is a migration? If you need to migrate, why not migrate to another platform.
Almost 2 years ago we published a white paper (that is still available on our website). This paper showed the cost differences in proprietary (Oracle, Microsoft) versus open source (Pentaho) data integration software. (( I believe we were slightly ahead of Mark Madsen, although our study was only a three pager of course ;) )). Anyhow in this study we also discussed the migration scenario. (Read the white paper if you want the details.)
Basically we discussed 3 scenario's:
- Scenario 1: Remain closed source, in other words, stay with your proprietary vendor and pay for the extra/new licenses you might need in the future. That means no need to rework anything. Pay license costs where needed, and build new functionalities as you need them.
- Scenario 2: Go open source. Rip and replace! Remove your proprietary solution and replace it completely with open source. Throw away your old licenses (kind of a cost saver) but rewrite everything you have (or still need).
- Scenario 3: Have both. Put open source next to the proprietary solution for the extra/new functionality and go for a slow migration. You are stuck with your license cost, but will not buy new functionality (remain with old version of the software). I the mean time you deploy open source next to it.
Basically the conclusion back then was that often the best scenario was to go for open source along side closed source because a rip and replace was too expensive. Basically the migration cost for rewriting your ETL jobs (or reports) - that is, the effort of your IT resources (or even off-shore resources) - makes a business case for rip and replace very expensive (on the short term). In the long run, rip and replace is the cheapest, but where's the CIO that will go for a project that has the best ROI only after 5 years?
I believe it is clear to everyone that in the case of the "painful upgrade", the above charts change a bit. Due to the fact that the upgrade really is a migration cost, we'll see the red curve as well as the purple shifting up in the first two years. Remaining with your proprietary vendor will cost a big effort from your IT resources, just as migrating to a new software would. In that case, clearly option number two, rip and replace, becomes the best scenario.
So, please, if you are one of those customers, that feels cornered by a company proposing you a product upgrade which actually is the release from hell. Consider a real migration as a serious alternative option.