It is great to see some more detail of the recent Bloor research into current Data Migration practice appearing. This time in a paper sponsored by SAP. I especially like this paper as it gives me the opportunity to say 'I told you so' loudly. This may not be an especially endearing trait but, heck I am only human.
The theme of the current white paper, which for all the facetiousness of what follows, I recommend you read, is the importance of business ownership of Data Migration projects.
Well blow me down - to think that Golden Rule number one in Practical Data Migration (published 2006) was 'Data Migration is a business not a technical issue'. Seemed contentious at the time but looks like the world is beginning to catch up with me. As Philip explains 'If you are migrating from one application environment to another... you are doing it for business reasons'. This is a truth often forgotten. In a classic means-end reversal the business driver becomes suborned to the technical delivery. Of course it goes deeper than that. It is not just the reasons why you are performing Data Migration, it is also how you are going to succeed that is so business dependent. As Philip acknowledges we need business experts in the data as well as technical experts to succeed.
We are also told that '100% accurate data is not obtainable and even if it were it would be prohibitively expensive', which echo’s Golden Rule three 'No company, needs, wants, or will pay for perfect quality data'.
As Shakespeare put it 'Vex not my prescience'. I was beginning to feel properly vindicated by now.
Finally when I read that it was important to set targets for data quality and monitor them via dashboards I almost shouted out loud 'Golden Rule Four - If you can’t count it, it doesn’t count' and 'That’s the DQR process you are talking about' (my apologies to the other commuter on the 7:32 Huntingdon to London Express for the agitation in carriage B).
There is of course much else to read in this report. I do not intend to recapitulate the entire contents here so I shall merely cherry pick the odd item and spit out the cherry stones of knowledge at the page.
It was interesting to see that Philip identified software suppliers with their own consultancy arm as being better than 'Pure play' systems implementers. The advantage is marginal with 59% no overruns to 52% respectively. Philip suggests that this may be related to the advantage the vendors have in knowledge of their own software. I, from experience, also think it may be something to do with the positive incentive the vendors have from seeing their software implemented and running smoothly as oppose to the perverse, negative incentive for SI’s in projects that overrun, providing the reasons can be shown to lie on the Business side of the DMZ.
Philip also makes some very good points about the benefits of taking the value of the data quality and data governance lessons on from the Data Migration project and into the in-life running of the target. A point I have been banging on about on various forum for a while. Within Data Migration we have the compelling event of the immanent demise of a strategic system to grab the attention of the business. Used properly, PDM will have built up a virtual team with the skills to carry on data quality enhancements. We will have a complete list of the nasties in the new system that, given the time constraints of a Data Migration, we could not fix. How often have I held all these valuable items in my hands (metaphorically) only to leave them on the table as I head out of the door to my next project with no one picking them up?
I was wryly amused by the paradox of identifying the importance of business involvement and linking that to migration tool selection. Philip does this by suggesting that the tools should be of the kind that are business friendly. Perhaps he had Business Objects in mind (which, of course, began life as an end user Business Intelligence tool not a data quality or ETL tool)?
And talking of SAP, or more especially their ASAP methodology, I should be getting exposure after the summer holidays to how this has been extended to include the Business Objects tool set. As you know I have been critical in the past of ASAP as a Data Migration as opposed to a system implementation method. Of course if anyone from the SAP community wishes to enlighten me earlier, my contact details are at the bottom of the page. But it seems that SAP is making a real effort to get to grips with Business Engagement in Data Migration for which they should be applauded. Perhaps they could start by buying a copy of Practical Data Migration.
There again possibly they already have!
The white paper is available from the Bloor website and is well worth reading.
