Don't you reconcile our data!



  • The project I am currently working on is about maintaining access rights data for a 100K-employees-bank. It is quite a big system, with a fat client app to maintain access rights (including such nice things as can-the-user-view-or-change-certain-customers-or-not), a middleware software that distributes this data to various target systems and application databases, and runtime libraries for mainframe (COBOL), Java code, as well as specific solution for third-party-software. The various intermediate databases filled by the middleware serve as a kind of "docking place" where third-party-software can fetch the access rights for their users. The whole conglomerate of software systems is operational for several years, and my project has completely rehauled the middleware to gain massive speed advantages, wanting to attain close-to-realtime updates of target systems. (previously, access right modifications could take a week to get operational).

    The architect had us implement a reconciliation feature, to be triggered manually (he talked about once every month), which would update *ALL* access rights of *ALL* users in *ALL* target systems. He said, this was required just to be on the safe side, if the middleware had any kind of glitches that could lead to inconsistent states, where users could have access to something but they really shouldn't, or vice versa. Implementing this reconciliation feature was a bit of a chore because it produced large amounts of updates which could only be processed over the course of several days. We then decided to give each update a priority, and reconciliation updates got the lowest priority, so they processed slowly in the background.

    So far so good. Currently, we are close to moving to production, and our architect left for a three-week vacation (a WTF in its own).

    Yesterday, his deputy came and told the team that said reconciliation process would never be executed, because they were afraid to override all the discrepancies between the source database and the various runtime databases that had crept in over the last years. They were afraid that thousands of users might call the help desk at once, complaining about missing access rights, that couldn't then be updated in the source database in short notice.

    It looks like their source database contains outdated access-rights instead of the needed ones, and their access-right-distribution-process was faulty for years. And now they are afraid to correct the situation? WTF?

    (I am an external consultant in this project. I think it is called body-lease)



  • Slow it down so it happens over a month instead of a couple days, that'll spread out the support calls. I AM FULL OF SOLUTIONS.



  • Trigger it by accident. Bugs happen you know ;-)


  • ♿ (Parody)

    @blakeyrat said:

    I AM FULL OF SOLUTIONS.

    Almost right.



  • @boomzilla said:

    @blakeyrat said:
    I AM FULL OF SOLUTIONS.
    Almost right.

    Piss and bile are both solutions, aren't they?

    Hell, he's probably got some venom and vitriol in him as well.

     



  • @blakeyrat said:

    Slow it down so it happens over a month instead of a couple days, that'll spread out the support calls. I AM FULL OF SOLUTIONS.

    We thought of that, but the current position is that they want to wait until a user is touched regularly, at which point it will be distributed anyway. Then he will be the only user to complain if he misses something. They say that over the course of organizational reorganizations, all users will be touched at least once a year. Really? I'm not so sure, but if that lets them slumber nicely at night, I'll be the last to stir the shit.



  • @Daid said:

    Trigger it by accident. Bugs happen you know ;-)

    Random users get reconciliated at random times? Sounds like an interesting idea. I'll have to think about that. :-)


  • @TheRider said:

    a user is touched regularly


    Tee hee.



  • @Schlagwerk said:

    @TheRider said:

    a user is touched regularly


    Tee hee.

    Don't forget @TheRider said:
    all users will be touched at least once a year



  • @TheRider said:

    We thought of that, but the current position is that they want to wait until a user is touched regularly, at which point it will be distributed anyway. Then he will be the only user to complain if he misses something.

     

    That introduces nasty side effects.  What if you just viewed the user and hit "save"? Then the user's acces is damaged and nobody knows why.  This is the I-didn't-touch-anything-problem.  They probably also won't discover the problem for a few weeks anyway as the discrepancies are probably in subsystems that aren't accessed every day.

    Better to just have the "accident" and then spend a few days of overtime patching it up for everyone.  If you've got some kind of log of before-and-after, then you can print the whole thing in 100-page chapters and give them out to an army of temps.


Log in to reply