A few years ago at a National Center for Database Marketing conference, a panelist said that the decision whether or not a marketing organization should build their database management functionality in-house often rests on the relationship between two people – the marketing chief and the head of technology. How does that dynamic play out in your organization?

Is their relationship collaborative and friendly? Then building and maintaining a marketing database in-house can work well. But if the two executives regularly engage in silo defense and turf-grabbing, then outsourcing may be faster, less stressful on the business, and offer you more autonomy.

Naturally, politics shouldn’t be a key factor in the decision. But it usually is because politics drives delay – and delay drives opportunity costs. You can successfully pull an internally-managed database solution into the station even if your CMO and CTO are ‘frenemies’. But it will take longer while they argue over who’s driving the bus.

How much incremental revenue, cost savings, or efficiency do you lose in the meantime? You need to figure it out, then figure it into your decision process.

I was once refused administrative rights to a database, due to a business rule that only the I.T. team members were qualified DBA’s. I challenged the rule, citing my assistant’s graduate degree in Computer Science and the fifteen years of database experience between
us. We finally did get our rights because we had the proper credentials, not because we were entitled to autonomy. If you don’t possess real qualifications within your team or have immediate plans to hire people with them, outsourcing is probably best.

You’ve got to put yourself in your tech manager’s shoes. A poorly written query against a database on a shared server could grind her production system to a halt. When the field offices suddenly can’t enter any new contracts, she’s the one who has to stand in front of the Sales VP’s desk explaining what happened, not the hapless marketing guy who set the whole thing in motion.

So give her a comfort level by talking like a DBA instead of a marketer. Which statement will be more effective in dispelling her fear?

a) “We should be able to control our own database – we know what we’re doing – you won’t be sorry.”

b) “I promise, I’ll never perform a six-table outer left join without a where clause or import a two million row table without proper indexing.”

If you know what (b) means, she will realize you’re aware of the type of bad acting that brings down servers and she has your word that it won’t happen on your watch. If you don’t know what it means, you should seriously consider outsourcing.

Consider safety and continuity. The server corrupts, the on-call junior tech loads the backup, which corrupts too, and keeps loading each previous backup until they’re all damaged. Or you discover that the backup failed every night for the last three weeks, but the failure notification went to the phone of an employee laid off last June. It happens. Tight procedures and consistent oversight help mitigate it, but the risk is inherent to any in-sourced solution.

Many consider outsourcing safer. But consider the October 2009 T-Mobile Sidekick debacle – a catastrophic database failure in which some vital client data was irretrievably lost. And the keeper of the data wasn’t some undercapitalized DB startup – it was Microsoft. They’ve since recovered a portion of the lost data, but confidence in outsourcing and cloud computing in particular took a definite hit.

Outsourcing data failures are fairly rare, and you at least have the option to sue. But either outsourced or in-house failure can cripple your operation and lose customers. You need to honestly assess how well your in-house staff can execute on database maintenance best practices, compared to the vendor’s ability to do the same, and use those risk factors in your decision.

PLAN B: TRAINING WHEELS AND TRANSPARENCY

If you definitely want to take your database operations in-house, and your tech team balks, you can offer to launch with “training wheel” rights and gradually earn your way to autonomy. Offer to:

 Accept read-only and row append rights to start.

 Submit all query coding to an IT manager for quality assurance prior to a live run.

 Schedule meetings to review server load metrics, table change requirements, and new data loads you need them to support.

 Call for advance clearance to append more than a 100K records into the database.

Give it six weeks and ask again. If you’ve been diligent, you’ll likely be granted full rights to manage your database. The tech department doesn’t really want to review your code, add more meetings to their schedules, or interrupt their day to approve your appends. They just want a comfort level that:

a) You acknowledge you are playing in their sandbox.

b) You won’t break anything.

c) You will be a good steward of the data.

No matter the relationship between your CMO and CTO, you can better develop your own relationship with IT by seeing things through their eyes.