Watching the Facebook IPO and followed by all the Morgan Stanley, NASDAQ and other parties bickering, pointing fingers and preparing lawsuits reminds me of many of the struggling IT projects that I have assisted with as a DB2 consultant. The failures of the Facebook IPO show how having unaligned interests always leads to failure. Even though I don’t know the technology used for the NASDAQ, or any of the companies involved, the following discusses some of the reasons why I believe there many classic DB2 performance lessons to be learned from this high profile Facebook IPO failure.
The Facebook IPO was doomed since it was much bigger than any other IPO. Everyone knows that proper capacity planning and sizing are the first rule for any DB2 database design or DB2 performance situation. Since many venture capital firms invested in Facebook many years ago the IPO needed to offer a record number of shares. The hype behind the Facebook IPO was tremendous and the number of shares was increased 25% only days before IPO. The IPO total of 421 million shares offered and raised over $16 billion. DB2 performance professionals know that increasing workloads 25% potentially requires additional hardware or database design considerations. This last minute change reveals poor communication to IT to change the DB2 performance considerations which is almost always a big issue.
More complexity and multiple components usually cause more confusion and performance issues. DB2 performance is achieved through solid design principles for your database including designing your application for scalability. A record number of banks, over thirty-one banks, were involved supporting the massive interest in the Facebook IPO. Since an unusual large number of banks were involved, the application processing probably wasn’t designed for this extra complexity, didn’t leverage parallelism and had scalability issues. Was this the reason the Facebook IPO processing was delayed and trading started over an hour and a half late? To get good DB2 performance within your applications plan for areas where the business might expand its capabilities and design for parallelism in your database and application. This way your application can handle additional components and complexity.
Finally, track everything about your DB2 performance. One of the stories coming out of the Facebook IPO situation is that the processing was so slow that web site clicks trading stocks were not serviced quickly enough. This caused additional web site clicks to reaffirm a large number of share trades. Then their first trades were confirmed leading to traders to reversing out the second trades. All of this confusion led to further complexity for all bankers and traders as they tried to figure out which trades were completed and which ones failed. Lack of scalability planning caused poor performance during the Facebook IPO.
To get good DB2 performance you must track all the application transactions within your database to understand their DB2 performance. Keep DB2 performance monitoring on so that you can tell when processing lags and needs new database designs or application tuning. Only by tracking DB2 performance and revising designs, application coding or improving capacity can you avoid problems. Always tracking your DB2 performance and the application performance is the best way to keep performance problems from happening.
_________________________________________________________
Dave Beulke is an internationally recognized DB2 consultant, DB2 trainer and education instructor. Dave helps his clients improve their strategic direction, dramatically improve DB2 performance and reduce their CPU demand saving millions in their systems, databases and application areas within their mainframe, UNIX and Windows environments.
Leave a Reply