Boek review: Big Data geschreven door Tom Breur

Big Data. Er lijkt geen ontkomen meer aan te zijn, iedereen praat en schrijft over deze nieuwste hype. Het is eigenlijk een hype waarvan ik zelf dacht dat ik me daar niet zo druk om hoefde te maken. In de regel volg ik het principe dat als de leveranciers heel hard brullen ik rustig aan de zijlijn blijf staan tot het echt duidelijk wordt of het wat is. Ik laat me in ieder geval niet door leveranciers overtuigen dat ik een early adopter moet worden. Het kost namelijk vaak simpelweg teveel geld en tijd om vroeg in te stappen. Daarnaast heb ik ook ooit eens een overtuigend verhaal gelezen over een IBM principe: always be second.

Het boek. Heel fijn, voor de niet Big Data expert, is dat helder uiteen gezet wordt in begrijpelijk Nederlands wat het verschil is tussen SQL en NoSQL en de impact ervan op Big Data dit inclusief de positionering van Hadoop. Dat scheelt weer een heleboel uitzoek werk. Aan de hand van praktijk voorbeelden wordt duidelijk gemaakt dat Big Data alleen maar waardevol is in de context van “small data” uit je datawarehouse.

Je heb ook een bijzonder type medewerker nodig die aan de slag gaat met Big Data, namelijk de data scientist. Ik had die term al vaker gelezen, maar het is me nu duidelijk geworden dat je een dergelijk persoon nodig heb. In de huidige jonge levensfase van Big Data zal het nog niet eenvoudig zijn om daar goede mensen voor te vinden.

Onderwerpen als sentimentanalyse, long tail marketing, micro targeting komen ruimschoots aanbod en worden verduidelijkt met leuke herkenbare voorbeelden. De voorbeelden komen uit verschillende werelden; van McDonalds, Twitter, Rijkswaterstaat, Politie, naar Call centers.

Er wordt veel verteld over de business case rondom Big Data. Dit is een boeiend hoofdstuk om te lezen. Met name als er verbanden gelegd worden met de theorie van Michel Porter en Treacy & Wiersema. Mocht je weinig tijd hebben om te lezen, pak dan dit hoofdstuk!

Het hoofdstuk over privacy heeft me aan het denken gezet. Er liggen een aantal gevaren op de loer. Enerzijds de veranderende wetgeving (inclusief de verschillen tussen Amerika en Europa) wat neerkomt op een waarschuwing voor de consument en anderzijds hoe denk je als bedrijf straks te dealen tussen privacy en Big Data? Dat zal geen eenvoudige opgave worden.

Het oordeel. Het boek is heerlijk leesbaar geschreven, met sprekende praktijkvoorbeelden. Hierdoor maakt de auteur het thema Big Data concreet en levendig. Het is geen halleluja verhaal over hoe geweldig Big Data wel niet is, en dat is prettig. Leveranciers zijn daar veel beter in om dat te vertellen. De belangrijkste thema’s komen allemaal aanbod, waaronder de thema’s privacy en de business case.

Dat Big Data niet zomaar iets is wat je er even bij gaat doen is wel duidelijk geworden. Dat wist ik eigenlijk al maar fijn dat het weer bevestigd wordt. Laat Big Data a.u.b. geen IT-feestje worden.

Eigenlijk ben ik heel benieuwd naar een opvolger van dit boek over een paar jaar. Hierin kan dan een reflectie gegeven worden op de huidige hoofdstukken. Is Big Data over 5 jaar “mainstream” geworden of doen alleen hele rijke en/of slimme bedrijven nog aan Big Data?

Dus het eindoordeel? Dit bepaal ik op mijn standaard manier: Weet de auteur na het lezen van het boek mijn interesse voor het onderwerp te vergroten? Het antwoord hierop is volmondig ja. Big Data is zeker een trend om goed in de gaten te houden.

The Universal Pattern of Huge Software Losses.

On my way to the Change Artistry Workshop, September 2013, I read an interesting article:
The Universal Pattern of Huge Software Losses, by Jerry Weinberg, one of the hosts of this monumental workshop.

Let me share a small section of the article:

The Pattern of Large Failures
Every such case that I have investigated follows a universal pattern:
1. There is an existing system in operation and it is considered reliable and crucial to the operation.
2. A quick change to the system is desired, usually from very high in the organization.
3. The change is labelled “trivial.”
4. Nobody notices that statement 3 is a statement about the difficulty of making the change, not the consequences of making it, or of making it wrong.
5. The change is made without any of the usual software engineering safeguards, however minimal, that the organization has in place.
6. The change is put directly into the normal operations.
7. The individual effect of the change is small, so that nobody notices immediately.
8. This small effect is multiplied by many uses, producing a large consequence.

Whenever I have been able to trace management action subsequent to the loss, I have found that the universal pattern continues. After the failure is spotted:

9. Management’s first reaction is to minimize its magnitude, so the consequences are continued for somewhat longer than necessary.
10. When the magnitude of the loss becomes undeniable, the programmer who actually touched the code is fired—for having done exactly what the supervisor said.
11. The supervisor is demoted to programmer, perhaps because of a demonstrated understanding of the technical aspects of the job. [not]
12. The manager who assigned the work to the supervisor is slipped sideways into a staff position, presumably to work on software engineering practices.
13. Higher managers are left untouched. After all, what could they have done?

The article amused me. A few weeks after the workshop, an email was send from our IT supplier to the Testing Department (I was in the cc).

Hi Frank,

Please find a list of known open incidents that could be fixed for the next repair release (I refer to bug tracking system IDs), together with our point of view regarding risks.

5791: Typos/translations -> impact = low risk, we will fix it.
5802: Sorting in the table on attribute. ->impact = also low risk (one line of code has to be changed)
5839: expanding of the list in the table view ->impact = low risk, consequence: the list will be scrolled to the top, please comment that!

5841: Appearance of “unknown error message”-> impact = none, already fixed in next version
5845: Comma between first name and last name -> impact = low risk, should be fixed
5846: Double click function does not work for certain objects. -> impact = low risk, should be fixed
5857: English error text ->impact = low risk, should be fixed
5859: Expanding of the list for the export filter -> impact = low risk
5863: view object in read-only mode -> impact = low risk (just one flag needs to be set correctly), should be fixed
5865: Rename the object window -> impact = low risk, of course 
5867: small error in standard calculation behaviour.. is that really a blocker?!? -> impact = anyway, risk seems to be low, but developer is on leave! Very quick decision required!!!

Best regards,

John

Hmmm…..I notice a pattern….. we just covered steps 1, 2, 3 en 4. Time is running out, but we still have some weeks to make sure we don’t end up in Jerry’s updated version form this article.