Projects of this nature are very, very tricky, even with full management
buy-in. I just spent the last 7 years at a University with around 23K
active users (depending on where we were in the academic calendar) so have
some familiarity with how the .edu environment makes IT hard. And we were
blessed in that we didn't have either a Law School or a Hospital, two
entities big and complex enough to guarantee a very separate IT
environment, to complicate matters.
More abstractly, what you're dealing with is how to merge various
databases with different database schema and potentially lots of
duplication. Creating a master coordination database is how this is
usually solved, and create methods for the master database to work with
the in-area databases. That's the view from orbit.
Where projects like this fall flat on their faces is when the various
account database owners can't come to an agreement for how data should
flow through the system (also known as failing to modify existing business
practices to fit the new model). You will need some kind of primary key to
disambiguate users ("Meg Odonnel" = "Meghan O'Donnel", that kind of
thing), and if everyone can't agree to what that could be then you're
stuck with manual disambuguation. If everyone can't come to an agreement
over who owns the 'Fullname' field and how updates to that field, or other
key fields, need to get disseminated, then things get exceedingly
complicated.
This is the 'management buy-in' we've been talking about, since this is a
busines process not an IT process.
Things that will make your job a LOT easier:
* A primary key. Sounds like your students have one, but your employees
may not.
* Automated ways to get and send updates to the various account
databases. Gaining this access may be a political process of the first
order.
It's still possible without the above, but it's a nightmare to maintain.
Without a primary key you'll end up writing your own disambiguation logic,
as well as the exception-handling logic when the inevitable collisions
occur (with 23K users we generally had more than three 'John Smith'
students at any given time). Without automated ways to at least fetch
account database information, you're stuck with batch-mode data analysis
at best, or just plain out of luck at worst. Lacking update rights means
introducing humans into the workflow, and coding around the inevitable
excpetions that'll creep in as a result of that.
These kinds of systems are very, very, VERY nice to have, and are a worthy
goal for any organization of size. The trick is convincing all of the
stakeholders that this is the case and getting them to work together. In a
highly decentralized system such as yours that's a job that belongs well
into the Management layer, but at least you can get the ball rolling.
--
Law of Probable Dispersal:
Whatever it is that hits the fan will not be evenly distributed.
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
