Our column on the Government Service Insurance System’s computerization problem (GSIS’s Big Bugs, 12 June 2009) received a number of comments from readers that we are sharing today.
Wilson (wyl5326@yahoo.com) sent us his rather lengthy but still worthwhile view on the issue. Here is what he says:
“I’m an IT consultant with 30 years experience who’s read about the GSIS’s computer system problem. Even without knowing all the details, it looks like GSIS may have been dealing with Questronix without ensuring IBM’s technical support.
“DB2 is a very solid software used all over the world which can support very humongous amounts of records in a very short amount of time when combined with the right hardware to run it. The world’s top financial institutions rely on [DB2] without having too many problems.
“The problem could lie between the hardware that [GSIS is] using and the software that was installed to run with DB2. Any … mismatch in specifications when they were installed could have brought down the system.
Unclear roles in handling technical problems
“IBM does things by the book and won’t lift a finger if you’ve never signed a contract for technical support from them. I’ve had that experience before Y2K way back in 1997 even when my company had an arrangement with IBM that unfortunately did not specifically include the kind of support information I need.
“They did not allow us to contact the proper person who could have helped me then, but I got help from someone who’ve had the experience of running the specific program I was trying to run. After about 30 minutes of discussion with this outside person, the problem was solved.
“I understand that GSIS was running their DB2 in support of another software application from SAP. SAP programs have been widely known to be very hard to install and that is why SAP consultants command premium rates, higher than IBM consultants!
“Then there is another thing that puzzles me. If [GSIS] encountered this problem just with the new version of DB2, why not use the older version to continue the processing? We call this the rollback of the software update. Was there ever a comprehensive testing before they went into full blown production? There are too many technical questions that make me doubt the competence of the people who were contracted to implement the computer system.
“I’ve never been an IBM employee and have never worked for them, but have always been using the IBM system throughout my IT career. So blaming IBM for the debacle at GSIS is just not right. I know for a fact also that SSS [Social Security System] has a ticking system time bomb that we were aware of about over 20 years ago and IBM has nothing to do with lousy design.
“Members’ contributions were not accurately reflective of actual contributions, because the design of their system was flawed then. I don’t know if this has been corrected since, and that’s why we were encouraged to apply for a salary loan even when we didn’t need it just to verify that your actual contributions were all properly accounted.
“At that time, many contributions were not attributed to the right employees by virtue of human data entry error that was not detected at time of coding when SSS number had minor shifting of digits. When that happens, sorry to the poor guy whose contribution will not be attributed to his record! GSIS’s problem could be similar to the inherent defect at SSS before.
Incompetence is underlying cause
“Another thing that adds significance is IBM Canada agreeing to provide a special build for GSIS. This clearly points to the fact that the software acquired by GSIS was designed with special codings that are not standard in most installations where the DB2 was used. It is like someone is putting unique codes not meant for standard DB2 installations.
“This all boils down to incompetence of the integrators and GSIS staff who probably lack the technical abilities to do it themselves and never conducted an intensive testing before going on live production.
“Don’t immediately believe the spokesmen of incompetents when they are blaming someone or looking for a escape goat.
“The more I know the details of the problem, the more I believe there are problems between the hardware and how the software was installed that caused the repeated crashing of the system. Repeated recurrence of this problem only confirms the incompetence of those who are running/maintaining the system. Isolating the problem is time consuming, but the fact that the integrators failed to restore the data before the changes were applied, points to their incompetence!
“DB2 is a hardware hog and if they did not provide adequate hardware updates, expect the hardware to get overloaded and crash. That is very significant considering the fact that the problem gets worse over time, most likely pointing to hardware inadequacy.
“Unfortunately for GSIS, they didn’t have a direct contract with IBM for technical support of the product, even when they have a legitimate license. That is the way how IBM works and I’ve been there.
“If they have a technical support contract with IBM, then IBM is obligated to send in their men to find out what caused the crash on site, instead of just remotely looking at what was relayed to them!”
Fixing the problem must be the priority
Jestar Joe posted the following on the BizLink’s Philippine Star online blog:
“In their desperate rush to save their corporate status from damnation and humiliation, i.e., GSIS to its members-pensioners, and IBM to its partners and competitors, they will both be [paying for] costly legal [fees] rather than working jointly or creatively to fix the problems.
“What an expensive way of settling the issue! When nobility and pride are partly at stake in their respective suits, this can be compared to a singing contest. But here, the sure winners are their legal counsels. And the aching members-pensioners ending up as slave fiddlers.”
Lastly, another reader posted this on the column’s online blog:
“It’s in the design of the system, not DB2. DB2 has been known to handle millions of records. Suing each other should be the last resort... fixing the problem for millions of members should be the priority.”
www.CollegiateChampionsLeague.net
Watch this space for updates on the 2009 Philippine Collegiate Championship Games or visit www.CollegiateChampions League.net.
Should you wish to share any insights, write me at Link Edge, 25thFloor, 139 Corporate Center, Valero Street, Salcedo Village, 1227 Makati City. Or e-mail me at reydgamboa@yahoo.com. For a compilation of previous articles, visit www.BizlinksPhilippines.net.