Big Data Divination Pam BakerYou’ve gotta read “Data Divination: Big Data Strategies,” Pam Baker’s new book about Big Data.

Actually, let me change my recommendation. If you are a techie and you are looking for suggestions on how to configure your Hadoop installation or optimize the storage throughput in your NAS array, this isn’t the book for you. Rather, this is the book for your business-side manager or partner, who is looking to understand not only what Big Data is, but really really learn how to apply data analysis to business problems.

One of the challenges with Big Data is simply understanding it. The phrase is extremely broad and quite nebulous. Yet behind the overhyping of Big Data, there are genuine use cases that demonstrate that looking at your business’ data in a new way can transform your business. It is real, and it is true.

Bake is the editor of the “Fierce Big Data” website. She deconstructs the concept by dispensing with the jargon and the, well, overly smug Big Data worship that one finds in a lot of literature and pushed out by the vendors. With a breezy style that reflects her background as a technology journalist, Baker uses clear examples and lots of interviews to make her points.

What will you learn? To start with, “Data Divination” teaches you how to ask good questions. After all, if you don’t ask, you won’t learn anything from all that data and all those reports. Whether it’s predictive analytics or trend spotting or real-time analysis, she helps you understand which data is valuable and which isn’t. That’s why this book is best for the executive and business-side managers, who are the ultimate beneficiaries of your enterprise’s Big Data investments.

This book goes beyond other books on the subject, which could generally be summarized either as too fluffy and cheerleading, or as myopically focused on implementation details of specific Big Data architectures. For example, there is a lengthy chapter on the privacy implications of data gathering and data analysis, the sort of chapter that a journalist would write, but an engineer wouldn’t even think about.

Once you’ve finished with the basics, Baker jumps into several fascinating use cases: in healthcare, in the security industry, in government and law enforcement, in small business, in agriculture, in transportation, in energy, in retail, in manufacturing, and so on. Those are the most interesting parts of the book, and each use had takeaways that could apply to any industry. Baker is to be commended for digging into the noteworthy challenges that Big Data attempts to help businesses overcome.

It’s a good book. Read it. And tell your business partner, CIO or even CEO to read it too.

Graeme WarringThirty seconds. That’s about how long a mobile user will spend with your game before deciding if he or she will continue using it. Thirty seconds. Maybe a minute. If you haven’t engaged the customer by then, forget it.

That’s according to Graeme Warring, COO of 2XL Games LLC, a game startup based in Phoenix. Speaking at an investor conference here today sponsored by AZ TechBeat, Warring explained that while mobile games are exploding, it’s getting harder and harder to make money at it.

One culprit that’s especially true with mobile games is that the new business model is free-to-play. That is, gamers can download the mobile app at no cost. They have, therefore, little or no emotional investment. They might try the game. They might not try it. They might play for 30 seconds or a minute. There’s no sense of guilt to drive them to engage with the software for hours or days, and then be inspired to use in-app payments to improve the gaming experience.

By contrast, consider a console game, such as for Sony’s PlayStation 4 or Microsoft’s Xbox One. A typical game might cost US$60. The gamer has done his/her research before making that purchase. Thanks to the emotional and financial investment, he/she is going to make a serious effort to play that game.

“It’s problem transference,” explained Warring. Who owns the problem of ensuring that the player gives the game a serious try? For an expensive console game, it’s the player’s problem. For a free-to-play mobile game, it’s your problem as the game developer.

Getting the player to engage requires an outstanding initial experience. Don’t require a steep learning curve; the era of preliminary in-game tutorials is long gone. Get the player involved instantly, and make it a fun and rewarding experience. Later, and only later, should you try to monetize through in-app purchases. Whether it’s a new weapon for a shoot-em-up, or grippier tires for a racing game, or more lives and candy and prizes, those become appealing only after the player is hooked and engaged.

Warring and other speakers at the AZ TechBeat conference made the point that the best-selling, top-revenue-producing games come from a small number of firms. They insist, however, that there are tremendous opportunities to make a smaller game, perhaps one that costs less than $5 million to create and market, and to make a profit from the investment.

Marketing is key. Expect to spend as much on marketing as on development, “and be prepared to burn through that budget,” the speakers insisted. That may mean social media; it may mean licensing arrangements. To that end, they suggest that instead of creating your own new brand and attracting a new audience, you may do better licensing an existing brand and a proven audience. Making a motorcycle racing game? License and tie it in with an existing motorcycle event, if you can. Such a tie in might be expensive, but it might bootstrap downloads and maybe even help attract investors.

That, in turn, will buy you 30 seconds. Make the most of it.

apple_watchFirst Impressions of the Apple Watch: Surprised that it’s not called the iWatch. The user interface looks surprisingly cool. Distressed that the Apple Watch needs to be charged every day, but if the docking station is sufficiently easy to use, it shouldn’t be a deal breaker.

