Often people ask me about "migrating to another platform" as a litmus test of platform flexibility. And yes, the test of a good data system is whether its data can be obtained readily enough to migrate it.
But that's not really true of a good component system. Because if it has the best components -- other component systems are inferior.
As a data for-instance: Oracle. I've found Oracle well, arcane and unpleasant when it comes to data migration. I'm not entirely sure why. Maybe it's the utilities that Oracle provides, with its arcane language. Maybe it's that BLOBs, CLOBs, VARCHAR, and VARCHAR2 all have to be changed. And they're most often, text and images. And what is an application without text an images?
Oracle Data Migration isn't a lot of fun.
But some data systems are downright simple to migrate. They export data in XML, export their data structures in SQL & DDL. That's great. It works. It works well. And it allows you to leverage data export into data communication.
The best of data systems make it easy to communicate. Because what's data without communication?
It's a trap.
All well & good. Data systems and structure are immensely useful to communicate. But component systems? Well, they're best when it's more costly to migrate them. Why? Well, take the building example. You have a steel building, and now you want brick & mortar. How much of the steel building will remain? Do you really want to communicate your components into another building?
It doesn't make any sense, does it.
A steel building was probably cost effective when you set it up. And now you want brick & mortar. All well & good, that's what you want. But you're not going to transmute steel into mortar. And your software alchemist isn't going to, either.
IBM's Domino component model is the same. It's not built to lowest common denominator. It's actually built to fairly high sophistication. So you're going to spend a lot transmuting its advantages onto another platform.
But the data ... well, DB2 and Domino are both pretty easy when it comes to extracting data.
So I often answer this way:
1. If you want to migrate data then sure, IBM, particularly Domino, can migrate data anywhere you want.
2. But if you want to migrate your code ... um ... you barely coded anything. It's mostly components. So migrating what you coded is pointless. What you wrote was only the mortar in a brick wall of components. That's why it was so inexpensive to get going so fast. And that's why it's always so costly to go to another system.
But that's not really true of a good component system. Because if it has the best components -- other component systems are inferior.
As a data for-instance: Oracle. I've found Oracle well, arcane and unpleasant when it comes to data migration. I'm not entirely sure why. Maybe it's the utilities that Oracle provides, with its arcane language. Maybe it's that BLOBs, CLOBs, VARCHAR, and VARCHAR2 all have to be changed. And they're most often, text and images. And what is an application without text an images?
Oracle Data Migration isn't a lot of fun.
But some data systems are downright simple to migrate. They export data in XML, export their data structures in SQL & DDL. That's great. It works. It works well. And it allows you to leverage data export into data communication.
The best of data systems make it easy to communicate. Because what's data without communication?
It's a trap.
All well & good. Data systems and structure are immensely useful to communicate. But component systems? Well, they're best when it's more costly to migrate them. Why? Well, take the building example. You have a steel building, and now you want brick & mortar. How much of the steel building will remain? Do you really want to communicate your components into another building?
It doesn't make any sense, does it.
A steel building was probably cost effective when you set it up. And now you want brick & mortar. All well & good, that's what you want. But you're not going to transmute steel into mortar. And your software alchemist isn't going to, either.
IBM's Domino component model is the same. It's not built to lowest common denominator. It's actually built to fairly high sophistication. So you're going to spend a lot transmuting its advantages onto another platform.
But the data ... well, DB2 and Domino are both pretty easy when it comes to extracting data.
So I often answer this way:
1. If you want to migrate data then sure, IBM, particularly Domino, can migrate data anywhere you want.
2. But if you want to migrate your code ... um ... you barely coded anything. It's mostly components. So migrating what you coded is pointless. What you wrote was only the mortar in a brick wall of components. That's why it was so inexpensive to get going so fast. And that's why it's always so costly to go to another system.