'Disintegrated' IT didn't help financial crisis

Financial institutions looking to ramp up their risk management capabilities through technology must ensure their IT implementations take on a holistic approach. Doing so could also have prevented the financial crisis from erupting.
Despite having access to IT tools such as analytic applications to flag incident exceptions, the financial industry and its regulators were challenged by various technical and other issues during the crisis, experts told ZDNet Asia.
Irving Low, head of internal audit, risk and compliance services at KPMG in Singapore, said in an e-mail interview that "disintegrated IT systems" were the reason technology faltered in the face of the economic downturn.
Financial organizations that did not properly integrate their IT systems across their various businesses, and had risk management applications running on different systems, received information that was incomplete for effective risk monitoring and decision-making, Low explained.
Neil Katkov, senior vice president of Celent, a research firm specializing in the financial sector, said such systems failed to look at multiple scenarios--in particular, the crash of the credit default swap (CDS) market that occurred around the subprime mortgage crisis in the United States.
"Each system tended to look at one area. They did not tend to look at a pileup of multiple issues," said Tokyo-based Katkov in a phone interview.
It is essential to implement multiple products and lines of business into the systems, and have these systems collect relevant information across the organization, he said. "Firms that don't have that yet should get that done," he urged.
Intervention of humans
Another reason for the current financial crunch, Katkov said, involved the "human decision" factor.
"Simply put, you can have all the technology and models in place, but if the company [still] decides that [a risky undertaking] is a business it wants to be in, it will determine that this is acceptable and continue to do that business," he said.
Low described this as a lack of balance between risk appetite and risk control.
"The thresholds set for the red flags may not necessarily reflect the actual risk appetite, and as such, decision-making or escalation of a 'red flag' incident is often delayed," he explained. "High-risk behavior may then be allowed to proceed unhindered."
Katkov noted that before the crisis erupted, there was a boom in the financial markets, during which "people do not tend to put on the brakes, [choosing instead to] go along with the good times".
According to Low, when financial institutions implement their IT strategy for risk management, they should also consider a more holistic and integrated approach. For example, they could leverage existing IT functionalities to integrate fragmented governance, risk and compliance programs.
"In the process, they would be strengthening their internal control structures," he said.
He suggested that financial organizations also embed controls into their day-to-day financial, operational and regulatory processes, using available governance, risk and compliance systems.
"This enables the continuous monitoring of risk using alerts generated from pre-determined business rules," Low said.
With IT playing a greater part in risk management, IT professionals should also demonstrate an understanding of the peculiarities and unique needs of their companies and the industry. This way, they can better advise business users how to optimize existing IT risk management capabilities, Low said.
"They should show an appreciation for the underlying business policies, rules and risk management and business frameworks, such as how Basel II can be supported by IT."
But while Katkov agreed a conceptual understanding of what is needed in risk management would go a long way for IT to support financial risk management, he noted that risk modeling is a very "deep and technical field".
"So it would be unreasonable to expect IT professionals to know the ins-and-outs of everything," he said.
Instead, he noted that since the IT department will be responsible for implementing an enterprise-wide system, a business analyst can work with IT to provide insights into the business requirements for the IT systems.
"It needs to start with a risk management division that realigns its risk management approach, including which products to monitor and what type of risk models to adopt," Katkov said. "That will then have implications for the types of systems or data integration that needs to be in place."
READ MORE - 'Disintegrated' IT didn't help financial crisis

Keep project scope small for success

Negativity can kill a project, but the opposite is also true: You can stuff a project with so many features that it's crushed by its own weight.