The watches look like real watches, beautiful as well as functional. The pricing of US$349 and up doesn’t scare me. The long delay for the release—not until early 2015—gives competitors like Motorola and Samsung a great opportunity to respond and seize the initiative. I hope that by the release date, Apple Watch will work with Android phones (and maybe Windows Phone), not only iPhones.

First Impressions of Pay-to-Yelp: The Ninth Circuit Court of Appeals in San Francisco ruled that Yelp did not extort businesses by changing how business reviews appeared on its site based on their advertising status. For example, because Yelp never had any agreement to be impartial in its dealings with Dr. Tracy Chan (a dentist who never bought ads from the company), the judge said:

We begin with Chan, who alleges that Yelp extorted her by removing positive reviews from her Yelp page. Chan asserts that she was deprived of the benefit of the positive reviews Yelp users posted to Yelp’s website, and that, had she received the benefits of the positive reviews, they would have counteracted the negative reviews other users posted. But Chan had no pre-existing right to have positive reviews appear on Yelp’s website. She alleges no contractual right pursuant to which Yelp must publish positive reviews, nor does any law require Yelp to publish them. By withholding the benefit of these positive reviews, Yelp is withholding a benefit that Yelp makes possible and maintains. It has no obligation to do so, however.

This sets a scary precedent that could affect all for-profit businesses that both provide a forum for user feedback and which benefit in some way from that feedback. For example, an electronics reseller will undoubtedly sell more products if the reviews of those products are positive. There is nothing to stop such a reseller from removing negative reviews of products that it wants to sell (such as those that have profit margins or where the manufacturer offers incentives), or removing positive reviews from other products. While I never had much faith in online reviews, whether of books, hotels or big-screen TVs, I will have even less faith in them now.

First Impressions of COBOL: Well, okay, it’s not a first impression, but let us revisit last week’s column, where I talked about job opportunities for young COBOL developers. Kevin Nitert, a 26-year-old developer from the Netherlands, responded, “While it’s very true [COBOL] is easy to learn, the problem is that most companies work directly on the mainframe or ISPF. So learning COBOL is only one part; you have to know about the mainframe environment as well and learn things about JCL and REXX.”

I totally agree and should have talked about the environment. It is easy to learn COBOL on your own or with online training. Picking up the mainframe and environment is much harder. It’s been my experience that employers bringing in employees to work on legacy systems expect to do such training themselves, especially if those employees are young and were hired for their aptitude, not for their specific legacy skills with the platform.

To be honest, it wouldn’t take long to bring newbies up to speed on REXX (Restructured Extended Executor, a sophisticated scripting and job-control language) and ISPF (Interactive System Productivity Facility, a development tool chain for IBM’s z-series mainframes).

mag-tapeOnce upon a time, back when dinosaurs roamed the planet, I learned COBOL. While I never wrote any deployed applications in the language, I did use it to teach an undergraduate course in computer science for business majors, back in the early 1980s. Those poor students, who submitted their programs on punch cards for an IBM System/370, complained that the class was the most time-consuming of their undergraduate studies, often requiring lots of late nights at the campus computer center.

Hint: If you are using a card punch, it’s important to have excellent typing skills.

Today, of course, COBOL is more likely to be a punchline. Sure, there was a resurgence of interest in the language about 15 years ago, when everyone was concerned about the Y2K problem. After that, legacy systems running COBOL disappeared from the public eye. Everyone would much rather use Java or C# or Python or Ruby or Objective-C; that’s where the jobs are, right?

Don’t be so quick to discount COBOL, especially if you are looking for a job, or think that you might be some day. There are lots of COBOL applications running all over the world, and more and more COBOL experts are retiring every day.

I’d like to share some information from one of the biggest COBOL vendors: Micro Focus. Bear in mind that Micro Focus’ interest is self-serving, but with that said, I find the information fascinating.

According to the company:

A poll of academic leaders from 119 universities across the world saw more than half (58%) say they believed COBOL programming should be on their curriculum, with 54% estimating the demand for COBOL programming skills would increase or stay the same over the next 10 years. That’s a far cry from today’s reality. Of the 27% confirming COBOL programming was part of their curriculum, only 18% had it as a core part of the course, while the remaining 9% made it an elective component.

