Is big data just more marketecture? Or does the term refer to a set of approaches that are converging toward a common architecture that might evolve into a well-defined data analytics market segment?
That’s a huge question, and I won’t waste your time waving my hands with grandiose speculation. Let me get a bit more specific: When, if ever, will data scientists and others be able to lay their hands on truly integrated tools that speed development of the full range of big data applications on the full range of big data platforms?
Perhaps that question is also a bit overbroad. Here’s even greater specificity: When will one-stop-shop data analytic tool vendors emerge to field integrated development environments (IDEs) for all or most of the following advanced analytics capabilities at the heart of Big Data?
Of course, that’s not enough. No big data application would be complete without the panoply of data architecture, data integration, data governance, master data management, metadata management, business rules management, business process management, online analytical processing, dashboarding, advanced visualization, and other key infrastructure components. Development and deployment of all of these must also be supported within the nirvana-grade big data IDE I’m envisioning.
And I’d be remiss if I didn’t mention that the über-IDE should work with whatever big data platform — enterprise data warehouse, Hadoop, NoSQL, etc. — that you may have now or are likely to adopt. And it should support collaboration, model governance, and automation features that facilitate the work of teams of data scientists, not just individual big data developers.
Yesterday, Amazon launched an adjunct to its successful Amazon Web Service (AWS) elastic cloud offering. While we don’t normally comment on every product release, this one is significant — primarily because of who is doing it. The Simple Workflow service (SWF) clearly has nothing to do with Adobe’s Flash offering (although techno-nerds may initially think so, given the acronym).
So what was this all about? The business model is certainly interesting: an elastic, configurable workflow capability that’s distributed across any number of access points. Essentially, this will allow an organization to orchestrate processes in the cloud, linking participants up and down the value chain.
“Amazon Simple Workflow Service (Amazon SWF) is a workflow service for building scalable, resilient applications. Whether automating business processes for finance or insurance applications, building sophisticated data analytics applications, or managing cloud infrastructure services, Amazon SWF reliably coordinates all of the processing steps within an application.”
Pricing is initially free and then transitions into a blended, low-cost consumption model, with charges oriented around execution steps, bandwidth usage, how long the task is active, and signals/markers, etc. With usage charges at around $0.0001 per execution step, this gives you an idea of how small the operating overhead might be.
The story of Agile is more than just one chapter in the history of software development. It's also an extremely valuable case study in innovation, an elusive and often humbling process that doesn't work in quite the way that we instinctively think it should.
The trajectory of Agile points toward increasing the value of the software delivered. However, it started with no metric of value and almost no notion of what happened outside the development team. Instead, the first phase of Agile, as I describe in the recent publication "Navigating The Future Of Agile And Lean," focused primarily on changing the behavior and world view of developers working together in a team. Therefore, you won't find anything in Scrum or XP that says, "This is how you know your software is better." Instead, these methodologies told you how to work more effectively as a team. Presumably, better results would follow.
Engineering methodologies have been around for a long time. They've not been noticeable for being terribly successful. They are even less noted for being popular. The most frequent criticism of these methodologies is that they are bureaucratic. There's so much stuff to do to follow the methodology that the whole pace of development slows down.
Employees that use smart devices — PCs or mobile devices — for work have expanded their use of technology more than most people realize. How many devices do you think a typical information worker uses for work? If you only ask the IT staff, the answer will be that most use just a PC, some use a smartphone, and a few use a tablet. But our latest Forrsights workforce employee survey asked more than 9,900 information workers in 17 countries about all of the devices they use for work, including personal devices they use for work purposes. It turns out that they use an average of about 2.3 devices.
About 74% of the information workers in our survey used two or more devices for work — and 52% used three or more! This means that the typical information worker has to figure out how to manage their information from more than one device. So they’ll be increasingly interested in work systems and personal cloud services that enable easy multidevice access, such as Dropbox, Box, SugarSync, Google Docs/Apps, Windows Live, and Apple iCloud.
When you dig into the data, the mix of devices info workers use for work is different than what IT provides. About 25% are mobile devices, not PCs, and 33% use operating systems other than Microsoft.
I’m always searching for new negotiation best practices and tips when I’m speaking with Forrester clients, but it's not often I find one when I’m relaxing in bed with an old favourite, recently rediscovered book. But here’s one that I hope you’ll find amusing, and educational, from a book written over 80 years ago.
The current Mrs. Jones did some “tidying up” over Christmas — her euphemism for moving my stuff from its organized filing places in her office and dumping it as a jumbled pile on the floor of my office. In amongst a number of unwanted books and DVDs, now available at very reasonable prices on Amazon, I found my ancient copy of Kai Lung Unrolls His Mat by Ernest Bramah. It’s a wonderful book — set in China at some unspecified date in history — and written, so the preface claims, in that country’s classical convoluted style replete with analogies, adjectives, and apophthegms[i]. Read this passage about the ivory carver, Chan Chun, and his lowly assistant, Kin Weng, buying some new tusks from the merchant Pun Kwan — I hope you’ll love it as much as I do.
Pun Kwan and Chan Chun began slowly to approach, the former person endeavouring to create the illusion that he was hastening away, without in reality increasing his distance from the other, while the latter one was concerned in an attempt to present an attitude of unbending no-concern while actuated by a fixed determination not to allow Pun Kwan to pass beyond recall. Thus they reached Kin’s presence, where they paused, the sight of the outer door filling them both with apprehension.
In a conversation with Alex Bard, CEO of Assistly (now desk.com, part of salesforce.com), I learned a few interesting things about customer service solutions for small to medium-size businesses (SMBs): (1) Companies can be too small to have customer service organizations; (2) the main competition of vendors of SMB customer service solutions is not each other, but Post-It notes and Gmail; and (3) the service that SMB customers demand is exactly like the service that enterprise customers demand.
So what do each of these points mean?
Companies can be too small to have customer service organizations. Without a formal customer service organization, customer-facing personnel such as customer relations managers, CEOs, and marketing folks are on the hook to answer customer inquiries. These employees wear many hats, are on the road a lot, and communicate constantly with one another. And, more than likely, their companies also don’t have formal IT organizations. This means that customer service software must be tailored to a business user: easy to deploy, easy to configure, and supporting a multitude of mobile devices. Customer service software must also have built-in collaboration features, alerts, and notifications allowing personnel to quickly work together on a customer issue for quick resolution.
Last week I read an article on wired.com’s Danger Room blog about the elite US military Special Forces command, JSOC. The units within the Joint Special Operations Command (Delta Force and Seal Team 6) are responsible for the most clandestine and sensitive US military operations, including the Bin Laden raid into Pakistan last year. JSOC is very similar to elite Special Forces (SF) units across the globe including: the Russian Spetnaz, British SAS, French Naval Commandos, and the Israeli Shayetet 13. These SF units are capable of addressing asymmetric threats that traditional military units aren’t prepared to handle.
In the article, Spencer Ackerman interviews Marc Ambinder, one of the authors of The Commandabout JSOC. The article piqued my interest and I just finished reading the eBook. Like almost everything I do, I considered the information security implications as I read it. Today’s infosec threat landscape is dominated by unconventional threats that are difficult to address. How can we leverage the techniques utilized by SF to deal with the cyber threats we face today? I realize that we have an international audience, and my point isn’t to focus on US policy, but rather to take a deeper look at the unique capabilities of SF units and what lessons we can apply in our roles as S&R professionals.
“ITIL, ITIL, ITIL” is all that many of us hear these days when it comes to improving IT service management (ITSM) maturity or the availability of ITSM good/best practice and guidance (for the "Little Britain" fans out there imagine Tom Baker reading this intro). Many talk (and write) about the alternative or complementary frameworks, methodologies, and standards; but neither COBIT nor ISO 20000 (amongst others) have yet gained the market traction and collective consciousness of ITIL, the “ITSM best practice framework.”
ITIL is and will continue to be the de facto choice for most IT infrastructure and operations (I&O) professionals. Having said this, however, many I&O organizations continue to look at the possibilities of using multiple frameworks, methodologies, and standards in tandem to help better deliver against business and IT issues – what is commonly called an “ITIL plus” or “plus” strategy, e.g., ITIL plus COBIT.
Another body of service management good/best practice, the Universal Service Management Body of Knowledge (USMBOK), has long been lauded by ITSM thought leaders; but it has, to date, lacked the profile of ITIL in particular. Importantly, it works with, and is differentiated from, ITIL – it is not an ITIL competitor, more of a “companion piece” that supplements ITIL on both strategic and operational levels. Hopefully you noticed the deliberate naming of USMBOK – that there is no “IT” in it. It is about service management not IT service management – a solution to the issue that we often place too much emphasis on the “IT,” and not enough on the “SM,” element of “ITSM.”
Data privacy laws are the champions of citizens' rights in the digital age. However, multi-national organizations often find these laws challenging to navigate given the complex framework of global legal requirements. To help our clients address these challenges, Forrester developed a research and planning tool called the Data Privacy Heat Map (try the demo version here). Leveraging in-depth analyses on the privacy legislation of 54 countries around the world, this product is aimed at helping our clients better strategize their own global privacy and data protection approaches.
Using the tool, one can quickly determine how various countries stack up against each another in terms of their data privacy standards. Each country has been rated across seven key criteria, covering the breadth of law, EU adequacy, data transfer limitations, government surveillance activities, etc. Leveraging this data, our clients will be able to establish their own data privacy “high watermarks”, ensuring compliance in all locales in which their organization operates. One such application is in the use of cloud computing. Since the cloud is borderless, jurisdictional-based privacy laws are often a mismatch when applied to clouds. When considering outsourcing to a cloud service, companies should consult Forrester’s Privacy Heat Map to determine, for example, whether their data will be at risk of residing in a country with questionable governance surveillance practices.
A few months ago I shared a flight with a very pleasant lady from a European regulatory body. After shoulder surfing her papers and seeing we were both interested in information security (ironic paradox acknowledged!) we had a long chat about how enterprises could stand a chance against the hacktivist and criminal hordes so intent on stealing their data.
My flight-buddy felt that the future lay in open and honest sharing between organisations – i.e. when one is hacked they would immediately share details of both the breach and the method with their peers and wider industry; this would allow the group to look for similar exploits and prepare to deflect similar attacks. Being somewhat cynical, and having worked in industry, I felt that such a concept was idealised and that organisations would refuse to share such information for fear of reputational or brand damage – she acknowledged that it was proving tougher than she had expected to get her organisations to join in with this voluntary disclosure!
Across the US and Europe we are seeing a move toward ‘mandatory’breach disclosure; however they have seemingly disparate intentions. US requirements focus on breaches that may impact an organisations financial condition or integrity, whilst EU breach notification is very focussed on cases where there may have been an exposure of personal data. Neither of these seem to be pushing us toward this nirvana of ‘collaborative protection’.
In the UK, I’m aware that the certain organizations, within specific sectors, will share information within their small closed communities, unfortunately this is not widespread and certainly does not reflect the concept of ‘open and honest’ as my flight-buddy would have envisaged.