Category: Consider this

  • Beyond the Myth of “Purity of Arms”: Uncovering the Documented History of Pre-1948 Paramilitary Violence – Podcast Link Included

    Beyond the Myth of “Purity of Arms”: Uncovering the Documented History of Pre-1948 Paramilitary Violence – Podcast Link Included

    Beyond the Myth of “Purity of Arms”: Uncovering the Documented History of Pre-1948 Paramilitary Violence

    Spain, London and France, Wednesday 26th August 2026

    Collage reading “CONTESTED HISTORICAL MEMORY,” with maps, photographs, chains, and labels.
    A layered collage examines how truth, memory, and silence shape contested history.

    For decades, a pervasive historical narrative has insisted that the conflict in pre-1948 Mandate Palestine was defined by a stark asymmetry of intent: an Arab population driven by ideological hostility on one side, and a Jewish community operating purely in self-defence on the other. Popularised in political discourse and corporate comment sections alike, this framing often relies on the assertion that pre-state Zionist military forces restricted their operations strictly to British colonial targets, maintaining an unblemished record of “purity of arms” (Tohar HaNeshek).

    (more…)
  • DATA WORLD: Friends! Romans! Countrymen! Big Data is not Data Warehousing – 2026/01/29

    DATA WORLD: Friends! Romans! Countrymen! Big Data is not Data Warehousing – 2026/01/29

    29th January 2026

    Hold this thought: To paraphrase the great Bob Hoffman, just when you think that if the Big Data babblers were to generate one more ounce of bull**** the entire f****** solar system would explode, what do they do? Exceed expectations.

    I am a mild mannered person. However, one thing that irks me is hearing variations on certain themes. These themes include phrases like “Data Warehousing is Big Data.” Another is “Big data is in many ways an evolution of data warehousing.” Lastly, some say “with Big Data you no longer need a Data Warehouse.”

    Big Data is not Data Warehousing. It is not the evolution of Data Warehousing. It is also not a sensible and coherent alternative to Data Warehousing. No matter what certain vendors will put in their marketing brochures or stick up their noses.

    (more…)
  • IT’S POLITICS: The Complexities of Brexit

    IT’S POLITICS: The Complexities of Brexit

    Image1Martyn Richard Jones

    Düsseldorf, Germany – 2nd August 2017

    Last year I was asked if I would contemplate taking on the management of Brexit. It was a hypothetical question. No one is actually going to offer me the job. I had no qualms in stating that, given the complexity, uncertainties, risks and costs, I would hope that I would have the good sense to turn down such an offer. With the recommendation to the client that they should not to undertake such a reckless, costly and strategically stupid project.

    So, that’s my going-in position. As other strategists will have picked up on. (more…)

  • Big Data: And it’s all gone quiet over there!

    Big Data: And it’s all gone quiet over there!

    Big Data is all pervasive, all seeing and all knowing.

    Everyone is doing Big Data, and if they aren’t then they will.  It’s inevitable.

    Big Data will revolutionise the worlds of data, decision making and business.

    Am I right, or am I right?

    (more…)

  • A data superhero is something to be

    A data superhero is something to be

    SuperHeroA data warehousing superhero is something to be

    Not all that glitters is Big Data, and Big Data has a long way to go before it can deliver anything like the same satisfying results, tangible benefits and organisational agility that a properly implemented Inmon Enterprise Data Warehouse can provide.

    Therefore, I have a question for you.

    (more…)

  • 12 Amazing Big Data Success Stories for 2016

    12 Amazing Big Data Success Stories for 2016

    If this piece tickles your fancy, then please consider joining The Big Data Contrarians on LinkedIn:

    https://www.linkedin.com/groups/8338976

    Every year I ask myself the same question. Will there be any tangible, coherent and verifiable Big Data success stories in the coming year? Every year I come up with nothing. Nothing at all. “Sorry, no rooms at the Big Data Success Inn, as we are closed for vacations.”

    However, this year things are different. More positive, more alive and more fantastic. (more…)

  • The Big Data Contrarians At 1000

    The Big Data Contrarians At 1000

    First things first. The Big Data Contrarians (“a hype free Agora for Big Data dialogue”) is now a community of over one thousand professionals. (more…)

  • 10 amazing reasons to join The Big Data Contrarians

    10 amazing reasons to join The Big Data Contrarians

    You love data. You eat, breathe and sleep data! You source it, clean it, integrate and then analyse it until it confesses. You represent, invent and present results. Data is your life and Big Data is your prophet. The Big Data Big Top is the place to be, and (passively) that is where you are headed. For you, Big Data drives everything we do! Is that the case?

    Yes?

    No worries, in spite of all of that, you too can also be a useful member of The Big Data Contrarians.

    (more…)
  • Who’s afraid of the Big Data Contrarians? Here’s 500 reasons not to be

    Who’s afraid of the Big Data Contrarians? Here’s 500 reasons not to be

    If you enjoy this piece or find it useful then please consider joining The Big Data Contrarians:

    Join The Big Data Contrarians here: https://www.linkedin.com/grp/home?gid=8338976

    Many thanks.

    When I first started The Big Data Contrarians group on LinkedIn I was thinking that maybe we would get 100 members within three or four months. Well, I was mistaken. Since the 1st of July, the membership ranks of The Big Data Contrarians has risen to over 500 members. However, it’s not about the quantity it’s about the quality, and The Big Data Contrarians is ‘the nicest Big Data community that you are ever likely to encoun (more…)

  • The Million-Dollar Big Data Briefing

    The Million-Dollar Big Data Briefing

    If you enjoy this piece or find it useful then please consider joining The Big Data Contrarians: https://www.linkedin.com/grp/home?gid=8338976

    Many thanks, Martyn.

    Big Data, together with Cloud computing, the Internet of Things and Machine Learning, are topics that are very much to the fore in contemporary trends in Information Management. But is Big Data really the revolution that people have been waiting for or is it simply about the next steps in the evolution of business data architecture and management?  (more…)

  • Top 20 Big Data Bafflers

    Top 20 Big Data Bafflers

    If you enjoy this piece or find it useful (or something) then please consider joining The Big Data Contrarians: https://www.linkedin.com/grp/home?gid=8338976

    Many thanks, Martyn.

    For your amusement, delectable enjoyment and delight, I bring you the first in a series of Big Data Quizzes from The Big Data Contrarians – the nicest, most civilised and congenial Big Data community on the entire World Wide Web. (more…)

  • Stuff a great data architect should know

    Stuff a great data architect should know

    Stuff a really great Data Architect should know

    If you enjoy this piece or find it useful then please consider joining The Big Data Contrarians:

    Join The Big Data Contrarians here: https://www.linkedin.com/grp/home?gid=8338976

    Many thanks. (more…)

  • Why so many ‘fake’ Big Data Gurus?

    Why so many ‘fake’ Big Data Gurus?

    Why so many ‘fake’ Big Data Gurus?

    Where do you all come from?

    Where do you all come from?

    All your integrity’s gone

    Now tell me, where do you all come from?

    From ‘Where Do You All Come From‘ by Mott the Hoople (more…)

  • Big Data, the promised land where ‘smart’ is the new doh!

    Big Data, the promised land where ‘smart’ is the new doh!

    If you enjoy this piece or find it useful then please consider joining The Big Data Contrarians:

    Join The Big Data Contrarians here: https://www.linkedin.com/grp/home?gid=8338976

    Many thanks.

    So you want to ‘do’ Big Data

    Now everyone is doing Big Data you don’t want to be the odd one out, right? Of course not.

    Now, if you are serious about looking at Big Data from a business perspective then I will try and lend you some advice. If you are doing it from an IT or technology perspective, then I wish you good luck, and I hope that your Big Data initiative doesn’t turn into another tech crash-and-burn show.

    Now some Big Data pros are telling us that the place to start with Big Data is with strategy. Now, I’m too polite to call this out as abject bullshit, even though it is, and will instead content myself by offering an alternative and simple approach to approaching and addressing Big Data.

    My first piece of advice is this. DON’T START WITH STRATEGY!

    Don’t start with Strategy

    Strategy is a coherent, cohesive and executable response to a significant challenge.

    Strategy is not a definition of objective, a wish list of what you are trying to achieve or aspirational goals of a nebulous nature. No, strategy is not the objective but a means of reaching that objective. Strategy is real, tangible and executable. Strategy is doing.

    So what is a Big Data strategy?

    If a company is looking at the Big Data options, the last place they should want to start out from is from strategy. That is as silly idea as they come. Starting with strategy on the road to formulating viable responses to significant challenges and opportunities is like saying that before we choose strategic options and a realisable strategy, then you must have a strategy in place.

    Strategy is not working out what you want to achieve. That sort of thing should happen prior to any strategic work. Neither is strategy an exercise in establishing starting points, nor formulating questions nor understanding the challenges. All of this should come well before the major strategy aspects even kicks-in.

    Big Data strategy is a realisable, tangible and manageable response to a significant challenge, one that depends heavily on the availability, usability and credibility of Big Data (or Very Large Data Bases) and the business value of processing that Big Data.

    So, a word of advice. If you are thinking of embarking on a Big Data initiative, do not start with strategy. That is a really daft place to start.

    Start with business imperatives

    Start here instead. With real business imperatives. This is where you are thinking about the big and significant challenges to the business, and how, at a high level of abstraction, you could go about meeting those challenges. Here you identify your challenges and your responses, aligned to your objectives.

    If you can identify business imperatives that make it absolutely necessary to include elements of Big Data, then go forward with that mandatory requirement in mind. If not, then don’t try to shoe-horn Big Data into a place where it really isn’t needed or wanted. Because if you go against the grain in this way it may well hurt you and your business, in more ways than you bargained for.

    Know what you are looking for

    In order to go out looking for data requirements driven by business imperatives, we really need to know what we are looking for.

    What we are looking for maybe highly tangible or less so. We may have to derive the data we are looking for by refining, aggregating, enriching, filtering and cleansing. Therefore, with those and other aspects in mind, we can go out and find what we need.

    How to find what you are looking for

    From looking at the data requirements, you should have a good idea of potential sources of that data. Agility in this aspect is predicated on the premise that one knows the systems on the IT landscape, the business processes and all the potential sources of data – at a high level at least. So, this is not the sort of work you can do remotely with little or no knowledge of the clients business, IT setup, processes or culture.

    But anyway, after you identify the sources you move on to the next step.

    Check data availability

    Here you discuss aspects of the data you require with the database / application platform owners to ensure that:

    1. they have the data you are looking for
    2. that quality of the data is known and data quality can be addressed
    3. that the data is relevant for what is needed
    4. that the cost of providing this data is not prohibitive
    5. that this data can be made available to you
    6. that service levels could be put in place, if and when required

    So far so good. Once passed these hurdles (and don’t forget this is a super-simplification) we move in to the next.

    Make proof of concepts

    So, now we know:

    1. What data we need
    2. Where we can get it from
    3. How we get it
    4. What we need to do to make it usable
    5. How we need to analyse it

    Therefore, we go ahead and create a proof of concept or three. Simples!

    However, make sure that all prototypes are governed by these simple timeless guidelines:

    1. The proof of concept should be small enough to be doable in a reasonable time-frame. I would be rather generous for the very first pilot of its type in a company, but would set that limit at 90 days, tops.
    2. Make sure that the proof of concept is big enough to be significant. Again, ‘simple enough to be realisable’ and ‘large enough to be significant’, should go hand in hand.
    3. Arrange your proof of concept execution into sprints. So your 90 days may be made up of nine 10 day sprints.
    4. Don’t try and shoe-horn infrastructure aspects of your initiative into sprints, it just doesn’t work, and simply pisses people off.
    5. If a proof of concept looks like it will fail, then make sure it fails early. There’s nothing worse than having people insist on pushing a dead project to live the full length of its planned term. Failing early means that business doesn’t take a dim view of the pilot, and will be more open to new proof of concept initiatives.

    Analyse the outcomes

    You run your proof of concept. You analyse, assess and represent your outcomes. You socialise, present and interpret.

    Revise your strategic outlook accordingly

    When you’ve done that you are in now in a good position to estimate the usefulness of the exercise, from both a qualitative and quantitative perspective.

    Did I mention technology?

    I did not want to touch in specific aspects of technology in this piece, in part, because I did not consider it a central issue in the theme of things. Of course, as part of creating proofs of concepts and pilot schemes you may want to experiment with the swatch (swaith? oh for auto-correction) of technologies out there. So go ahead and evaluate ‘Big Data’ technologies, and don’t forget, the answer to every Big Data technology question isn’t an automatic ‘Hadoop’. There are other valid Big Data technology options around, such as Lustre and GPFS, or even Oracle, Teradata or EXASol. Also, remember this, if all you are working on is a prototype, a proof of concept or a pilot then you can try and negotiate a free license with any of the major DBMS vendors for that initiative. So negotiate, bargain and get the most appropriate technologies with the best deals.

    That’s all folks

    Finally I will leave you with three guidelines to consider:

    1. Don’t ask ‘how can I do Big Data?’ but ‘what data do we need?’
    2. You don’t need to seek out Big Data. If you really need it, and it’s available, and it’s adequate and appropriate, then you’ll be getting it soon enough.
    3. Avoid searching for a Big Data problem you don’t have, which can only be solved by Big Data technology you don’t need.

    Many thanks for reading.

    In subsequent blog pieces I will be sharing my views on the evolution of information management in general, and the incorporation novel and innovative techniques, technologies and methods into well architected mainstream information supply frameworks, for primarily strategic and tactical objectives.

    As always, please reach out and share your questions, views and criticisms on this piece using the comment box below. I frequently write about strategy, organisational, leadership and information technology topics, trends and tendencies. You are more than welcome to keep up with my posts by clicking the ‘Follow’ link and perhaps you will even consider sending me a LinkedIn invite if you feel our data interests coincide. Also feel free to connect via TwitterFacebook and the Cambriano Energy website.

    For more on this and other topics, check out some of my other posts:

    Absolutely Fabulous Big Data Roleshttps://www.linkedin.com/pulse/absolutely-fabulous-big-data-roles-martyn-jones?trk=prof-post

    Not banking on Big Data?https://www.linkedin.com/pulse/banking-big-data-martyn-jones?trk=prof-post

    10 amazing reasons to join The Big Data Contrarianshttps://www.linkedin.com/pulse/10-amazing-reasons-join-big-data-contrarians-martyn-jones?trk=prof-post

    Amazing Data Warehousing with Hadoop and Big Datahttps://www.linkedin.com/pulse/cloudera-kimball-dw-building-disinformation-factory-martyn-jones?trk=prof-post

    The Big Data Contrarians: The Agora for Big Data dialoguehttps://www.linkedin.com/pulse/big-data-contrarians-agora-dialogue-martyn-jones?trk=mp-reader-card

    The Big Data Shell Gamehttps://www.linkedin.com/pulse/big-data-shell-game-martyn-jones?trk=mp-reader-card

    Aligning Data Warehousing and Big Datahttps://www.linkedin.com/pulse/aligning-data-warehousing-big-martyn-jones?trk=mp-reader-card

    Big Data Ludditeshttps://www.linkedin.com/pulse/big-data-luddites-martyn-jones?trk=mp-reader-card

    Data Warehousing Explained to Big Data Friendshttps://www.linkedin.com/pulse/data-warehousing-explained-big-friends-martyn-jones?trk=mp-reader-card

    Big Data, a promised land where the Big Bucks growhttps://www.linkedin.com/pulse/big-data-promised-land-where-bucks-grow-martyn-jones-6023459994031177728?trk=mp-reader-card

    The Big Data Contrarianshttps://www.linkedin.com/pulse/big-data-contrarians-martyn-jones?trk=mp-reader-card

    Is big data really for you? Things to consider before diving inhttps://www.linkedin.com/pulse/big-data-really-you-things-consider-before-diving-martyn-jones?trk=mp-reader-card

    Big Data Explained to My Grandchildrenhttps://www.linkedin.com/pulse/big-data-explained-my-grandchildren-martyn-jones?trk=mp-reader-card

    If you enjoy this piece or find it useful then please consider joining The Big Data Contrarians:

    Join The Big Data Contrarians here: https://www.linkedin.com/grp/home?gid=8338976

    Many thanks.

  • Absolutely Fabulous Big Data Roles

    Absolutely Fabulous Big Data Roles

    Plus ça change, plus c’est la même chose.

    Jean-Baptiste Alphonse Karr

    Prologue

    I wrote a piece called ‘7 New Big Data Roles for 2015’. I published it on LinkedIn. Many people read it. Some people made suggestions. Others politely ignored it.

    I listened to the suggestions, comment and criticisms, and revised the piece as a result.

    So here, it is… I hope you like it. And if not, I might try again in six months’ time.

    (more…)
  • Amazing Data Warehousing with Hadoop and Big Data

    Amazing Data Warehousing with Hadoop and Big Data

    Many thanks for reading, and don’t forget, please join The Big Data Contrarians.

    Some time back, Bill Inmon, the father of Data Warehousing, took the Hadoop vendor Cloudera to task for putting out some confusing advertising.

    In recent times, Cloudera have linked up with Ralph Kimball, who, as some in the data world will know, has been an eternal ‘rival’ of Bill Inmon.

    For some, the name of Ralph Kimball has become synonymous with dimensional modelling, and although the Kimball Group once stated that Ralph did not invent the original basic concepts of facts and dimensions, Ralph has contributed much to the development of dimensional modelling and the innovative use of SQL. Subsequently, the Kimball Group reassessed, and are now labelling Ralph as the “Dimensional modelling inventor”.

    Kimball and Cloudera have collaborated on a number of initiatives, such as a webinar and slide set, with particular emphasis on the theme of Hadoop and Data Warehousing.

    Now, I do not know whether this is intentional or accidental, but this collaboration has produced a lot of disingenuous claims and dubious comparisons, so much so, that I get the impression that building the DW Disinformation Factory is becoming a cottage industry in its own right.

    Personally, I can see scenarios in which Big Data complements Enterprise Data warehousing, and I have explained my vision and possible architectures for these scenarios. However, what some Hadoop vendors are alluding to in the Data Warehousing space, is actually quite mischievous and misleading and is not constructive in the least, in fact, the biggest side-effect is to muddy the Big Data and Data Warehousing waters even further. That is not good, either for the industry or for the customers, or indeed, for the professionals.

    In one piece of content from Cloudera, we can read that…

    “Dr. Kimball explains how Hadoop can be both:

    A destination data warehouse, and also

    An efficient staging and ETL source for an existing data warehouse”

    On the first point? No, Hadoop will not be replacing Teradata, Oracle, EXASol or any other high-performance relational database management system.

    On the second point. Hadoop could support a data source for Data Warehousing, as can many other technologies. However, there is no such animal as an ETL source. There are data sources and data targets, extractions, transformations and loads, and all that cool data management, but ETL is a technology, not a source.

    I think Big Data may have a big future; it depends on how deeply the internet development culture pervades enterprise application development. A lot of what Big Data addresses is about is making up for shortfalls created by badly architected web applications and shoddy application development, in which data use and data persistence were at best workaround bodges, rather than being well designed and coherent approaches to data management.

    Maybe this is some why people have a hard time explaining why they are considering using Hadoop technologies for Big Data. What would a CEO say if it was brought to their attention that Hadoop was being used in their business simply to make up for the fact that their internet applications are really shoddy examples of analysis, design, architecture and management? More to the point, what would the shareholders say if they understood the full ramifications behind the need to use Hadoop?

    In many cases, I think that Hadoop can be an indication that your IT organisation did something very wrong in the past, and that in these cases Hadoop is the price one pays when you one does not want to bite the bullet and admit that to screwing up, big time.

    In my opinion, it would make more sense to replace applications built on faulty architectures with robust and well-architected applications, rather than fix a problem by overmedicating the patient. This would mean that data generated and used by these applications could simply dovetail into standard decision-support data platforms, such as the Enterprise Data Warehouse.

    As for Cloudera and their bizarre and babbling baloney about Hadoop replacing the Data Warehouse? I suggest they read a book in the subject of Building the Data Warehouse, and maybe buck up their ideas a bit. As Bill Inmon stated “You would think that the executives of Cloudera would have familiarized themselves with what a data warehouse is.”

    As for recognised data professionals and influencers who support such Hadoop tripe? The less said the better. Eh, Ralphie?

    That stated, maybe Cloudera, Kimball and the Big Data flim-flam merchants simply don’t care.

    So go ahead, “turbocharge your Porsche – buy an elephant.”

    Many thanks for reading. Don’t forget, please join The Big Data Contrarians. The best Big Data community on the planet.

  • You can’t hide your lyin’ Big Data

    You can’t hide your lyin’ Big Data

    As a child, I adored the USA rock band the Eagles, especially the musical talents of Joe Walsh. This explains the inspiration behind the title of this piece.

    So, what’s going down at Ashley Madison?

    Never heard of them? Off your radar? Surely not?

    That stretches the bounds of incredulity. As even the people in Singapore’s Media Development Authority have heard of them. They even described their business site this way “it promotes adultery and disregards family values”, and subsequently will not allow them to operate in Singapore. Well, what a turn-up for the books.

    On a more serious note, and as you might know, (from Wikipedia or some other ‘sites’,) Ashley Madison is a Canadian-based online dating service and social networking service marketed to people who are married or in a committed relationship. Its slogan is “Life is short. Have an affair.” It seems, if we are to believe various reports doing the rounds, that their Big Data has been compromised, big time.

    Yes, I know, how could that possibly have happened, right?

    According to some reports, Adison Mashley have around 37 million clients in the Big Data pool, and large caches of it have allegedly been stolen after an apparently successful hacking attempt was carried out. According to Krebs On Security, data stolen from the web site in question “have been posted online by an individual or group that claims to have completely compromised the company’s user databases, financial records and other proprietary information.”

    But, again I ask, how can this happen?

    I am not an avid fan of Big Data technology for core business use, and given the level of Big Data technology maturity, it sounds like a dopey idea. But each to their own.

    What I will state is that my database management experience has tended to be associated with database technologies that can only be hacked as part of an inside job i.e. where people either know user IDs, passwords, IP addresses and layers of protection etc. or know of someone who does. Either someone who is a friend, part of the family (no, not that type of ‘family’) or someone who can be blackmailed into divulging the required access paths and security check workarounds.

    However, taking a broader and more permissive view of this alleged hackerisation of Big Data, do we write it up as a Big Data success, i.e. The Amazing Big Data Affair? Put it down to a technical glitch and community faux pas? Or do we take a jaundiced view of the whole thing and keep it real? I await with baited breath for the enlightened opinions of the Big Data gurus.

    Mitch ‘n’ Andy are not unfamiliar with ‘issues’ related to the use of people’s data. The Daily Dot carried a piece from contributing writer S. E. Smith with the headline ‘Why Ashley Madison is cheating on its users with Big Data’ in that piece, Smith states that “Like pretty much every other website on Earth, Ashley Madison spies on its users and crunches the data in a variety of ways to increase the bottom line.”

    Belinda Luscombe writing in Time confirmed these suspicions with a piece titled ‘Cheaters’ Dating Site Ashley Madison Spied on Its Users’. She wrote:

    In a study to be presented at the 109th Annual Meeting of the American Sociological Association in San Francisco on Saturday Aug. 16, Eric Anderson, a professor at the University of Winchester in England claims that women who seek extra-marital affairs usually still love their husbands and are cheating instead of divorcing, because they need more passion. “It is very clear that our model of having sex and love with just one other person for life has failed— and it has failed massively,” says Anderson.

    “How does he know this? Because he spied on the conversations women were having on Ashley Madison, a website created for the purpose of having an affair. Professor Anderson, who as it turns out is a the “chief science officer” at Ashley Madison, looked at more than 4,000 conversations that 100 women were having with potential paramours. “I monitored their conversation with men on the website, without their knowing that I was monitoring and analyzing their conversations,” he says. “The men did not know either.”

    Elsewhere, and as reported on Wikipedia, “Trish McDermott, a consultant who helped found Match.com, accused Ashley Madison of being a “business built on the back of broken hearts, ruined marriages, and damaged families.”

    Wow, wow, and triple wow! What a way to run a dance hall!

    Maybe they should reconsider their slogan, making it more snappy and apposite. How about “Life is short, we pimp your Big Data” as a starter? So go ahead, make your own and post it below. Have fun.

    Many thanks for reading.

    Oh, and one last thing before I go… GOOD-AD: Join The Big Data Contrarianshttps://www.linkedin.com/grp/home?gid=8338976

  • Consider this: Big Data Luddites

    Consider this: Big Data Luddites

    Bore da, pobl dda. A hyfryd dydd ‘Big Data’* i bawb.

    When it comes to Big Data, some people accuse me of being akin to a Luddite. Nothing could be further from the truth. Not that the facts matter. In the age of superficiality and surfaces there is as much wilfully cultivated obliviousness as there is unashamed and unabashed term abuse. Add the prevailing underlying current of anti-intellectualism into the mix, and we have an explosive combination that manifests itself in the alliterative combination of bluff, bluster and banality.

    — JOIN THE BIG DATA CONTRARIANS: http://www.linkedin.com/grp/home?gid=8338976

    I was reticent about writing this article, because it’s a bit like arguing against the irrational, self-interested and wilfully obtuse. Or as Ben Goldacre would have it, “You cannot reason people out of a position that they did not reason themselves into.” Therefore, a lot of care needed to be exercised. Indeed, Mark Twain once stated, “Never argue with stupid people, they will drag you down to their level and then beat you with experience.” Now, I wouldn’t go that far, and I do try to be nicely diplomatic, most of the time, but I can see where he was coming from.

    Anyway, without more ado let’s get a handle on what a Luddite is, in terms I hope that most will understand.

    According to Wikipedia (yes, I know) The Luddites were:

    “19th-century English textile workers who protested against newly developed labour-economizing technologies from 1811 to 1816. The stocking frames, spinning frames and power looms introduced during the Industrial Revolution threatened to replace the artisans with less-skilled, low-wage labourers, leaving them without work.”

    So why do I get a feeling that some people think that I am a Big Data Luddite?

    Here is Peter Powell of PDP Consulting Pty Ltd putting me in my place below the line on my piece titled 7 Amazing Big Data Myths:

    “With all due respect – your post does sound a little like what I could envisage an exchange between a man riding a horse and a man driving one if the first automobiles….sorry.”

    Although a respectable knowledge of the technology and its evolution would inform otherwise, I assume that this means that I would be the “man riding a horse”…  An interesting piece of conjecture indeed, even if hat in lacks in accuracy is made up for by the inexplicable certainty of belief. Still, it’s fascinating to discover just how many ‘experts’ think that this stuff – the sort of stuff I was doing in the mid to late eighties at Sperry and later Unisys – is bleeding edge innovation,

    Sassoon Kosian a Sr. Director of Data Science at AIG, had this to tell me on my piece entitled Amazing Big Data Success Stories:

    “Yes, cynical indeed… here is another amazing Big Data success story. You go on your computer, type in any search phrase and get instantaneous and highly relevant results. It is so amazing that a word has been coined. Guess what that is…”

    What to say? There goes a person who seems to believe that the history of search starts and ends with the Google web search engine. Something slightly less than a munificently inapposite comment, only outdone by its tragically disconnected banality.

    More recently, Bernice Blaar had this to say about my take on Big Data in general and The Big Data Contrarians in particular.

    “Master Jones may well be the great and ethical strategy data architecture and management guru that the chattering-class Guardian-reading wine-sipping luvvies drool over, but he is also a brazen Big Data Luddite. No, actually far worse than a Luddite, he`s a Neddite, because with his ‘facts’ and ‘logic’ (what a laugh, you can prove anything with facts, can’t you [tou}???) he is undermining the very foundation of the Big Data work, shirk and skive ethic that has been so hardily fought for by the likes of self-sacrificing champions and evangelists of the Big Data revolution, to wit, such as those bold, proud and fine upstanding members Bernard Marr, Martin Fowler and Tom Davenport, for example, and the brave sycophants that worship at their feet. Martyn is worse than Bob Hoffman, Dave Trott, Jeremy Hardy, Mark Steel, Tab C Nesbitt and Bill Inmon, all rolled into one. He may be a great strategist, but I wouldn’t hire him. Contrarian Luddite!”

    And then followed it up with this broadside:

    “The Big Data Contrarians group are nothing more than a bunch of over-educated clown-shoes who are trying to scupper the hard-work of decent people out to earn a crust from leveraging the promise of a bright future. In a decent society of capital and consumers, they would be banned off the face of the internets.”

    How does one reciprocate such flattering flatulence? How can one possible respond to such a long concatenation of meaningless clichés? Though to be fair, I quite liked being referred to as a Neddite, whatever that is.

    Anyway, to set the record straight, this is where I stand.

    A contrarian is a person who takes up a contrary position, especially a position that is opposed to that of the majority, regardless of how unpopular it may be.

    Like others, I am a Big Data Contrarian, not because I am contrary to the effective use of large volumes, varieties and velocities of data, but because I am contrary to the vast quantities of hype, disinformation and biased mendaciousness surrounding aspects of Big Data and some of the attendant technologies and service providers that go with the terrain. I don’t mind people guilding the lily (to use an English aphorism for exaggeration), but I do draw the line at straight out deception., which could lead to unintended consequences, such as creating false expectations, diverting scarce resources to wasteful projects or doing people out of a livelihood. That’s just not tight.

    Does that make me a Luddite (or a Neddite)? I don’t think so, but do make sure that your opinion is your own and is arrived at through reason, not some other persons bullying hype. As I wrote elsewhere some moments ago “If you have to lie like an ethically challenged weasel to sell Big Data then clearly there is something amiss.”

    As always I would love to hear your opinions and comments on this subject and others, and also please feel free to reach out and connect, so we can keep the conversation going, here on LinkedIn or elsewhere (such as Twitter).

    Many thanks for reading.

     

    — JOIN THE BIG DATA CONTRARIANS: http://www.linkedin.com/grp/home?gid=8338976

    Photograph: Delegates at my Big Data Summer Camp in Carmarthen (Wales).

    *Data mawr

  • Data Warehousing Explained to Big Data Friends

    Data Warehousing Explained to Big Data Friends

    Okay, before we get started I have to declare the real intent for posting this piece. It is to get you to join The Big Data Contrarians professional group here on LinkedIn.

    To apply to join the best Big Data community on the web simply navigate to this address http://www.linkedin.com/grp/home?gid=8338976 (or paste it into your browser) and request membership, the process is quick and painless and well worth the effort.

    Now for the rest of the news…

    There are many common misconceptions amongst the Big Data collective about Data Warehousing. There are common fallacies that need clearing up in order avoid unnecessary confusion, avoidable risks and the damaging perpetuation of disinformation.

    Big Picture

    In the dim and distant past of business IT, the best information that senior executives could expect from their computer systems were operational reports typically indicating what went right or wrong or somewhere in between.  Applied statistical brilliance made up for what data processing lacked in processing power, up to a point, because even heavy lifting statistics requires computing horsepower, which in those days was really a question of serious capital expenditure, which not all companies were willing to commit to.

    Then, and curiously coincidentally, people around the world started to posit the need for using data and information to address significant business challenges, to act as input into the processes of strategy formulation, choice and execution. Reports would no longer just be for the Financial Directors or the paper collectors, but would support serious business decision making.

    Many initiatives sprang up to meet the top-level decision-making data requirements; they were invariably expensive attempts, with variable outcomes. Some approaches were quite successful, but far too many failed, until the advent of Data Warehousing.

    Back then, most of the data that could potentially aid decision-making was in operational systems. Both an advantage and a problem. Data in operational systems was like having data in gaol. Getting data into operational systems was relatively easy, getting it out and moving it around was a nightmare. However, one of the advantages of operational data is that it was generally stored in a structured format, even if data quality was frequently of a dubious nature, and ideas such as subject orientation and integration were far from being widespread.

    Of course, data also came in from external sources, but usually via operational databases as well. An example of such data is instrument pricing in financial services.

    Therefore, briefly, a lot of Data Warehousing started as a means to provide data to support strategic decision-making. Data Warehousing ways not about counting cakes, widgets or people, which was the purview of operational reporting, or to measure sentiment, likes or mouse behaviour, but to assist senior executives, address the significant business challenges of the day.

    Who’s your Daddy?

    Bill Inmon, the father of Data Warehousing, defines it as being “a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process.”

    Subject Oriented: The data in the Data Warehouse is organised conceptually (the big canvas), logically (detailing the big picture and) and physically (detailing how it is implemented) by subjects of interest to the business, such as customer and product.

    The thing to remember about subject areas is that they are not created ad-hoc by IT according to the sentiments of the time, e.g. during requirements gathering, but through a deeper understanding of the business, its processes and its pertinent business subject areas.

    Integrated: All data entering the data warehouse is subject to normalisation and integration rules and constraints to ensure that the data stored is consistently and contextually unambiguous.

    Time Variant:  Time variance gives us the ability to view and contrast data from multiple viewpoints over time. It is an essential element in the organisation of data within the data warehouse and dependent data marts.

    Non-Volatile:  The data warehouse represents structured and consistent snapshots of business data over time. Once a data snapshot is established, it is rarely if ever modified.

    Management Decision Making: This is the principal focus of Data Warehousing, although Data Warehouses have secondary uses, such as complementing operational reporting and analysis.

    In plain language, if what your business has or is planning to have does not fully satisfy the Inmon criteria then it probably is not a Data Warehouse, but another form of data-store.

    The thing to remember about informed management decision making is that it needs to be as good as required but it does not need to achieve technical perfection. This observation underlies the fact that Data Warehouse is a business process, and not an obsessive search for zero defects or the application of so called ‘leading edge’ technologies – faddish, appropriate or not.

    JOIN THE BIG DATA CONTRARIANS: http://www.linkedin.com/grp/home?gid=8338976

    Some Basic Terms

    Before we delve into the meaning of Data Warehousing, there are a couple of terms that need to be understood first, so, by way of illustration:

    Let’s follow the numbers in the simplification of the process.

    1. We gather specific and well-bound data requirements from a specific business area. These are requirements by talking to business people and in understanding their requirements from a business as well as a data sourcing and data logistics perspective. Here we must remember at all times not to over-promise or to set expectations too high. Be modest.
    2. These business requirements are typically captured in a dimensional data model and supporting documentation. Remember that all requirements are subject to revision at a later data, usually in a subsequent iteration of a requirements gathering to implementation cycle.
    3. We identify the best source(s) for the required data and we record basic technical, management and quality details. We ensure that we can provide data to the quality required. Note that data quality does not mean perfection but data to the required quality tolerance levels.
    4. Data Warehouse data models modified as required to accommodate any new data at the atomic level.
    5. We define, document and produce the means (ETL) for getting data from the source and into the target Data Warehouse. Here we also pay especial attention to the four characteristics of Data Warehousing. ETL is an acronym for Extract (the data from source / staging), Transform (the data, making it subject oriented, integrated, and time-variant) and Load (the data into the Data Warehouse and Data Mart).
    6. We define, document and produce the means for getting data from the Data Warehouse into the Data Mart. In short, a bit more ETL.
    7. User acceptance testing. NB Users must ideally be involved in all parts of the end-to-end process that involves business requirements, participation and validation.

    This is a very simplified view, but it serves to convey the fundamental chain of events. The most important aspect being that we start (1) and end (7) with the user, and we fully involve them in the non-technical aspects of the process.

    JOIN THE BIG DATA CONTRARIANS: http://www.linkedin.com/grp/home?gid=8338976

    Business, Enterprise and Technology

    Essentially, a Data Warehouse is a business driven, enterprise centric and technology based solution for continual quality improvement in the sourcing, integration, packaging and delivery of data for strategic, tactical and operational modelling, reporting, visualisation and decision-making.

    Business Driven

    A data warehouse is business centric and nothing happens unless there is a business imperative for doing so. This means that there is no second-guessing the data requirements of the business users, and every piece of data in the data warehouse should be traceable to a tangible business requirement. This tangible business requirement is usually a departmental or process specific dimensional data model produced together in requirements workshops with the business. We build the Data Warehouse over time in iterative steps, based on the criteria that the requirements should be small enough to be delivered in a short timeframe and large enough to be significant.

    Typically, a Data Warehouse iteration results in a new Data Mart or the revision of an existing Data Mart.

    Enterprise Centric

    As we build up the collection of Data Marts, we are also building up the central logical store of data known as the Enterprise Data Warehouse that serves as a structured, coherent and cohesive central clearing area for data that supports enterprise decision making. Therefore, whilst we are addressing specific departmental and process requirements through Data Marts we are also building up an overall view of the enterprise data.

    Technology Based

    By technology, I mean technology in the broadest sense of techniques, methods, processes and tools, and not just a question of products, brands or badges.

    Unfortunately, there is a popular misconception that Data Warehousing is primarily about competing popular and commercial available technology products. It isn’t, but they do play an important role.

    Architecture

    The following is an example of a very high-level Data Warehouse architecture diagram.

    Methodologies

    Various methodologies support the building, expansion and maintenance of a Data Warehouse. Here is one example of a professional data integration methodology, produced, maintained and used by Cambriano Energy.

    And here is an information value-chain map as used by Cambriano Energy as part of its Iter8 process management. There are alternatives, many of which do a satisfactory job.

    Last but not least, this was (from memory) the way that Bill Inmon’s Prism Solutions ETL company used to view the iterative EDW building process.

    JOIN THE BIG DATA CONTRARIANS: http://www.linkedin.com/grp/home?gid=8338976

    Keeping it Shortish

    At this point, I decided to cut short further explanations on aspects on Data Warehousing. However, if you have any question then please address them to me and I will do my best (or something close) to answer them.

    That’s all folks

    Hold this thought for another time: If you think you can replace a Data Warehouse, that is not a Data Warehouse, with another approach to ‘Data Warehousing’ that doesn’t produce a Data Warehouse, for as fast and cheap as one can do it, then you still don’t have a Data Warehouse to show for all of your efforts. That is not a great place to be.

    Therefore, you see, Data Warehousing was never about a haphazard approach to providing random structured, semi-structured and unstructured data of various qualities, provenance, volumes, varieties and velocities, to whomever was of a mind to want it.

    Many thanks for reading.

     If you want to connect then please send a request. I you have any questions or comments then fire them off below. Cheers :-)

    Oh… and one last thing before I go… DON’T FORGET TO JOIN THE BIG DATA CONTRARIANS: http://www.linkedin.com/grp/home?gid=8338976

     

  • Raise the Big Data Flim-Flam High

    Raise the Big Data Flim-Flam High

    If there were ever a more apt rallying slogan for the Big Data BS babblers it would be “We BS about Big Data so that you don’t need to think”… and you know what? That’s how it is working.

    The trouble with the hype is that almost everyone and their dog is in on it. From the freelance or indentured Big Data gurus to the Gartners, IBMs and HPs of this world. Everyone who is anyone is trying to jump on the Big Data bandwagon, whether it makes sense or not. Hell, if I could become ludicrously rich and infamous on the back of Big Data, I would jump the Big Data shark as well.

    The other trouble is that the Big Data hype is very inconsistent in almost all areas, apart from the general unstated agreement there seems to be that Big Data will bring riches beyond the dreams of avarice, for everyone who wants it.

    So, let’s assuming that one wants to cash in on Big Data, what’s the first thing that we need to understand?

    Big Data comes in big data volumes, it has many data varieties, meaning it has a number of distinct formats, and it comes at us with increasing velocity, which most of the time we simply do not notice.

    So what does that tell us? Right, Big Data is data; just more of it, more flavours of it, generated and transmitted at faster and faster rates.  To simplify, data is like water (Oh, no not another analogy) and whereas Data Warehousing is the Rhine or the Mississippi Delta, Big Data is the Ma and Pa of the Iguazu, Victoria and Niagara Falls.

    So, what were the next questions I asked myself on the way to the land of Big Data health, wealth and happiness?

    I asked, “if you have a Big Data success story then let’s hear the skinny”, such as:

    • Please detail data that has used to create new insight and understanding?
    • How was this data sourced, treated and stored?
    • How was the resulting data queried? Let’s see the queries, the code, the pseudo-code and the code narrative.
    • What were the results of the queries? In technical and business terms, please.
    • What normalisation of the results took place?
    • How did those results drive insight? In business terms, please.

    Perfectly straightforward, right? These are the sorts of questions that one should be able to ask of a Data Warehouse user and then reasonable expect to get a coherent set of answer back in return.

    Well, seems like when it comes to Big Data this sort of line of questioning and reasoning is somewhat problematic.

    Which is a problem, because I am seeing fantastic claims made for Big Data, which is great, and I wish we all could become more prosperous from Big Data, but I can’t seem to get a handle on quite how one goes about it. It’s as if ‘tangible’ was anathema when it comes to practical and detailed examples of Big Data in action. You know, driving tangible business benefits through an understandable value chain of processes, ingredients and outcomes.

    So, come on Big Data guys, gals and gurus, it’s time now to pony up, put up or shut up.

  • The Amazing ROI of Big Data

    The Amazing ROI of Big Data

    For every professional bubble-head and bozo ‘bigging up’ Big Data there are at least ten intangible, unintelligible and phantom Big Data success stories.

    Why do I write that? Simples! Because that is what we have.

    From the perspective of non-IT business users, what does a real IT based success story look like?

    Here’s some examples:

    • We ran a Big Data project and the end-result was increased sales and margins, which added $21M to the bottom line. The overall project cost, including cost of business disruption, was $7M.
    • We deployed Hadoop technology to identify potential influencers and purchasers on Twitter. As a result of the campaign we increased sales of the Widgets by 8% (adding $9M is revenues and $3M in profits on an investment of $1M).
    • Big Data helped us to identify and exclude significant errors of judgement introduced into our new corporate strategy. As a result we averted possible losses of more than $10M. Total cost of aversion exercise was $5M. $5M up and no egg on our faces.

    These are fictitious examples of tangible benefits that might be accruable to Big Data. But, they are not factual, they are made up.

    Remember this. They are not real-life stories.

    Now, for some real-lifelike examples of benefits accrued from Big Data.

    • Big Data vendor strikes gold! The Big Data technology vendor GREPACLE today signed an enterprise wide licensing arrangement with the Fed for an estimated initial $750M, covering the years 2010 to 2017. The deal includes all industry-ready Hadoop “free ‘n’ open-source software” developed by GREPACLE. AWKACLE, who brokered the deal, expect to clear a $33M net profit from the arrangement.
    • OLLY-HARDY, the west coast hardware giant, has signed up WALLYCO who have handed over $60M as the first instalment for the provision of a cheap and cheerful battle-hardened commodity-hardware infrastructure that will replace the existing legacy infrastructure currently based on OLLY-HARDY MPP and SMP hardware and Oracle and Teradata software. A second contract billed to be worth in excess of $100M is in the pipe-line and is expected to be signed during the next quarter.
    • The profits of information theology research and technology advisory firm Gardening Leave jumped a clear 25% over the last three quarters due solely to sales of it’s reports and services in the Big Data domain.

    The names changed, and the project details finessed, to protect the guilty, but they are three simple, clear and fabulous examples of how gold is obtained from Big Data.

    However, there are many other Big Data success stories to consider, including:

    • The indentured Big Data pundits. Who wouldn’t lie for a slice of the pie? Right! But not everyone has scruples, values or even ethics when it comes to the filthy lucre.
    • The pro-Big Data press and their Big Data advertisers and ‘infomercialisers’. There still is money in getting people to advertise, big time.
    • The external service provider. The hardware may be commodity. The disk storage may be ample, cheap and cheerful. The unit cost of staff may be lower. But, you will be paying 10 times over the odds to your favourite outsourcer/offshoring business just for the privilege of having them screw up your Big Data project… 18 months down the line. You will even pick up the tab for breaches of data privacy and data protection. But don’t worry, paying someone else to make mistakes and learn on your money and time is the highest form of corporate altruism.

    Well, that should give one a flavour of the direction of Big Data, of the benefits accruable and to whom the benefits really accrue.

    Now here’s a thought:

    Most of the success stories seem to have the sale of a Big Data project, Hadoop’s ‘grep awk ecosystem’ and ‘development’ services as its central tangible success criteria.

    At best, these are dubious Big Data tech and service vendor success stories.

    What tangible Big Data client benefits are there on view in the public domain? How about non-IT business Big Data ROI? Same for Hadoop ROI? Same for Big Data and Tech Stack service ROI?

    What about… Who? What? Where? When? How? Why?

    Oh, there aren’t any success stories like that or they are so secret that one cannot but allude to them in generic BS terms.

    But, seriously? Do people still swallow that type of mendacious flim flam?

    Many thanks for reading.

  • Let’s talk strat! Business Strategy and IT

    Let’s talk strat! Business Strategy and IT

    I used to work for an affable person from Chicago. His two favourite phrases were “Let’s talk strat” and “Brought your cheque book with you?”

    There are many misconceptions about strategy. But, I particularly want to address two things:

    • What is business strategy?
    • What is IT (information technology) strategy?

    So, without more ado, let’s get the baby off the ground.

    (more…)
  • The Hadoop  Honeymoon is Over

    The Hadoop Honeymoon is Over

    Listen up Big Data playmates! The ubiquitous Big Data gurus, tied up in their regular chores of astroturfing mega-volumes, velocities and varieties of superficial flim flam, may not have noticed this, but, Hadoop is getting set up for one mighty fall – or a fast-tracked and vertiginous black run descent. Why do I say that? Well, let’s check the market. (more…)

  • On Not Knowing Sentiment Analysis

    On Not Knowing Sentiment Analysis

    If you know all about Sentiment Analysis, you’ve come to the right place. Because I don’t have a clue if what I know about it is accurate or not.

    I started to do a bit research into this Sentiment Analysis lark, in particular with the theoretical idea of using it to analyse and draw conclusions from comments on Pulse – assuming that this is what it can be used for.

    To begin at the beginning, which is good place to start, I read the piece on Wikipedia, and this was how it began:

    “Sentiment analysis (also known as opinion mining) refers to the use of natural language processing, text analysis and computational linguistics to identify and extract subjective information in source materials.

    Generally speaking, sentiment analysis aims to determine the attitude of a speaker or a writer with respect to some topic or the overall contextual polarity of a document. The attitude may be his or her judgment or evaluation (see appraisal theory), affective state (that is to say, the emotional state of the author when writing), or the intended emotional communication (that is to say, the emotional effect the author wishes to have on the reader).” Source: Wikipedia Link:http://en.wikipedia.org/wiki/Sentiment_analysis

    Well, that’s a fairly intuitive description. I could have almost have guessed as much.

    But, back to the aim of analysing sentiment in Pulse comments, where to start and what to do.

    What would sentiment analysis make of these:

    On the death of an IT-business celebrity. What would sentiment analysis make of the very emotive comments of desolation, sadness and poignancy of people who didn’t personally know the departed, even remotely, or maybe didn’t even know of them until after they had ‘shuffled off life’s mortal coil’? How would that work? What would sentiment analysis make of the maudlin aphorisms, surrogate grief and bizarre sorrow of people separated by more degrees than Kofi Anan and Mork from Ork.  What additional insight does sentiment analysis tell us when these comments are analysed along with the body of the text and other comments that triggers these comments?

    In a similar vein, how does sentiment analysis catch instances of sycophancy? Especially considering the fact that some of it is so ‘in your face’ and blatant that it often times seems to be a bad parody of a bad parody. “Oh, Ricky, why are you such a sexy brainbox?” How does it work in those situations?

    Worse than that is the preening, gushing and obtuse texts of massive, errm… fabulators[i]. If it wasn’t about Big Data or Strategy or IT, it would be about something else, usually about the writer themselves. “I give Rafa and Rodge tips on tennis! I went to the University of the Universe and got a first! I challenged Superman to a race, and won! I have read the entire works of Dan Brown, 25 times…Neeeh!” What would sentiment analysis do with that sort of gold?

    Also, what does sentiment analysis do with texts so ambiguously daft that they could mean anything? Okay, it might be able to pick up a few trigger words here or there, “rubbish”, “of”, “load”, “a”, “what”, etc. However, how does it know when “excellent” is being used in a way that means anything but excellent? For example, “Excellent Big Data job there”, with the silent “if you want a job doing properly then do it yourself”.

    Finally, for the purpose of this little piece, what would sentiment analysis do with term abuse, if it could actually identify it? Going back to the use of the terms such as Big Data or Strategy, how can sentiment analysis discern between the dopey and wrong-headed use of the term, and when it is actually being used in a coherent, cohesive and consistent way, in line more or less with its formal definition? I suppose we can always write a mountain of rules to help us out:

    If topic in focus of piece is strategy

    And context of topic is business

    And author of piece is Richard Rumelt

    Then the credibility of text is good (with a certainty of 100%)

    But you and try and maintain a rule base with isntances like that. It soon becomes a management nightmare.

    Alternatively, maybe it could be used to analyse this text. It’ll have its work cut out, that’s for sure. Does sentiment analysis do sarcasm and cynicsm?

    Anyway! I bet you might know how this sentiment analysis works, don’t you? On the other hand, if not, then it will be someone else who ‘knows’. But of course, all will not be revealed, because it’s a secret so powerful, that in the wrong hands it could be used to dominate the entire galaxy.

    Only joking; and many thanks for reading.

    [i]To engage in the composition of fables or stories, especially those featuring a strong element of fantasy: “a land which  had given itself up to dreaming, to fabulating, to tale-telling” (Lawrence Durrell).

    lang: en_US