Tuesday, May 30, 2006

the data we hold

Funny (not ha, ha) how this DOPA business and all the news about the stolen laptop that held all this VA data, makes us (me) face some of our technical limitations, some of our past decisions, some of our core values and some of our new endeavors...

Interesting how we can be expected to apply all kind of regulations on as varied a population as we serve.

It's clear for us that we do not have enough data to ever dream of implementing AGE based policies. Our ILS does not currently have a useable BIRTHDATE field. It has had a BIRTHYEAR field forever but it never even was either required or verified so we have some users with no entry there, some with 2 digit entries there and some with 4 digit entries. Of course, the full, useable BIRTHDATE field will be available to us very soon, but to have the field does not solve the problem, you need to POPULATE this field with accurate data before you can use it....

"The technical infrastructure that makes something possible is only the first step of a long process to make something usable." from Roy Tennant, TechEssence.info

Now, if we decide (are made) to gather birthdate info, we will have and hold 2 of the 3 essential parts required for ID theft.

I was thinking maybe we can devise a sensible workaround and gather month and year in separate (verified) fields, without having to know or keep the DAY part. Of course this would require substantial manipulation of the db on a regular basis, but that part can be automated...

Why not seek YEAR XXXX+ MONTH XX and use this to populate a separate Majority: Y/N field? That Majority field can be used to "enforce" certain policies and/or laws.

That way, should (--warding evil eye sign--) our data get compromized, we have exposed our users to much less risk than if we had had a full birhtdate in our records...

More to come on this.

technorati tags:,, , ,

Thursday, May 18, 2006

not easy

A little Friday Philosophy...

It is not going to be easy!, I keep saying it to everyone I train, meet, talk to about emerging technology. We can't expect that it will go down PERFECTLY. Not when we innovate! It can be fun though... We must learn to appreciate and enjoy the process.

Things have been a little difficult lately at MPOW. I don't know if it's just too many changes at once, not enough comfort throughout. Personally, just like everyone, I have felt like stepping back a little. But it really doesn't help if we start some great project, and abandon it as soon as we encounter a difficulty ( read:one person complains or one thing doesn't work as well as expected.)

Thriving. I love the word. Personally, I thrive on success. I am a troubleshooter, it's in my blood, and nothing makes me happier than seeing it fixed after it was broken. That's success right there! But I also thrive on innovation, and that often takes me to the opposite side... Yes, I love to break things too. In a sick twisted way, that in itself feeds into my 1st passion right? Now that it's broke, I better fix it...
It's a vicious cycle,
no, it's a vivacious cycle.

technorati tags:,, , ,

Monday, May 01, 2006

Going away angry anyone?

Seth Godin post a brilliant snippet about policies.
Not only does he make a great point, and share a good idea; he also succeeds in getting you to relate to the topic right from the start. (Story tellers will rule the world one day, I swear!)
Who has not lived thru one of these as a customer? Libraries (some) are intent on writing policies, as soon as ONE event or customer steps off the beaten path. We love policies. I want to speak up, (really, sometimes I want to scream!) each time I see pages and pages of minute, complex, "overthought" narrative trying to predict every single possible scenario relating to the use or feared abuse of one of our resources. We do this with the best intentions too. We want to ensure fairness, prepare our staff for all possibilities, remain ready for all eventualities etc., etc., etc. Right now, trying to justify the creation of a MySpace account for MPOW... Well, this will require a policy right?

Really, then when we start trying to "empower" our front line staff, we end up writing layer after layer of exceptions, increasing complexity and good reasoning each time.

I do enough training to know what it can do to a new employee. Here the rule, here's how/when you should break it... Frankly I would rather spend my time making sock puppets.

Why not THROW AWAY the rule once it no longer serves a purpose, or if it never did.

technorati tags:,, , ,