- Pekinduck
- May 10, 2008
-
|
This is actually true; SSA IT infrastructure is incredibly ancient and jury-rigged,
I don't want to distract from the main purpose of your thread, but any good anecdotes?
|
#
¿
Nov 1, 2023 04:16
|
|
- Adbot
-
ADBOT LOVES YOU
|
|
|
#
¿
May 10, 2024 07:10
|
|
- Pekinduck
- May 10, 2008
-
|
So, SSA IT.
First off, let me say, since this is the only government job I've ever had, that a lot of people who scoff about "government IT" are being somewhat unfair. I've seen a lot of terrible, outdated IT in the private sector too. And I've also seen IT that looks primitive as hell but never got updated because it never needed to; greenscreen DOS stuff for industrial equipment that flawlessly does the seven things the machine needs, and would only get less reliable and more complicated if you tried to modernize it.
Yeah, people often have a knee-jerk reaction to replace old systems that work fine for their intended purpose and won't be improved by modernization. A computer science professor shared an example he was involved with: Delta or one of the big airlines wanted to explore rewriting their mainframe-based flight scheduling system to something more modern. Everything had to be transferred over seamlessly, no downtime acceptable. They hired a consulting company who looked at everything and said it can be done, for 300 million dollars. The benefits would have to be enormous to justify that.
So, SSA IT.
First off, the backbone. SSA systems run on more than 60 million lines of COBOL, and require mainframe inputs for very simple transactions at the most basic user level, which are batch processed overnight. This means that there are no instantaneous changes, and that overnight processing, due to having a very specific order of processes, sometimes means your inputs won't show up for 2-3 days even. Purpose-built (sometimes decades old) programs each line up for their pass at the data for the purpose of their very specific task. Any changes in Social Security law that may change the calculations we make (or classes of individuals) is incredibly expensive and error-prone to program for.
At the basic user level, we run two green screen terminal emulators using IBM Personal Communicator. You make what are essentially coding inputs (and for certain classes of benefits they were never able to fully automate, such as SSI couples' cases, they are literally coding inputs). If I showed you a person's Master Benefit Record (MBR- their record for Title II benefits such as retirement/disability/survivors), or Supplemental Security Record (SSR, the same but for Title XVI SSI/welfare), it'd look like complete Greek to you. That's because none of it is in plain language.
By the way, those two records use different codes. You have to learn how read both types of codes just to answer a person's basic questions about their benefits. That's why it's generally accepted that it takes three years to train a Service Rep to any kind of proficiency. For what is basically a data entry/customer service job.
So here's a worst case scenario. A man and his wife who both are on SSI want to change their address to the house next door. In a normal GUI, you'd just make like a maximum of three keystrokes or clicks to get to the address field, right? And just turn that "666 Hellfire Lane" into "668 Hellfire Lane".
But in our systems, I open up PCOM, navigate to the correct screen, and type in the following:
(person's SSN) + C, enter
BC7(routing number)(C for checking account, S for savings)(account number).AD668 Hellfire Lane.AY7Mobile.AT7AL.ZP736602.RA668 Hellfire Lane.AY7Mobile.AT7AL.ZP36602.TL7(phone number).LA701480AA.
You may think that you can skip typing the bank account, because that's not gonna change, right? Well, the input will look like it works. And then it will never change. And then you have to look up the error code a day later (overnight run, remember?), find the error code, and then look it up to realize that actually yeah, it doesn't work if you try to change the address without also typing in the direct deposit.
Dumb poo poo like that. Basic rear end inputs that take far too long to make, train, and verify.
That's wild, thanks for sharing. I imagine the batch based system could be hard to change, but surely they could put a more humane UI on top of it?
|
|
#
¿
Dec 23, 2023 21:13
|
|
#
¿
Nov 1, 2023 04:16
