Confessions of an IT Manager_Phil Factor
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Section III: S<strong>of</strong>tware Projects: the Good, the Bad <strong>an</strong>d the Pitiful 119<br />
that this new MDM (Master Data M<strong>an</strong>agement) strategy is just a rearr<strong>an</strong>gement<br />
<strong>of</strong> the furniture to sell the same old apartment.<br />
Boss:<br />
<strong>Phil</strong>:<br />
Boss:<br />
<strong>Phil</strong>:<br />
Boss:<br />
<strong>Phil</strong>:<br />
So what is the purpose <strong>of</strong> this document? It doesn't provide<br />
information.<br />
[shocked]: Th<strong>an</strong>k goodness! <strong>IT</strong> business documents aren't there to<br />
provide 'information'! They are there to provide cover <strong>an</strong>d concealment<br />
for our real activities.<br />
Come on <strong>Phil</strong>, don't be so silly, <strong>an</strong>d just rephrase the entire document<br />
so that ordinary mortals like me c<strong>an</strong> underst<strong>an</strong>d it. Tell me what it<br />
me<strong>an</strong>s as though I was a chum at the golf club.<br />
[apprehensively]: Are you absolutely sure you w<strong>an</strong>t that?<br />
Of course, get on with it m<strong>an</strong>!<br />
[gulping nervously]:<br />
OK …<br />
Once upon a time, <strong>IT</strong> departments used to appoint someone to keep<br />
tabs on what data was held by the comp<strong>an</strong>y, what the business<br />
understood about that data <strong>an</strong>d the sort <strong>of</strong> processes that happened to<br />
that data. This person, usually a grizzled Systems Analyst (or Data<br />
Architect), would ensure that there was a common underst<strong>an</strong>ding <strong>of</strong> all<br />
the real entities involved, such as customers, products, employees, <strong>an</strong>d<br />
the processes that acted upon them, such as releases, recalls, invoices,<br />
<strong>an</strong>d so on. He would maintain a document, usually called a Data<br />
Dictionary or Data Model, which could be read <strong>an</strong>d understood by<br />
<strong>an</strong>yone, <strong>an</strong>d provided a basis for each individual <strong>IT</strong> project. Any<br />
misunderst<strong>an</strong>dings were soon ironed out, <strong>an</strong>d the activity was <strong>an</strong><br />
essential part <strong>of</strong> strategic pl<strong>an</strong>ning.<br />
When the cyclical downturns in <strong>IT</strong> happened, it became tempting to<br />
get rid <strong>of</strong> this chore. The Data Architect, or whatever he was called, was<br />
packed <strong>of</strong>f with <strong>an</strong> ornamental m<strong>an</strong>tel clock under his arm, <strong>an</strong>d there<br />
seemed to be no dire consequences. It all seemed painless. The integrity,<br />
<strong>an</strong>d shared underst<strong>an</strong>ding, <strong>of</strong> Corporate data didn't seem to be <strong>an</strong><br />
import<strong>an</strong>t asset after all.<br />
However, with mergers, acquisitions <strong>an</strong>d restructurings, m<strong>an</strong>y<br />
enterprises, including our own, have struggled to keep a consistent
Change language