Initially I think I should apologise for not publishing a blog last week. The reason it didn't get written was because I ran out of week (in the UK Good Friday is a public holiday).
But on to the main topic of this weeks blog – why we need a DMZ (De-Militarised Zone) – I have a couple of insights to share from engagements I have been doing recently.
Perhaps before I go much further however I need to define the DMZ as far as Practical Data Migration (PDM) is concerned.
he DMZ is a new addition to PDM (v2 of which will be formally launched at the DMM3 event in May). The DMZ is "The neutral area between the technology provider and the wider business". In large projects the function of managing the physical aspects Data Migration is usually contracted out to a Systems Integrator (SI). However there are all sorts of inputs that are required that only the business can provide (like a semantic understanding of legacy data). Therefore a DMZ is erected. Often it is embodied physically in a staging area where the business puts the data to be migrated. The SI picks up the data, validates it, loads it and puts any records that fall out back into the staging area.
However the SI will also, explicitly or implicitly define a DMZ in the contract. It is normally couched in the terms of the expectations the SI will place on the contracting business in terms of the timing and quality of the data to be loaded, but there are also expectations of support etc.
All this is very reasonable. On a fixed price contract the SI cannot be expected to bare the cost of delays for which it is not responsible and over which it exercises no control. Last week I was reviewing just such a contract for a client. The key to getting the right deal for both parties lies in being precise about the exchanges that will take place over the DMZ and being generously accurate in the estimations of time needed to get the data ready and faults corrected. No point in being over optimistic on either side, better to get the budget for a well run programme than be arguing about additional work at time and material rates when project deadlines are looming.
Also this week I have been engaged on the first of our accreditation programmes for PDMv2. A large software vendor is coming to market with a new Data Migration product. They have asked that their best practice approach be accredited for PDMv2. Working with their process designer I was struck yet again by how appropriate the DMZ concept is. Like any new software theirs has its own unique selling points. To get the best out of them means using the product in a way that maximises these strengths. However, just as in the case of the SI, there are also problems, for instance with Business Engagement and Programme Management, that are common to all Data Migrations. Here it makes sense to take advantage of PDM’s features that are proven to deal with these things rather than re-invent.
So what I have been doing this week is marking out with them the DMZ around their product's method and working out where it will fit into a PDM style project. It has been an interesting few days – with more to come I'm sure as we push back and forth at the boundary between PDM proper and their software.
As to who they are? Ah ha! For that you will have to wait for DMM3! (Along with the launch of PDMv2).
Talking of which the call for papers on Data Migration Pro is now closed and we will be evaluating the submissions. I'll let you all know how we got on next week.
