On Tuesday July 28, 2009, 9:55 am EDT
ARMONK, N.Y. (AP) -- IBM Corp. said Tuesday it agreed to acquire SPSS Inc., a Chicago-based company that makes software to help businesses spot future trends as well as shifts in consumer patterns and behavior, for $1.2 billion.
N.Y.-based IBM said the acquisition of SPSS for $50 per share will boost its business-analytics technology, which can also be used to help reduce credit risk, increase customer loyalty and detect and prevent fraud across diverse industries, it said.
The deal represents a 42 percent premium to SPSS closing price Monday of $35.09. The news of the deal sent SPSS shares soaring in premarket trading on Tuesday, and it recently changed hands at $49.11, up $14.02, or 40 percent. IBM shares shed 46 cents to $117.17.
SPSS software predicts customer reactions, including to sales pitches and marketing campaigns. Clients include financial firms, telecommunications companies, government agencies and educational institutions.
The deal is expected to close later in the second half, subject to approval by SPSS shareholders and regulatory clearances.
Separately, IBM also said it has acquired Ounce Labs Inc., a privately held software company in Waltham, Mass., for an undisclosed amount. IBM said the company makes software that helps businesses reduce the risk and costs associated with security and compliance concerns.
Tuesday, July 28, 2009
Monday, July 27, 2009
Methodology Clashes?
We are all enslaved by our own dogma. Don't you agree?
I'd disagreed. Being dogmatic shouldn't be mistakenly treated as being held to facts as with stubborn to persistence. And yet facts must not be confused with common senses.
If in the entire universe, there are only 2 software development methodology and equal hordes of followers for each, can you tell which method is better? Hard to decide, ya. Most probably they are equally good or in a more negative perspective, equally worse. Survivorship bias contributes to the ill-perceived successfulness of perhaps any favored winners. Take water fall life cycle model for example, as one of the classic methods adopted in software development in past few decades, many large projects completed and rolled out but yet practitioners yelling about project failure rates. To certain extent, water fall model is proven to be a necessity for project failures and this judgement can only be made because the method had been used and tested extensively over a long period of time. The point is given two unproven, untested and possibly unknown methodology, it could be better in saving project time, if we just simply pick one and get a head start.
We now moved on to a world of unprecendented complexities and yet we are striving to simplify our understanding of "things". Many of us don't know about how a motor vehicle works, how Facebook homepage managed to show on your computer screen and so on. Despite all the simplications, we did not eliminate or reduce complexities but we now hide these nitty gritty details underneath a layer of people with professional skills. Ironically because of enormously growing complexity, even more details need to be abstracted from these professionals using friendlier tools or the hiring of "hard core" professionals. LOL.
Even better, the higher you climb on the corporate ladder, the less complex your works will be and more people are hired to manage your problems and well... complexities. Better life and higher pay :D.
Me Blabbing again...
I'd disagreed. Being dogmatic shouldn't be mistakenly treated as being held to facts as with stubborn to persistence. And yet facts must not be confused with common senses.
If in the entire universe, there are only 2 software development methodology and equal hordes of followers for each, can you tell which method is better? Hard to decide, ya. Most probably they are equally good or in a more negative perspective, equally worse. Survivorship bias contributes to the ill-perceived successfulness of perhaps any favored winners. Take water fall life cycle model for example, as one of the classic methods adopted in software development in past few decades, many large projects completed and rolled out but yet practitioners yelling about project failure rates. To certain extent, water fall model is proven to be a necessity for project failures and this judgement can only be made because the method had been used and tested extensively over a long period of time. The point is given two unproven, untested and possibly unknown methodology, it could be better in saving project time, if we just simply pick one and get a head start.
We now moved on to a world of unprecendented complexities and yet we are striving to simplify our understanding of "things". Many of us don't know about how a motor vehicle works, how Facebook homepage managed to show on your computer screen and so on. Despite all the simplications, we did not eliminate or reduce complexities but we now hide these nitty gritty details underneath a layer of people with professional skills. Ironically because of enormously growing complexity, even more details need to be abstracted from these professionals using friendlier tools or the hiring of "hard core" professionals. LOL.
Even better, the higher you climb on the corporate ladder, the less complex your works will be and more people are hired to manage your problems and well... complexities. Better life and higher pay :D.
Me Blabbing again...
Wednesday, July 22, 2009
The obligations of rating agencies
Eddy: The thoughtless following of rating agencies is just the same with a bank blindly following their internal risk models. Why you never expect to see this coming? Perhaps the followers believe that rating agencies are another group of entity with the "Too Big to Fail" nature? :D
By Mustapha Kamil.
Rating agencies just can't issue an opinion and then skate scot-free, says the chief investment officer of CalPERS
WHAT was said by the chief investment officer of The California Public Employees' Retirement System (CalPERS) last Wednesday was interesting and somewhat made sense.
Speaking to Bloomberg and of the suit CalPERS is undertaking against rating agencies, Joseph Dear said: "They (rating agencies) just can't issue an opinion and then skate scot-free, even if they're totally wrong, which they were with respect to these securities".
CalPERS was taking action against three bond rating agencies for the US$1 billion (RM3.58 billion) loss the pension fund suffered as a result of what it calls "wildly inaccurate" risk assessments by the rating agencies. Besides CalPERS, other investors who suffered massive losses in the subprime meltdown crisis has also commenced legal actions against rating agencies.
Whatever the outcome of these litigations will be interesting as any one of them may form a precedent for future cases.
So far, there has been no known successful action taken against rating agencies.
But rating agencies are not the only ones that issue some form of advice on investments. Stockbroking firms do too when their research arms make calls on stocks.
Investment banks do too when they issue advice on corporate moves to minority shareholders and sometimes, there is a grey area where even the financial press may find itself in.
In the past, rating agencies in the US have successfully argued that they were protected by the first amendment in the American constitution, just as the press are when newspapers publish indices, as they were merely issuing opinions on securities.
But such argument is being challenged by lawyers who essentially said there is a limit to the protection the first amendment accord to the likes of rating agencies.
The American courts are clear on this, in that when a rating agency rates only securities it is hired to rate or when the agency itself participated in the structuring of the security (such as in the Collateralised Debt Obligation debacle) and if such security was privately placed instead of offered to the general public, then the protection accorded by the First Amendment would be lost.
Stockbroking firms too are expected to follow development in these suits against rating agencies closely as the outcome could have a bearing on them too. And so too would the financial press in their role in disseminating information that may assist investors make their investment decisions.
Perhaps, the absence of malice would be a strong defence on the part of rating agencies and stockbroking firms as do fair comment on the part of journalists.
But the litigations against the rating agencies have just begun and even if they succeeded in mounting a strong defence, it remains to be seen whether they can escape other charges irate investors like CalPERS may pile on them.
There are always other possible suits, including perhaps, for negligence.
By Mustapha Kamil.
Rating agencies just can't issue an opinion and then skate scot-free, says the chief investment officer of CalPERS
WHAT was said by the chief investment officer of The California Public Employees' Retirement System (CalPERS) last Wednesday was interesting and somewhat made sense.
Speaking to Bloomberg and of the suit CalPERS is undertaking against rating agencies, Joseph Dear said: "They (rating agencies) just can't issue an opinion and then skate scot-free, even if they're totally wrong, which they were with respect to these securities".
CalPERS was taking action against three bond rating agencies for the US$1 billion (RM3.58 billion) loss the pension fund suffered as a result of what it calls "wildly inaccurate" risk assessments by the rating agencies. Besides CalPERS, other investors who suffered massive losses in the subprime meltdown crisis has also commenced legal actions against rating agencies.
Whatever the outcome of these litigations will be interesting as any one of them may form a precedent for future cases.
So far, there has been no known successful action taken against rating agencies.
But rating agencies are not the only ones that issue some form of advice on investments. Stockbroking firms do too when their research arms make calls on stocks.
Investment banks do too when they issue advice on corporate moves to minority shareholders and sometimes, there is a grey area where even the financial press may find itself in.
In the past, rating agencies in the US have successfully argued that they were protected by the first amendment in the American constitution, just as the press are when newspapers publish indices, as they were merely issuing opinions on securities.
But such argument is being challenged by lawyers who essentially said there is a limit to the protection the first amendment accord to the likes of rating agencies.
The American courts are clear on this, in that when a rating agency rates only securities it is hired to rate or when the agency itself participated in the structuring of the security (such as in the Collateralised Debt Obligation debacle) and if such security was privately placed instead of offered to the general public, then the protection accorded by the First Amendment would be lost.
Stockbroking firms too are expected to follow development in these suits against rating agencies closely as the outcome could have a bearing on them too. And so too would the financial press in their role in disseminating information that may assist investors make their investment decisions.
Perhaps, the absence of malice would be a strong defence on the part of rating agencies and stockbroking firms as do fair comment on the part of journalists.
But the litigations against the rating agencies have just begun and even if they succeeded in mounting a strong defence, it remains to be seen whether they can escape other charges irate investors like CalPERS may pile on them.
There are always other possible suits, including perhaps, for negligence.
Thursday, July 16, 2009
Slowly Changing Dimension
Slowly Changing Dimension a.k.a. SCD is literally means Slow..ly Chang..ing Dimension. Simple.
It's a kind of table designated as a Dimension using the OLAP terminology and referred the most in star schema or snowflake schema design. Contents in the table are descriptive in nature, i.e. Name, Code, Description attributes rather than for analysis, i.e. Measures. A SCD can be designed to handle Type 2 changes, loosely speaking, maintaining full history of incremental changes.
The key to understand and correctly use SCD Type 2 feature in your favourite ETL tools is "Slow...ly Chang..ing". The ratio of changes in the dimension over a defined time interval ideally must not be greater than 5% (heuristically) of the original records, meaning 5 million record changes in every 100 million count. If the ratio is more than expected, you must exercise precautionary measures to ensure the performance is still acceptable. Secondly, the method to identify whether a record already changed is critical (Absolute value, hashsum, timestamp or etc. Thirdly, proper indexes in place will help in improving the performance of SCD process.
If changes are anticipated to be widely covering the source data, perhaps keep a complete snapshot of new data would be more efficient for loading, at the expense of storage and IO processing.
It's a kind of table designated as a Dimension using the OLAP terminology and referred the most in star schema or snowflake schema design. Contents in the table are descriptive in nature, i.e. Name, Code, Description attributes rather than for analysis, i.e. Measures. A SCD can be designed to handle Type 2 changes, loosely speaking, maintaining full history of incremental changes.
The key to understand and correctly use SCD Type 2 feature in your favourite ETL tools is "Slow...ly Chang..ing". The ratio of changes in the dimension over a defined time interval ideally must not be greater than 5% (heuristically) of the original records, meaning 5 million record changes in every 100 million count. If the ratio is more than expected, you must exercise precautionary measures to ensure the performance is still acceptable. Secondly, the method to identify whether a record already changed is critical (Absolute value, hashsum, timestamp or etc. Thirdly, proper indexes in place will help in improving the performance of SCD process.
If changes are anticipated to be widely covering the source data, perhaps keep a complete snapshot of new data would be more efficient for loading, at the expense of storage and IO processing.
Wednesday, July 15, 2009
Business Intelligence Project
Phew, it's being a month since I last updated this tiny blog. Sorry mate, I was stucked in a jungle of confusions and disturbances, now still.
We've heard about so many business intelligence projects failed despite relatively little success stories shared by major players in the market. One common fallacy about successful BI project is not about how flexible or friendly is the tool but the overall process that leads to the eventual outcome. In data mining projects, it's a known fact that the process framework is more critical or makes more business sense than just sneaking at mere churned numbers. We have SEMMA and CRISP-DM process methodology just to name a few.
To be fair, project failures in this context do not mean absolute technical failures but refer to the inability to meet constraints, key performance indicators or explicitly stated objectives. A project can considered failed due to expectation mismatch of final deliverables, user resistance to adapt or high total cost of ownership.
Anyway, BI effort is a Product, not a Project.
The formal definitions of project and product are well defined in IT management literature. Briefly, a project has well defined deliverables with final delivery dates which is usually once off. In a project, vendor delivers something then possibly station a few support staffs onsite and done. From the perspective of vendor, yes, a BI "project" can be treated as a project. However rightfully any business intelligence application owners must see it as a product. Very important, the mindset has to be right.
I'm not really a hard core proponent of big bang design phase guy. Planning and design is a must, yes I agreed but not to the extent of every nitty gritty details. My view is that development methodology that involves a big chunk of time allocated for plain design works is not practical and inefficient. Iterative and incremental is still the way to go. The longer that you plan ahead the more deviate the outcome will be compared to your original plan.
Changes need to be embraced.
If BI effort must be considered as a/part of a product, then ideally the vendor commitment to such product shall be time driven, not work driven. And why is it you might ask? Think about it, if the commitment is scoped by works, one obvious characteristic of such arrangement will be vendor resistance to work changes. Any potential works that can result in significant business value to the organization simply dropped or "overlooked" due to the stringent time frame or slight technical difficulty to meet the deadline.
Secondly, the fact is real business requirement changes faster than the frozen paper works. The whole problem with something called scope creep is again merely due to the idea of scoped by works. Scope creeps must be embraced. Customers only realize certain direction of BI usages or more efficient/effective ways of utilizing BI after they know more about it. That's why customers with prior failure in BI efforts are more demanding because they know at least more compared to previous on how to make better cases for BI. This trial and error way is costly. I propose a non-trivial business intelligence to be bounded primarily by time, making the scope of works secondary though still significant.
A scenario. Organization ABC signed up a 2 years service contract with a BI solution provider called XYZ. The arrangement shall be like this, given a set of business requirement that can be materialized in the solution within a month, the vendor starts a common lifecycle to manage the deliverables. Plan, analysis, design, development, test and deployment. A month later, the targeted users can start to make use of the new analytical capability and derive more requirements from it then combine with the latest requirements drive by other factors such as market trends, regulatory compliances and new technology enablements. Here it forms the second payload to start the next iteration of efforts. We must remember that all these efforts are part of a BI product meaning the core of the product (deliverables from the month 1) can be changed, removed and enhanced to accomodate the version 2 requirements. Technically, this means that original tables can be dropped, combined or enriched with more attributes or data behaviors. All ETL jobs are vulnerable to changes. At this point, you might argue that why can't I design nicely and properly beforehand even before the lifecycle of month 1 started? You can't or properly speaking it might not make full business sense. A product must be enhanced only when real needs arise, critical bugs/issues found, significant feedbacks and new corporate directions.
Quantitatively, let assume deliverables from month 1 effort are 10 jobs, 5 reports, 20 tables and 3 cubes. For month 2, assume 5 new jobs added/3 old jobs must be refactored, 2 cubes added/1 cubes refactored, 4 reports added/1 reports refactored and 10 tables added/10 tables refactored. The numbers suggested here are superficial but you might see the pattern as time passes, more the development iterations that the objects (cubes/reports/tables/jobs) went through, the more stable it will be and the business value of each can be justified and maximized. 2 years duration thus might turn into a 24 iteration of BI "project" cycle.
One major advantage of this approach is that the analytical capability of the corporation along with its BI users is truly increasing and now they are more trained to adapt business changes and more flexible to face competitions.
To emphasize again, the experience process is more important than the outcome.
Subscribe to:
Posts (Atom)