A common objection to a project plan is that it doesn't do enough--it doesn't have all the features that users will inevitably request, or it doesn't take certain situations into account.
Or as TechRepublic member biancaluna recently put it, it "does not solve world hunger nor does it wash my car or bake a pecan pie". But in my experience, those omissions argue for it rather than against it. Certainly, you don't want to preclude features that will be needed in the future, but if you try to anticipate all of those features in the initial design, you'll never complete that phase.
Rather than designing in everything from the top, start small but make your design modular and extensible.
In my response to biancaluna's comment I said: "In the future, whenever someone tries to shoot down an idea because it doesn't do enough, I'll say 'DNSWH'." Does Not Solve World Hunger. It's also a good response when someone is trying to pile on the features.
A company I used to work for had a long history of cowboy coding--that is, "we need feature X, so just go code it up." Naturally, after several years, this resulted in an unmaintainable mess; they got design religion and began requiring a lengthy design process before any code could be written.
To insure that nothing important was ever left out, they held daily design meetings involving a dozen or more people--each of whom was trying to impress everyone else with how many nits they could pick. Only a handful of projects ever emerged from this phase after months of bickering, and those projects went on to become bloated applications with so much feature noise that they were almost unusable.
What's even worse is that the projects didn't solve the original problem, which was to keep existing customers happy and to draw new customers in; instead, they focused on solving world hunger.
A number of times in my consulting career I've had clients want to ditch their product and start over from scratch. Perhaps the UI looks "old" and needs to be redone; or the code is so mangled that they think it is beyond hope; or they've hired someone who thinks that a certain language or framework is the philosopher's stone that will magically turn their applications to gold. These projects almost never succeed.
Why? Because they're too big. Yes, you can certainly recreate that application in Ruby on Rails in a fraction of the time spent on it to date, but do you realize how much time has actually gone into it? Chances are it's in the hundreds of thousands or even millions of hours. Even if you can develop ten times faster than the original, do you have several years to do this?
Sometimes it's easy to mistake how big these projects really are because their requirements aren't fully known. The projects have evolved over many years, and features are sometimes added without being documented; yet users rely on that behavior, and if you take it away, you're going to end up pasting it back in. Do that enough times, and your new, pristine version will end up being the same mix of baling wire and bubblegum that comprised the original.
It's almost always a better idea to make incremental improvements instead. That requires long-term vision of where you want to get someday, without trying to do it all at once. Lay out a general plan for the future, and then create a specific project to do just the first step. That helps to minimize the risk of failure and keep the project scope manageable.
It's easier to agree on the design for something that does only one thing well--and it's easier to tell when it doesn't. More importantly, you can get user feedback before you proceed to the next stage.
Trying to do too many things at once multiplies your chances of project failure. One company I worked for back in the 80s provided turnkey solutions--that is, they wheeled the system in, and all the user had to do was turn the key. The vendor provided the hardware, the operating system, and the software.
One bright day, the vendor decided to upgrade their database architecture. To do so, they needed a new version of the programming language and its runtime environment. That version was only supported on certain operating systems, so an OS upgrade would also be required for most users. The applications (mostly accounting) still needed regulatory changes, and they felt that they couldn't go a whole year without adding some enhancements as well.
To keep things "simple", they decided to do all this at once--to more than 1,300 supported users. It would be great--what could possibly go wrong?
The OS upgrades ran into hardware support issues. The language runtime was still pretty green on some platforms and introduced a massive number of failures--none of which showed up in QA, of course. But certainly a redesign of the database architecture should have been a simple task, right? No. Application bugs abounded due to touching just about every module.
The support lines were overwhelmed. Extra people manned the phones, including all the programmers. As a result, it took a long time to fix the issues. Meanwhile, we'd go home at night only after we attempted to call back every customer who had logged a call, but by then it was so late that they had given up on us--this added up to more than 700 users every night for months.
Did we keep all of our customers? No. Did we add any new ones? No, we tried to solve world hunger instead.
In retrospect, we should have taken on only one thing at a time. Upgrade the language runtime on one platform only where we already had users who wouldn't need an OS upgrade. Don't touch the database or the code until that's stable. Continue one platform at a time until the new runtime version is gold. Then look at changing the database--but only a portion of an application at a time.
Taking this sort of measured approach, we would have been able to slip in regulatory changes and even some small enhancements along the way, without breaking the customer's back.
For us consultants, limited scope is one of the key benefits of short-term contracts. In, done, out. But we can apply the same principle to long-term engagements as well by dividing each project into bite-sized chunks.
When a project looms massively before you, ask how you can cut it up so you won't choke on it. Identify the optional features and move those to the end, where they can be lopped off if you run short. Don't try to solve world hunger--feed one user need at a time.
READ MORE - Keep project scope small for success

