EMA Blog: Business Intelligence and IT Management

Review of Statistics Done Wrong by Alex Reinhart

Since the advent of the big data era, organizations have been crying out for data scientists. Initially it was finding the true data scientist. But as these resources were considered scarce, it was a search for people who could hand-code analytical models in a Hadoop environment.  As statistical tools such as R, Alteryx, and RapidMiner augmented Hadoop environments, we started to include traditional tools such as SAS and SPSS. These data scientists, or data scientists in training, were asked to take large amounts of data and divine the nuggets that would create a “cross-sell/up-sell” recommendation engine that would launch the next Netflix or link two disparate data sets that explain how markets interact and find the next groundbreaking investment opportunity.

The ability to execute in a low latency time frame is a core component of the concept of next generation data management architectures such as the Enterprise Management Associates Hybrid Data Ecosystem (HDE). One of the key business drivers of the HDE is speed of response,  which stems from an organization’s drive to execute faster than their competitors to create an advantage or to be on par with those competitors to simply “keep up with the Joneses.” You see this in workloads such as cross-sell/up-sell opportunities for revenue generation. You see this in opportunities to limit costs with asset logistics and labor scheduling optimization. You see this in opportunities to limit exposure to risk in fraud management and liquidity risk assessment.

This blog in the Internet of Things (IoT) series comes as a tribute to security researchers everywhere. The autumn’s largest security-focused show is the Black Hat Security conference. If you are not familiar with Black Hat, it is a tech conference that started in 1997 and covers numerous security topics in various presentations that are fairly to highly technical. As mentioned in the first blog in the series, IoT-like systems have been around a long time. However, researchers began paying more public attention to IoT around 2011. Visibility on the subject of the security, or lack thereof, of IoTincreased in 2011, when researcher Jay Radcliffe demonstrated that medical devices; in this case, his own automated insulin pump, could be hacked to deliver a lethal dose of insulin.1 Since that time, there were numerous other IoT hacks in various fields, including:

Customers in 2017 will demand solutions to claim back today’s massive CAPEX and OPEX waste of over 50% of their total IT spend. All our 2017 predictions are directly derived from the rapidly increasing pressure to reclaim these resources and leverage them to achieve direct business advantages in today’s highly competitive and fast moving marketplace.

ForeScout recently released an IoT Enterprise Risk Report based on research from ethical hacker Samy Kamkar. Based on Kamkar’s findings, the report on IoT security issues could readily be renamed something like, “IoT: the bane of the enterprise environment,” or “IoT brings new meaning to the term ‘Enterprise Risk’.”

An unfortunate side effect of maintaining a vibrant technology subculture is an over-reliance on acronyms to describe basic concepts and solutions. For instance, to be ITIL compliant a CTO may need to invoke the ARP of a TCP or UDP IPv6 WAN to determine the DNS entry of an SMTP server for a POS system to prevent GIGO and ensure WYSIWYG. Now, if you understood that statement, you are certainly among the lucky few “in the know” and probably use these terms on a regular basis. However, if you are unfamiliar with or had to look up any of those terms, you likely recognize the core problem. While acronyms are intended to simplify complex technical conversations, they actually impede successful communication if any participants are unaware of their meaning. Sometimes acronyms are introduced to shorten long-winded technobabble; sometimes they are developed as marketing devices to create unique sounding products; and often they evolve simply because they make techno-elitists sound more knowledgeable.

In an ideal world, customers would be able to fully take advantage of the benefits of hybrid cloud by rationally matching infrastructure parameters -cost, performance, reliability, availability, security, regulatory compliance, scalability- with the requirements and dependencies of each application.

As we -Evan and I- were ranting last week about how OpenStack and VMware fit together (see #EMACloudRants), we were mainly focusing on the central conundrum that VMware faces within this context: “Should we support an open platform that could commoditize away a substantial part of our profitable infrastructure business or should we ignore the threat and do our own thing”