The momentum is building this week and next as we rush into autumn with more and more Data Migration projects coming into view. Seems like I'm forever in transit from one project initiation session to the next.
Had reason to dwell this week on the interesting issue of how, in large data migration projects there is always a tension between central control and local autonomy. On the one hand we need to control cross programme issues, but on the other we will not succeed unless each tier is allowed to express their needs and interpolate their specialist knowledge into the programme.
It is also all very well insisting on a strong centre that can impose discipline on local activity but this not always possible. The co-operative model in place of the command and control model is going to become increasingly the norm as we move towards greater openness of access across enterprises with the use of SOA. But even within "traditional" migrations there are times (de-mergers are the obvious example) where two (or more) legally separate entities with wholly different management structures need to act together to get the right data to the right place at the right time to an appropriate level of quality. Now, ok, we can build a legal frame-work around the activities ("can?" of course we will), but, as anyone with any experience knows, going back to the legal details is the last resort. When you get to reading the small print of a contract to solve problems then you known your project is in big trouble.
So what mechanisms can we use to manage these sorts of programmes? Aside from the basics - shared plans, regular meetings at all levels of executive sponsorship etc. what do we have available to us because of the particular nature of a data migration project? Well there are shared schema's and data preparation experiences. Can we leverage more value from them? Both in terms of re-use and in building those relationships that will make the project fly. And what about more general Data Quality Rules activity? Can we set up a composite DQR board that maybe sits above the individual boards of the individual projects? And what about adapting our System Retirement Polices? Of course what we have to do is critically examine our Key Data Stakeholder analysis to expand the number of roles to include those needed to manage cross boundary understanding as well as cross boundary issues.
What we should not expect is that there be any mention of this in the legal document itself, but maybe there's someone out there with different experiences?
Finally I would dearly love to announce the next in our line up for 29th November. A date that I am sure you all now have firmly inked into your diary as the evening when we will get together to discuss data migration in all its many forms. And I am very excited about the person I will be announcing next week - I'm just waiting for his bio so I can do him justice. His is a well-known name in his area of ICT and he has been on the receiving end of many migrations over the last 20 years. He will give us the view from the top as a customer.
I am also close to announcing the sponsor of the event so watch this space!