S'pore Nissan facility goes RFID

SINGAPORE--A new Nissan hub is tapping radio frequency identification (RFID) technology to help cut time for identification and retrieval of new cars, from an average of 24 hours to two hours.
Located in the Western part of Singapore, the new TC Nissan Hub operated by Tan Chong International is believed to be the first RFID-enabled automotive facility in the country. Tan Chong International is the exclusive local distributor of Nissan vehicles.
Tan Chong's project was awarded a grant of S$120,000 (US$82,632) from Singapore's National RFID Centre (NRC) earlier this year, under the NRC's S$4.5 million (US$3.1 million) RFID Innovation Platform initiative. To date, the Centre has funded 11 projects to the tune of S$1.25 million (US$860,750), an NRC spokesperson told ZDNet Asia.
Boon Swan Foo, chairman of NRC steering committee and executive chairman of Exploit Technologies, said the RFID application projects do not necessarily have to be on a gigantic scale such as Wal-Mart's.
"The possibilities for new applications are left up to the creativity of the beholder [and] TC Nissan Hub is an excellent example of how such creativity can be exercised by innovative RFID players to benefit both the consumers and the company," Boon said Monday at the hub's official opening here.
Singapore's Acting Minister for Information, Communication and the Arts Lui Tuck Yew, lauded the project as "a good demonstration of local RFID technology capability". The systems integrator, applications developer and device manufacturer were Singapore companies, he noted.
"Newer", faster cars in one-stop facility
Samuel Lee, director of Tan Chong Realty, the company's real-estate arm, said the company had invested S$40 million (US$27.5 million) into the new site, which integrates storage, pre-delivery inspection, parts warehouse and delivery facilities.
RFID tagging system in TC Nissan Hub
Source: Tan Chong International
Prior to the setting up of the hub, new vehicles would have to be manually located in storage locations, sent for installations at a separate venue--after which they would be returned to the storage site--and subsequently delivered to the showroom for customer pick-ups. The point-to-point transportation, identification and retrieval of these vehicles can "easily clock" some 24 hours to complete, Lee explained, in an interview with ZDNet Asia.
With the proximity of various Nissan facilities, as well as the RFID-enabled car inventory management system, vehicle identification and retrieval can be shortened to two hours, he said. Mileage is also reduced by 90 percent, from an average of 50 kilometer (km) to less than 5km.
The use of a Japanese modular parking system also allows cars to not only be retrieved quickly, but also helps minimize--if not eliminate--scratches and dents.
At the hub, each new car is tagged with an RFID chip, which captures information such as the year the car was manufactured, its engine serial number, color and type, and the name of the customer who made the booking. There are also corresponding active readers on each parking lot known as "lot tags". The hub has 10 wireless readers used to track vehicles, including cars that need to undergo installations for additional features such as sports rims and alarm systems.
RFID technology is not a new proponent in Nissan's operations. According to the RFID Journal, Nissan North America announced in 2006 it would employ RFID in its Canton, Miss. factory to track auto parts and facilitate new vehicles rolling off the assembly line. The automaker also participated in a trial to improve the safety of Japanese schoolchildren in Yokohama, Japan.
READ MORE - S'pore Nissan facility goes RFID

Cisco CEO: 'Video is the killer app'

READ MORE - Cisco CEO: 'Video is the killer app'