The company has a lot of bullet points about COBOL, which I’ll share verbatim:

  • COBOL supports 90% of Fortune 500 business systems every day
  • 70% of all critical business logic and data is written in COBOL
  • COBOL connects 500 million mobile phone users every day
  • COBOL applications manage the care of 60 million patients every day
  • COBOL powers 85% of all daily business transactions processed
  • COBOL applications move 72,000 shipping containers every day and process 85% of port transactions
  • 95% of all ATM transactions use COBOL
  • COBOL enables 96,000 vacations to be booked every year
  • COBOL powers 80% of all point-of-sale transactions
  • There are 200 more COBOL transactions per day than Google + You Tube searches worldwide
  • $2 trillion worth of mainframe applications in corporations are written in COBOL
  • 1.5 million new lines of COBOL code are written every day
  • 5 billion lines of new COBOL code are developed every year
  • The total investment in COBOL technologies, staff and hardware is estimated at $5 trillion
  • An estimated 2 million people are currently working in COBOL

Micro Focus cites lots of sources: The Aberdeen Group, Giga Information Group, Database and Network Journal, The COBOL Report, SearchEngineWatch.com, Tactical Strategy Group, and The Future of COBOL report as sources for those points.

Again, this might mean job opportunities. FedTech Magazine reports:

In March [2014], the Office of Personnel Management released its “Strategic Information Technology Plan,” a vision for revamping the agency’s IT operations, including plans to automate paper-based processes, invest in data analytics and consolidate numerous databases. But maintaining the mainframe hardware and software systems that currently support retirement processes is expensive; according to the agency’s plan, OPM anticipates costs will increases 10 percent to 15 percent annually “as personnel with the necessary coding expertise retire and cannot easily be replaced.”

The United States military agrees. According to Terry Halvorsen, CIO of the Department of the Navy, it is often more cost-effective to maintain COBOL systems than to replace them:

In many cases, however, maintaining an older system that fully supports our mission makes more sense than upgrading it or buying a new system that runs the risk of degrading our mission and requires a large investment. The [Department of the Navy] and industry still use a programming language developed in 1959 to operate major business functions in finance and personnel. In fact, nearly three quarters of the world’s business transactions are done in that venerable language, COBOL. Now with an estimated 200 billion lines of code, it still works. Part of the reason for this is it’s an easy-to-use language, it is fast and it processes data quickly. It is in use worldwide and has proven so stable and reliable that many Fortune 500 companies—Capital One, for example—still hire and train COBOL programmers.

COBOL is easy to learn… and the jobs are there.

bankamericard“My name is Patricia from the Bank of America fraud prevention department. This important message is for Mr. Alan Zeichick. We are calling to verify some potentially suspicious activity on your account. It is very important that we speak with you.”

Tuesday’s voicemail from my bank was short and simple. Nobody had pilfered a credit-card receipt or hacked into my account, the representative told me during our conversation. Rather, BofA had been notified by Visa (the credit card clearinghouse) that a retailer had been hacked, and many credit card numbers were stolen. Including mine. As of right now, my card was frozen; the bank will issue me a new card with a new number.

Who was the merchant? According to the BofA representative, Visa didn’t divulge that information due to an ongoing investigation. Nor did the representative know how many credit card numbers were stolen; all she knew what was that BofA was given a list of their bank’s customers who were affected.

These stories are coming far too often. Millions of cards were stolen in 2014 from diverse merchants like P.F. Chang’s China Bistro (a restaurant chain), Michaels Stores (art supplies), Sally Beauty (cosmetics), and Shaws (grocery stores). And those are only a few of the major vendors. Who knows how many smaller card thefts are either never reported, or aren’t deemed sufficiently juicy by the news media?

Some of you might be thinking, “We don’t take credit card numbers on our websites, so there’s no potential risk exposure.” Wrong. I am frequently astonished by the number of companies that maintain lots of customer data, and have that data pilfered. The Payment Card Industry (PCI) standards say that you should never store customer payment information. We’ve all seen that those standards are not followed, sometimes intentionally through neglect, and sometimes through flawed architecture, bad coding or lousy testing.

Let’s be clear: Encrypting browser communications does not protect your customers’ personal or financial information. If you are storing that information anywhere—in your data center, in the cloud—it is at real risk. The threats are active. Are your countermeasures active?

What is even more astonishing is that many of these thefts are of personal information stored on employees’ laptops. You may recall a high-profile case in 2013, where nearly 840,000 Horizon Blue Cross Blue Shield customers had their information compromised when two laptops were stolen from the New Jersey-based health insurance company.

To quote from the Star Ledger’s story,

The stolen laptops were password-protected but had unencrypted data, Horizon said in a statement today. A subsequent investigation determined the computers may have contained files with personal information, including names, addresses, dates of birth, and, in some instances, Social Security numbers and limited clinical information, the insurer said.

How is that possible? No possible scenario should allow customer information to be downloaded onto a desktop or laptop or tablet or phone. Ever. Encrypted or not, the data should never leave the server.

Please tell me you aren’t storing credit card info in files that can be stolen. Please tell me  your company has actively sought to ensure that customer information can never ever ever be downloaded from servers.

Data theft is a nuisance, for cardholders like me, and for businesses like yours. Do you protect your customers’ information?