bfwebster writes "During the past few years, I served as an IT expert witness in BanxCorp v. Costco et al., in which BanxCorp sued Costco and Capital One for citing (with credit) its web-published national averages for CD and money market rates in their advertising. Judge Kenneth M. Karas issued his summary judgment opinion last fall, finding that BanxCorp's published averages are "uncopyrightable facts" due to the simple calculation involved and the lack of ongoing human judgment in what banks were involved. Here is my summary of his findings, along with a link to the actual ruling." top
30-40% of Healthcare.gov (backed systems) yet to be finished
bfwebster writes "Michael Swaine — long-time, well-known and very prolific author/editor in the programming and personal computing worlds — has just devised a new twist on the Peter Principal: the Peter Pinnacle, 'meaning to get promoted so high and to be so unqualified for your job that the company tells you that you can name your price just to go away.' I'm sure the timing of the neologism is just a coincidence." top
Book Review: Too Big To Fail: The Business Case for Big Data
bfwebster writes "[NOTE: I can't find any 'drop-down menu' for book review formatting. I have this saved out on my own laptop as text, so I can re-enter it if you can point me in the right direction...bfw.. (firstname.lastname@example.org)]
Suddenly more timely than ever in light of the US Government's own Big Data projects, Too Big To Ignore provides a quick-read introduction to Big Data for both managers and technical types. The book's subtitle sets forth its scope: this is neither a technical work on Big Data, nor a "how-to" primer, nor a comprehensive survey of the field. Instead, Phil Simon seeks to explain why a given organization of any size — small, medium, or large — might want to give serious thought to initiating a Big Data strategy relevant to its mission. He gives an overview of Big Data concepts, current solutions, case studies, and a path to get started.
Too Big to Fail: The Business Case for Big Data
Author: Phil Simon
Publisher: John Wiley & Sons Inc., 2013
Reviewer: Bruce F. Webster
ISBN: 9781118638170 (Hardcover)
Summary: Why businesses should consider a Big Data strategy
Disclosure: I reviewed Simon's first book (Why New Systems Fail) here on Slashdot four years ago and became friends with him as a result.
Following the success of his first book, Why New Systems Fail, Phil Simon has carved a publishing niche for himself in focusing on key issues in the intersection of technology and business, then explaining those issues to business types (as well as technical workers seeking a general introduction). Successive titles include The Next Wave of Technologies (various emerging technologies relevant to business), The New Small (using key technologies to allow small businesses to compete with large ones), and The Age of the Platform (the emergence of platform-based business models).
His newest book, Too Big to Fail, seeks to do the same for Big Data. As with his prior books, Simon's audience is primarily managers and business decision makers, though his books also provide a quick overview for technologists as well.
Big Data, as Simon uses the term, refers primarily to the massive amounts of unstructured data that organizations now have access to, either by tapping into various external data sources or capturing data directly via platforms and other hosted environments. In that sense, Big Data contrasts with traditional internal data stores, such as relational database systems and data warehouses. Big Data is, of course, very much in the news right now, given the on-going revelations of the US Government's PRISM project and other data gathering efforts, which may well be the largest Big Data project to date. This book — which came out in March — clearly does not address those revelations, nor does it touch upon government analysis of Big Data (beyond one or two passing comments). What it does do — as per the subtitle — is make the business case for exploring a Big Data strategy within your organization.
The book has an introduction and eight chapters, but really comprises three major sections.The first section — the introduction and Chapters 1 & 2 — covers, in effect, "What is Big Data, and why should I care?" Simon talks about the massive growth in unstructured data over the past 10-15 years and the impact it has had on various businesses. He also
The second section — Chapters 3 and 4 — provide an overview of Big Data techniques and current solutions. While the techniques — including data visualization, semantics, and predictive analytics — are timeless, the discussion of specific current technology solutions runs the risk of being dated within a few years, though there is probably no way to avoid that beyond future edition updates.
The final section — chapters 5 through 8 — seeks to explain what Big Data looks like in a business environment (including three case studies), how to get started on a Big Data project for your organization, and what the future is likely to hold.
As someone with a strong technical background who has not had any dealings to date with Big Data, I found the book a very useful introduction and overview to the business concepts and realities of Big Data. A few times I wanted a deeper technical dive and had to remind myself that this is not written as a technical overview of the subject, but is intended primarily for a business audience.
Simon's writing style is readable and informal (occasionally perhaps a bit too informal). But it is a fast and easy read — I read it in one sitting — which is essential for Simon's target audience. In light of PRISM, the subject is perhaps more relevant than ever for all of us, and some organizations may now see Big Data initiatives as a defensive move. However, the real long-term relevance of Big Data — and the corresponding issue, opportunity, and challenge — is underscored by a sidebar in the book written by Brad Feld (Managing Director at Foundry Group, a VC firm):
Twenty years from now, the thing we call Big Data will be tiny data. It'll be microscopic data. The volume that we're talking about today, in 20 years, is a speck....We are at the very beginning of a Cambrian explosion of data. (pp. 132-133)
bfwebster writes "iGoogle is my browser home page, for all my browsers on all my computers. I use it many times a day to check mail, manage my calendar, track the weather forecast, and, yes, see the latest stories on Slashdot. So it is with a bit of puzzlement and not a little dismay that I see that iGoogle is vanishing late next year. Google's stated reasoning, "You have better options on your mobile devices" — but I don't use it on my mobile devices. I use it on my laptop and my three desktop systems, which is where I actually, you know, do work. iGoogle can't be terribly expensive to support, which suggests that Google has other motives (big shock) for killing it off." Link to Original Source top
bfwebster writes "Browsing the web this morning, I discovered that the New York Post is blocking iPad users from reading its website via Safari. Instead, iPad users must download and use the NYPost App instead. That app previously required a paid subscription (which is one reason I didn't use it); however, the version I downloaded this morning isn't making any demands for payment. Yet." Link to Original Source top
bfwebster writes "Over at the Daily Kos, Chris Bowers lays out the groundwork for Grassroots SEO, with the up-front goal "to get as many undecided voters as possible to read the most damaging news article about the Republican candidate for Congress in their district" via "search engine optimization". He lays out the plan, then says, "Once we get the articles we can start working to push them up search engine rankings. We need to launch the campaign early next week, so let’s gather these articles as quickly as we can."" top
bfwebster writes "Since November of 2009, I have bought three multi-core 64-bit systems with Windows Home Premium (64-bit) preinstalled: an HP Pavilion desktop (model e9237c, bought 11/09); an HP Pavilion Entertainment laptop (model dv7, bought 03/10); and a Gateway desktop (model SX2802, bought 04/10). All three were upgraded to Windows 7 Professional at the end of May. During the time I have had these systems, I have had dozens of blue-scree-of-death (BSOD) crashes on the HP desktop; hundreds of BSODs on the HP laptop (which I suspect are related to the wireless adapter, since they mostly go away if I disable it), including multiple BSODs that occur at the log-in screen with no-one touching the laptop; and exactly zero (0) BSODs on the Gateway desktop. I am curious if others have noted similar problems on HP systems or lack thereof on Gateway systems. (Yes, I'm planning a factory restore and, if necessary, a return of the laptop; I've been on the road heavily since the end of March and haven't been able to lose use of the laptop until now.) More details here." Link to Original Source top
Does cheap technology undermine this court ruling?
bfwebster writes "Orin Kerr, a George Washington University law professor who focuses on legal issues regarding information technology (I own a copy of his book "Computer Crime Law") raises an interesting issue about a 2001 Supreme Court decision (Kyllo v. United States) that prohibited police from using a thermal imaging device on a private home without a warrant. (The police were trying to detect excess heat coming from the roof of a garage, as an indication of lamps being used to grow marijuana inside.) The Court made its decision back in 2001 because thermal imaging devices were "not in general use" and therefore represented a technology that required a warrant. However, Kerr points out that anyone can now buy such thermal imaging devices for $50 to $150 from Amazon, and that they're advertised as a means of detecting thermal leakage from your home. In light of that, Kerr asks, is the Supreme Court's ruling still sound?" Link to Original Source top
bfwebster writes "Roger Sessions released a white paper in which he claims that annual IT failure costs amount to $6.2 trillion. However, his reading of information sources and his resulting estimates are profoundly flawed. For starters, he misreads the US Federal Fiscal Year 2009 Budget Analytical Perspective document from which he extrapolates so much and ends up nearly an order of magnitude off in his estimate of the percentage of the US Federal IT budget that is "at risk" (his term, not the government's). Likewise, his estimate of a 65% failure rate for government IT projects is not supported anywhere in the document he cites and is, in fact, contradicted by it. The flaws in his extrapolation from the US Federal Government to the rest of the world merely compound the errors." Link to Original Source top
bfwebster writes "Despite the fact that a Google search on 'climategate' now yields over 10 million hits, the Google autosuggest feature appears to be deliberately ignoring 'climategate'. If you type 'climategate' in, letter by letter, you never get it as a suggestion, even when you've typed in 'climategat' (or, for that matter, 'climategate'). What you get instead is "climate guatemala". Bing, by contrast, autosuggests 'climategate' as soon as you type in 'cli'." top
bfwebster writes "Randall Parker, over at the always informative FuturePundit, calls attention to a study that claims that video games are a threat to support for the conservation of nature. The argument goes like this: people who play video games are less likely to be involved in outdoor activities, such as camping, hiking, and so forth; most support for conservation comes from people who are heavily involved in said outdoor activities; therefore, the more people who play video games, the fewer people who will support conservation. QED. Logical fallacies are left as an exercise to the Slashdot reader." Link to Original Source top
bfwebster writes "Independent of one's personal opinions regarding the desirability and forms of government-mandated health care reform, there exists the question of how well HR 3200 (or any other legislation) will actually achieve that end and what the unintended (or even intended) consequences may be. There are striking similarities between crafting software and creating legislation, including risks and pitfalls — except that those risks and pitfalls are greater in legislation. I've written an article (first of a three-part series) examining those parallels and how these apply to HR 3200." Link to Original Source top
bfwebster writes "I received a startling e-mail from my ISP this morning stating that my account for a dedicated server, from which I run several blogs, was going to be suspended because it had been "reported" as a phishing site for having four HSBC logos (JPEGs) present on the server. I immediately responded by noting that these logos were there because my co-blogger on one of my blogs wrote a post about HSBC's financial woes nearly two years ago and used one of the logos to head the article. My ISP claims that I not only need to remove the offending logos (which I did) but also conduct a security audit in case they were surreptitiously placed there (which they weren't). I asked just who had "reported" us as a phishing site and what the basis of their claim was beyond the mere presence of those JPEGs. I am waiting for a reply." Link to Original Source top
bfwebster writes "The New York Times has a lengthy article about the use of hunches or intuition by soldiers in dangerous situations (possible registration required). This phenomenon — a soldier sensing that something is wrong or out of place before determining just what the threat is — is real enough that the Army has spent two years studying it. The article cites other studies, military and non-military, that have demonstrated that "as the brain tallies cues, big and small, consciously and not, it may send out an alarm before a person fully understands why." Two interesting points that may actually be the same: troops that think of themselves as predators tend to do better than those that see themselves as prey; and elite troops (e.g., Navy Seals) tend to do better than regular troops." Link to Original Source top
bfwebster writes "US District Court Judge Andrew Gilford (Central District of California) granted a summary judgment motion in DealerTrack v. Huber et al., finding DealerTrack's patent (US 7,181,427) — for an automated credit application processing system — invalid due to the recent In re Bilski court decision that requires a patent to either involve "transformation" or "a specific machine". According to Judge Gilford's ruling, DealerTrack "appears to concede that the claims of the '427 Patent do not meet the 'transformation' prong of the Bilski test." He then applied the "specific machine" test and noted that, post-Bilski the Board of Patent Appeals and Interferences has ruled several times that "claims reciting the use of general purpose processors or computers do not satisfy the (Bilski) test." Judge Gilford analyzes the claims of the '427 patent, notes that they state that the "machine" involved could be a "dumb terminal" and a "personal computer", and then concludes: "None of the claims of the '427 Patent require the use of a 'particular machine,' and the patent is thus invalid under Bilski." DealerTrack apparently plans to appeal the ruling. Interesting times ahead." Link to Original Source top
bfwebster writes "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level customizable off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important.
Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.
Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.
What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.
The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.
The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.
The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.
The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.
The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.
The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.
Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.
While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.
My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.
bfwebster writes "The US Federal Court of Appeals sent some shockwaves through the patent world last year with its decision in In re Bilski, establishing a "machine-or-[physical]-transformation" standard for patents. The losing party appealed to the US Supreme Court, and word came today that the Supreme Court will indeed review the Bilski decision. Here is a set of links to the various filings in the matter, most of which are 'friend of the court' filings by various parties in favor of overturning the Bilski decision; by contrast, here is the filing by the USDOJ and USPTO (PDF) in favor of keeping the current ruling in place." Link to Original Source