Wat is de overeenkomst tussen Agile Transformatie en de Grotvergelijking van Plato?

Er zijn opvallend veel overeenkomsten tussen en de transformatie van organisaties van nu om een wendbare, vitale, betekenisvolle organisatie te worden en de Grotvergelijking van Plato – zo’n 2500 jaar geleden opgesteld.

Ik beschouw de grotvergelijking als de transcendentie van een organisatie

Plato beschrijft de overgang (de transcendentie) van de ziel in onze wereld naar de ‘goddelijke werkelijke’ wereld in een gedachten-experiment. Zonder dat hij het benoemt, zijn daar een aantal stappen voor nodig. Ik herken er drie:

  1. De huidige situatie die ver staat van het ideaal;
  2. Vol ongeloof inzien hoe bedrieglijk die situatie is en
  3. De openbaring van de echte, ware wereld.

In mijn werk ervaar ik dat organisaties precies dezelfde fasen doorlopen om tot verheffing te komen, waarbij inderdaad soms enige mate van geweld nodig is, zoals beschreven door Plato – noem het dwang.

De Grotvergelijking

Om de overeenkomst te herkennen volgt hieronder een verkorte vrije vertaling.

  1. Stel u gevangenen voor die in een onderaards verblijf leven, een grot bijvoorbeeld. De toegang tot de open lucht wordt gevormd door een opening die even breed is als de grot zelf. Die mensen zijn nog nooit buiten de grot geweest. Ze [..] kunnen alleen voor zich uit kijken. Achter hun rug is een lichtbron[..]. Tussen dat vuur en de gevangenen loopt een weg die ook hoog is gelegen, met een borstwering die dient als het schot dat bij het poppenspel wordt gebruikt om de poppenspelers aan het gezicht te onttrekken. [..] Dan houden de gevangenen deze schaduwen steeds voor de dingen zelf.
  2. Nu worden ze op de een of andere manier bevrijd uit de boeien die hen afhouden van de werkelijkheid. Eén van hen wordt gedwongen om op te staan, het hoofd te draaien en ineens in het licht te kijken. [..] Wat zal hij zeggen, als men hem dan vertelt dat hij vroeger schimmen zag en nu dichter bij de werkelijkheid is komen te staan en beter kan zien wat zich in werkelijkheid afspeelt? Wat is zijn antwoord als men hem ieder ding dat voorbij wordt gedragen aanwijst en hem vraagt te zeggen wat het is? Hij zal het niet weten en meer geloof hechten aan wat hij voor die tijd zag.
  3. Als iemand hem met geweld omhoog voert langs die weg, die steil is en moeilijk begaanbaar, en hem niet loslaat voordat hij buiten de grot staat, in het volle licht van de zon, zal hij dan dat zonlicht niet als pijnlijk ervaren? Hij zal zich geen raad weten. Als hij eenmaal in het licht is gekomen en als zijn ogen worden verblind door het zonlicht, zal hij dan ook maar iets kunnen onderscheiden van wat de werkelijkheid wordt genoemd? [..] Ik denk dat hij zal moeten wennen. In het begin zal hij eerst de schaduwen kunnen onderscheiden, dan de weerspiegelingen van de dingen in het water, en pas later de dingen zelf. [..] Tenslotte kan hij, denk ik, naar de zon zelf kijken en haar ware gedaante aanschouwen. [..] Als hij zich zijn vroegere verblijfplaats herinnert, en wat daar voor wijsheid doorgaat, en zijn medegevangenen van destijds, zal hij zich dan niet gelukkig prijzen met de verandering en medelijden hebben met zijn makkers in de grot?

Ik stap soms een grot binnen waar mensen werken die nog nooit buiten hun organisatie zijn geweest

Dat is de context die Plato ons schetst in zijn gedachten-experiment. Plato maakt die vergelijking om zijn visie op transcendentie uit te leggen: Hier in onze wereld zijn slechts afspiegelingen van de werkelijkheid te zien – de werkelijke vorm. Wij kunnen ook niet beter weten totdat we die echte vorm hebben gezien. Soms lijkt het alsof ik in een grot ben gestapt. Ik zal de overeenkomst langs dezelfde drie stappen uitleggen in een eigen Grotvergelijking.

De grotvergelijking van Sander

  1. Stel je een organisatie voor die gescheiden is in twee delen: Business en IT. In die afdelingen weer zijn organische werkvormen uit elkaar getrokken tot onsamenhangende efficiënte processtappen, verdeeld in afdelingen van disciplines. Elk van die afdelingen werkt in hun eigen gewenste tempo. Het enige dat medewerkers en hun managers in zo’n afdeling bezighoudt, is hun taken zo efficiënt mogelijk te volbrengen. Daar worden zij voor beloond. Het enige dat zij zien, is hun specifieke product, zonder te beseffen dat dit slechts een deel is van een groter product.
  2. Stel nu dat iemand hun op een of andere manier in contact brengt met klanten van hun organisatie en zij horen van de behoefte. Wat zullen zij zeggen als ze verteld wordt dat er een andere manier van werken bestaat, waarbij de klantbehoefte organisatiebreed centraal staat, waarbij kortcyclisch de veranderende behoefte wordt gevolgd? Wat zullen zij antwoorden als ze voorbeelden getoond worden, hoe een werkend eindproduct stap voor stap wordt doorontwikkeld? Zij zullen beweren dat zij de klant al kennen door bureau-onderzoek en dat zij bovendien een interne klant hebben. Zij zullen aangeven dat kortcyclisch bij hun niet kan, omdat hun product complex is. Zij zullen daarom nog overtuigd zijn van hun bekende werkwijze.
  3. Als iemand ze nu dwingt agile te gaan werken en de organisatie te transformeren. Zij zullen zich geen raad weten in het begin: Doelen lijken onduidelijk, budgettering en opbrengst lijkt ongedefinieerd, ogenschijnlijke risico’s doemen op, het resultaat is misschien niet gelijk goed … Er is weinig tegenslag nodig en men wil terug naar de oude bekende situatie en werkwijze, want dat voelt vertrouwd. Stel dat zij het vertrouwen krijgen door te zetten. Zullen zij dan niet na enige tijd inzien hoe agile helpt bij het relevant blijven voor klanten? Zouden zij opgelucht zijn terugkijkend naar de nauwe werksfeer waar zij eerst deelgenoot van waren?

De transcendente agile wereld

Wat ik bij veel organisaties zie, zijn verbeeldingen, symbolen, schaduwen van agile werken. Voorbeelden hiervan zijn half geïmplementeerde frameworks, virtuele organisaties (het term alleen al …) of sturen op uren. Ofwel, deze organisaties zitten in de tweede stap.

Iets moet ze nog over de streep trekken, dwingen, om over te gaan naar de transcendente wereld. Zoals in de grotvergelijking van Plato is dat een persoon die desnoods met dwang zorgt, dat zij de verplaatsing van de ene naar de andere wereld ondergaan. Hij is de leider in deze. Dwang is lastig in de moderne wereld. De leider van nu kan door voor te doen, te vertrouwen, te wennen, drempels te beslechten en op de juiste resultaten te sturen, hetzelfde bereiken.

De echte leiders van nu dwingen hun medewerkers vertrouwen te hebben om de weg naar boven te volbrengen

Leiders van organisaties die echt doorzetten, kunnen zich nauwelijks voorstellen hoe ze voorheen het hoofd boven water hielden. Zij beseffen dat ze ontsnapt zijn aan irrelevantie – de ondergang. Leiders die durven te vertrouwen op nieuwe organisatievormen en durven te experimenteren voor het verkrijgen van nieuwe inzichten, die helpen de organisatie uit de grot.

Het antwoord op de vraag is derhalve, het juiste leiderschap !

Bronnen

Vertaling van de grotvergelijking van Plato

Advertisement
Wat is de overeenkomst tussen Agile Transformatie en de Grotvergelijking van Plato?

Digital Transformation is cooking a dinner

Does your organisation also adopt the ideas of Agility and the need for Digital Tranformation? Have you seen a Scaled Agile Framework poster hanging around? Well, excersising a Digital Transformation seems harsh and complex. The main reason according to a (Dutch) survey turns out to be the amount of departments involved. That in itself is the proof of the need to transform as you will see. Digital Transformation is about a mindshift through the entire organisation. Would it then be possible within your organisation to transform itself into another one, one that could indeed adopt to change more easily? How should you overcome this paradox? There is a great – thorough – easy reading book about the subject. It is called

Agile IT Organization Design – For Digital Transformation and Continuous Delivery –

written by Sriram Narayan

In this blog I will try to solve this paradox based on the essentials of this book. Oh, one famous quote of mr. Albert Einstein which you should keep in mind reading this blog or the book:

No problem can be solved by the same KIND OF THINKING that created it.

Cooking a dinner

Imagine yourself as a cook. How would you cook a fantastic dinner? It would be very impractical to make the whole menu at once. It is at least for those who’d eat it. Instead, you’d make the entree first, followed by the second course and so forth. The cook transforms incoherent ingredients into a splendid dish, by grinding, heating, dissolving or cutting ingredients using all kinds of tools, and all proceedings described in a recipe. If Digital Transformation is like cooking, what then will the menu look like and what will be the recipe?

The Menu

Our menu consists of three courses:

  1. Govern for value over predictability
  2. Organize for responsiveness
  3. Design for intrinsic motivation.

This dinner we will have only one dish, one business outcome. Every course we add new specific ingredients to mature the dish.

The Recipe

As a good cookbook we take a look at the ingredients first and then follow the instructions. So, here they are.

Ingredients

  1. Agile Credo. We need the four principles from the credo as a guide for the mind shift. The credo is like salt in a dish: Whatever we cook, it’ll need at least a pinch of salt.
  2. Superstructure. An organizational structure that’s outcome oriented (as opposed to the classic activity-oriented organizations). Good business outcomes are testable, valuable, independently achievable and negotiable (TVIN).
  3. Team. A cross-functional team with different primary skills working toward a common goal. The team is self-sufficient and business goal-directed.
  4. Accountability. Every business outcome needs a full-time dedicated outcome owner having authority and accountability for achieving the outcome.
  5. Alignment. Ensure business strategy is articulated, shared and accepted.
  6. Tooling. A tool that blurs boundaries between specialists to create a fertie ground for cross-functional non-scripted collaboration.
  7. Metrics. Outcome-oriented aggrageted metrics to measure adaptability (over predictability). Measurement can be valuable without targets.
  8. Culture. Culture change needs a well-thought-out set of norms providing a healthy framework for greater authonomy. Influence the communication culture and encourage written deliberations for important decisions. Open-plan layout for the office encourages collaboration deemphasize hierarchy.

Instructions

Now, let’s start with the entree to excite the appetite: Govern for Value over Predicatability. Choose a simple fairly autonomous – maybe new – value stream in your organisation as the dish for this dinner. One that’s decoupled from internal processes and therefore untied from the departments. One that can operate without interference from the current powers. This is an important property of the dish to mitigate the paradox mentioned in the introduction.

Then use metrics to focus on outcome realization. Keep measuring adaptibility. If you’re distracted and inflexible at the same time, things might get burned and you’ll have to start all over. Do not let accounting considerations influence team design. Instead, add team capacity-based budgeting, add this together with a pinch of an outcome owner accountable for the taste of the dish. After all, you need the best ingredients for the best outcome.

This was the entree. Radiate the appreciation of your guests and use their feedback for the next course. The next course is Organize for Responsiveness. Now we need to add ingredients like Permissive Culture, by pealing off approval based access to tools until you have access by default. The dish now needs to rise. So, add some more accountable decision owner as the yeast to the outcome.

Our third and last course is Design for intrinsic Motivation. This dessert is quite rich of taste if you look at the ingredients. First add a spoon of shared understanding of outcome. Stir well to commingle planning and execution. Let the dish simmer for quite a while to create the nice taste of stable capability team.

Conclusion

One of the main pitfalls in the transformation is to approach it as a project or program of projects. That would be a regular approach, which will not succeed in this case, because of the involvement of many departments. Furthermore, being organised in departments inherently implies not having the right mindset. This is the relation to the qoute. Another pitfall is to treat software development as a production process of a strictly designed product. On the contrary! Software development must be seen as a design process not a production process. You could look at cooking the same way. The cook adds an amount of an ingredient and test the dish by tasting until the right balance of flavor is achieved. The consequence might be the dish needs more of the same ingredient or it needs another.

To mitigate the paradox find a small or new value stream that could have an outcome in a short period. Form the right organisation with a skilled team and radiate successes. Also, create a supporting IT architecture on the side that’s loosly coupled – preferably decoupled – to the current landscape. Doing this, focus on the three key themes: Value, Responsiveness and Intrinsic Motivation. Repeat this recipe per business outcome until the legacy departments are disposable.

Digital Transformation is cooking a dinner

Getting rid of legacy systems with Micro Services and Event Driven Architecture

Your legacy systems do not support your business goals any longer? Your legacy systems stall your Digital Transformation? This article will outline a strategy to phase out your legacy systems!

The term legacy is sometimes a pejorative term. This is not always fair to very well-functioning systems. However, as soon as a system’s life-cycle becomes expensive, more than it ever was, or it fails to keep up to ever changing (online) needs, then we’d like to migrate it to a system with contemporary standards – and thus call it legacy.

Those standards trend towards agility, automated scaling-ability, off-premise, decoupled (autonomous) components, and so on. Aspects to which older systems are often in the opposite area of the spectrum. So, if you want to be a Pure Internet Player like Amazon or Netflix, you might also want to be an early adopter of new technologies, or want to scale just relevant parts of your system, have multiple teams work on the product to make little changes in a frequent release cycle. All in reach if you’d adopt Micro Services as an architectural approach.

Definition Here in this article we look at a legacy system as an outdated computer system or in need of replacement.

 

How the system used to work


To find out how to get rid of the legacy and make the first steps towards your business goals through architectural change, let’s first determine what the situation and problem is. In the first cartoon we see a chimp as an API serving the internal customer the information as a banana he needs from the tree-system.

1_microsystems_story_144_klein

A legacy system can’t support the load, knowledge may be lost, vendors may not exist anymore, they contain core/essential data/rules, no (security) updates possible, outdated hardware, slow or even no development takes place, high Total Cost of Ownership. In short, the system becomes an increasing busines risk. Especially when the number of internal and external users increase rapidly.

This is illustrated in the next cartoon.

 

2_microsystems_story_144_klein

Often the following patterns try to solve the problem, but seem only delay of the inevitable. (Note: Stereotype solutions in hardware.)

  • Large caches in between the system and actors that request the data
  • High computational power to prevent the system to halt
  • Highly redundant infrastructure to provide all kinds of fail-over scenarios

 

Solution Statement



Step by step eat your legacy system by creating Micro Services and/or micro-events from the legacy system to put its (useful) data in modern storage facilities and recreate common web-oriented user-interfaces on top of it.

Solution


Finding a solution pattern depends of the combination of three properties of legacy systems.

  1. Data model is known or a development environment exists
  2. Data is not mutated through the (legacy) system any longer
  3. A well-known data storage solution is used (f.i. Microsoft SQL; not a custom object store)

Let’s look into a typical scenario based on a case.

Case

In this company there were various legacy ERP-like systems containing all sorts of information. (The vendor of one of the systems even went bankrupt years ago.) As described above those systems were not designed to be accessed on a scale of potentionally milions of online users. To fulfill the inevitable online need, they’d created an API as middleware of the online interaction with their backend. Some of the systems contained all kinds of business logic and data that no-one knew it is even there. Maintiaining those applications therefore was quite risky, especially for the IT Department being responsible for their functioning. Developing new business ideas became very long lasting projects as soon as the ideas included backend information. In this case the properties one and three apply: Still development going on and the data models are known as well as their Database Management System.

The solution for this case was to find an autonomous function or domain and redesign its user interaction and user interface first. The contract was implemented in a Micro Service and its data store was fed by events coming from the appropriate triggers in the legacy system created for this purpose. This cycle was repeated until all desired functionality was re-created in a web-oriented interface.

The cartoon depicts this as a frog per (business) function/value stream/domain in which the Legacy system’s role and its API diminishes.

 

3_microsystems_story_144_klein

Data mutation was still done through the API that was in place to expose the data in the first place. Mutations were also kept in the Micro Services, but events of the same entities coming from the legacy system were dominant.

As soon as there were no actors anymore changing data directly within the system, the existng API was untied and the legacy system was disposed !

A suitable name for this solution pattern could be: “Use eventing to build new data stores within Micro Services“. In the cartoon the system and its API are retired 🙂

 

4_microsystems_story_144_klein

System (re)Design Approach


All solutions ought to use the following order for system design iterations – in short cycles.

  1. Design the user-interaction (maybe one for each actor), then
  2. The business rules followed by
  3. The API-contract and
  4. Implement a Micro Service to fulfill the contract and at last (if applicable)
  5. A set of events or an API to extract the data.

Following this order a system is recreated exactly with – and no more than – the currently needed data and business rules, while ignoring old rules and false, inconsistent or duplicate data ! Find out which of the properties apply to your situation and read the epilogue below for a more thorough elaboration on each possible scenario. First let us take a closer look at a typical solution pattern to get rid of you legacy systems.

Conclusion


Basically, when the data of the legacy system does not change anymore a set of Micro Services forms a temporarily layer until all needed data is extracted over time. When data does change also create events by setting triggers upon updates of fields. If the data model is not known there’s no other way than to invest in obtaining this knowledge first.

Advantages of this approach: There are no large risky migration needed. On the contrary, the shift will be seamless, clean and smooth. Users will gradually use the newly created system, until no-one uses the legacy system. Then the remains of the legacy system can be disposed while only the necessary data and business rules are extracted into the new system. A great Java example can be found [here](http://article.arungupta.me/monolithic-Micro Services-refactoring-javaee-applications/)

So, this way you are softly getting rid of legacy systems with Micro Services and Event Driven Architecture (and silently moving towards to what is now disruptive architecture). What’s left is a suite of Micro Services serving as one new application.

Epilogue: Solution Patterns


Below are the properties in a table and the solution pattern it suits, followed by a detailed look into each scenario. Those are possible variations on the typical solution descibed in the case.

N Datamodel is known/development environment exists Data is not mutated through the system any longer A well known data storage solution is used Solution
1 X O O Create a Micro Services Layer to extract data as an API
2 O X O Create a Micro Services layer upon the existing model
3 O O X Use eventing to create a new system
4 X X O Create a Micro Services Layer to extract data as an API, implement (refactored) business rules on extracted data
5 O X X Use storage of events to build a new system (API) and connect to new system
6 X O X Use eventing to build new data stores
7 X X X Create a Micro Service layer to extract data through events of changes from the database as an API
8 O O O Start all over 😦

1. Create a Micro Services Layer to extract data as an API

Still needs large capacity of legacy system. If the software is still under maintenance then implement the Micro Services as events on updates. Implement (refactored) business rules on extracted data. Create an user interface with according business rules in parallel with the Micro Service to seamlessly dissolve the legacy interface. Dispose the legacy as soon as the new system meets current needs.

2. Create a Micro Services layer upon the existing model

This is not trivial! Invest in retrieving the knowledge, even by hiring pensioned people. Then one-time-migration can be a solution, but it also contains the flaws, faults and inconsistencies. Better create a Micro Services ‘layer’ upon the model and continue as in solution one.

3. Use eventing to create a new system

Create triggers to throw events and store them to build a new model that supports the user-interfaces, business rules and API contracts needed until the new system covers all needs. Then dispose the legacy system.

4. Create a Micro Services Layer to extract data as an API, implement (refactored) business rules on extracted data

Create a Micro Services layer to extract data as an API. Still needs large capacity of legacy system. Implement (refactored) business rules on extracted data. Create an user interface with according business rules in parallel with the Micro Service to seamlessly dissolve the legacy interface. Dispose the legacy as soon as the new system meets current needs.

5. Use eventing to build a new system (API) and connect to new system

Without understanding the model, create triggers to throw events and store them to build a new model that supports the user-interfaces, business rules and API contracts needed. As an alternative recreate the model and business rules if still applicable.

6. Use eventing to build new data stores

Create triggers to throw events and store them to build a new model that supports the user-interfaces, business rules and API contracts needed. As an alternative recreate the model and business rules if still applicable.

7. Create a Micro Services layer to extract data directly from the database as an API

The easiest solution: Create a Micro Services layer to extract data directly from the database as an API. Dispose the legacy system immediately and the database as soon as the new system meets current needs. Migrating would also include flaws, faults and inconsistencies.

 

 

 

 

 

Getting rid of legacy systems with Micro Services and Event Driven Architecture

Milk First Lady

Er bestaat een Engelse uitdrukking die luidt: “Milk first lady”. Het is een grappige expressie waarmee je jouw superioriteit wilt aangeven op een andere persoon. Niet in een directe ontmoeting natuurlijk, maar te midden van anderen.

De etymologie ervan is niet onomstotelijk, maar de meesten zijn het eens over de volgende uitleg. In de tijd dat de koelkast niet bestond, moest je opletten dat de melk die je in de thee schonk, niet bedorven was. Als de dame des huizes onoplettend was, dan verpestte zij de thee. Dat is natuurlijk een beschamende vertoning voor je gasten. Je schonk dus eerst de melk en als die goed oogde, dan pas goot je de thee erbij. Was je welgesteld dan hoefde je je over de versheid van de melk geen zorgen te maken. In dat geval schonk je het in de andere volgorde.

In het kort: Er is geen reden te twijfelen aan de kwaliteit van mijn melk, omdat ik kwaliteit kan veroorloven. Zonder aarzeling kan ik daarom melk bij de thee schenken. Dat maakt mij superieur ten opzichte van hen die het noodzakelijkerwijs andersom doen.

Milk First doet mij denken aan alle ‘first’ trends van het afgelopen decennium in web-ontwikkeling. Ik noem er een paar zonder enige toelichting over hun betekenis.

Mobile first, Content first, Test first, API first, Contract first, Design first

Herken je ze? Het lijkt wel of elke rol in web-ontwikkeling zichzelf superieur voelt ten opzichte van de ander. Iedere rol heeft ten minste een eigen mening hoe je moet beginnen om een online succesvol product te maken: Hun eigen discipline, hun eigen kunstje!

Aan dit rijtje ontbreekt wat mij betreft een hele belangrijke: Offline First! (*Zie vootnoot.) Precies, niet-online-first. We zijn per slot van rekening ‘offline’ mensen – en dat zullen we nog wel even blijven. Een andere kop thee waarbij de melk wordt bijgeschonken met een van bovenstaande paradigma’s. Deze benadering is niet technisch of vanuit een discipline gedreven, maar vanuit de menselijke behoefte (en niet per se een klant). Met andere woorden, begin na te denken over de primaire behoefte – empathiseer met de gebruiker.

Kortom, een nieuw paradigma overheerst alle andere !

Voetnoot: Offline first schoot mij te binnen terwijl ik dit blog schreef. Zoekend op internet bleek de term al te bestaan op een community-site. Hun aspect van offline first is specifieker dan dat van mij: Hun zorg is de ontwikkeling van mobiele apps die zonder enige verbinding met het internet, nog steeds bruikbaar zijn. Trouwens, de ontwikkeling van Service Workers gaan een positieve bijdrage leveren in de browser voor dit aspect.

Milk First Lady

Economie van BigData

“You can have data without information, but you cannot have information without data”

Een beroemd citaat om mee te beginnen. Een andere veelgehoorde uitspraak is “informatie is het nieuwe goud”. Beide uitspraken kunnen gecombineerd tot: “You can have data without value but you cannot have value without data”. Elk bedrijf heeft data, maar hoe zet je data om in waarde? Dat is precies waar dit artikel over gaat.

Kan jouw bedrijf waarde halen uit Big Data?

In andere woorden: Wat heb ik nodig om een betrouwbare conclusie te trekken uit een grote hoeveelheid veelzijdige data en wel zo dat de kosten de baten niet overtreffen? Op die vraag geeft dit blog een antwoord. Een inspiratie voor deze vragen was een ander blog dat in essentie zegt dat

Big data is not the magic bullet many imagine it to be. These analytical approaches inevitably break down when confronted with the small data problems of our increasingly complex and fragmented domains of knowledge. (inspiratiebron)

Moeilijkheid

Het is niet eenvoudig om inzichten te krijgen die toepasbaar zijn en waarde geven voor jouw bedrijf. Behalve de kennis over het domein is ook kennis van analytische methoden nodig. Hier volgt een voorbeeld van een verkeerde gevolgtrekking.

Bewering A = Het gemiddeld lichaamsgewicht van de volwassen nederlander neemt toe.

Bewering B = De nederlander sterft op steeds hogere leeftijd.

Met deze beweringen kun je niet de volgende correlatie maken en het volgende beweren.

Bewering C = Corpulente nederlanders worden ouder.

Het feit dat nieuwe generaties nederlanders ouder worden dan hun voorgaande heeft andere oorzaken, zoals betere gezondheidszorg, dan het feit dat ze (toevallig) ook zwaarlijviger worden. Het zou zelfs kunnen zijn dat volgende generaties nog ouder worden als zij slanker zouden zijn. Dit alles is een uit de duim gezogen voorbeeld en berust niet op enig onderzoek. Het illustreert hoe makkelijk het is een verkeerd verband te leggen (zonder enige achtergrondinformatie, zonder enige kennis van het verrichtte onderzoek, populatie, kernvraag, zonder toetsing, etc).

Hoe zorg je als bedrijf wel voor het leggen van verbanden in beschikbare gegevens en dan ook precies die verbanden waarmee het bedrijf een verbeterde dienst/product kan leveren aan de consument? Laten we hiervoor het begrip data nader bekijken.

Aspecten van Data

Volgens Gartner zijn er drie aspecten die bepalend zijn voor Big Data: Snelheid, kwantiteit en diversiteit. Voor nu laten we snelheid buiten beschouwing en beperken ons tot de samenhang van kwantiteit en diversiteit. Een assenstelsel ziet er dan zo uit.

Assenstelsel

Elk kwadrant is zoals gebruikelijk, genummerd met een romeins cijfer. De verticale as van laag naar hoog de kwantiteit: Weinig tot Veel. De horizontale as van links naar rechts Diversiteit: Laag, simpel, feit, gebonden (1) tot Ruim, complex, subjectief, ongebonden (2).

Elk kwadrant vertegenwoordigt z’n eigen mate van inspanning. Hier volgt een typering.

I: Grote inspanning om betekenis te geven. Statistiek schiet tekort door fijnmazigheid, diversiteit&relaties; Expliciete semantiek toevoegen is duur, want een diepgaande kennis van het domein is duur. Snelheid van veranderlijkheid in diversiteit/complexiteit zijn hier de kostenpost (technisch schalen is niet het probleem).

II: Weinig moeite om statistische analyse te doen en betekenis te geven. Impliciete semantiek via statistische benadering (3).

III: Inspanning is laag – nihil eigenlijk, omdat er te weinig data is om betekenis te geven. In dit kwadrant is dus de inspanning niet kostbaar, maar het ontbreken van data.

IV: Matige inspanning door toevoegen semantiek enerzijds en beperkte relaties (sub-domeinen) anderzijds. Met andere woorden, er is niet perse veel data nodig om toch een bruikbaar model te creëren. Expliciete semantiek via ontologische benadering (4).

Bandbreedte

Elk bedrijf zou zich de volgende vragen kunnen stellen: “Hoeveel inspanning neemt het om een bruikbaar&rendabel resultaat te krijgen?” Hoeveel moeite neemt het om een betrouwbaar model te ontwikkelen, een analyse te doen en een bruikbare conclusie te trekken? Er is een aantal factoren dat de het antwoord op deze vraag beïnvloedt. De factoren hebben invloed op de vorm van de data of het gemak waarmee een betrouwbaar niveau behaald wordt, beïnvloeden, ofwel op de betrouwbaarheid, bruikbaarheid of significantie van de uitkomsten van een kennismodel.

  1. Systeemdiversiteit
  2. Systeemtoegankelijkheid
  3. Tooling
  4. Kennisdomein
  5. Product/Dienst catalogus
  6. Klant complexiteit
  7. Team Competenties
  8. Organisatie

Bepaal voor uw bedrijf het punt in de grafiek. Als genoeg bedrijven dat doen, zal een gebied ontstaan van haalbare omstandigheden en onhaalbare. In een grafiek ziet dat er als volgt uit.

Bandwidth

De bandbreedte is puur illustratief en staat allerminst vast. Het gebied van haalbare situaties zal in kwadrant I in werkelijkheid veel groter zijn. Grofweg kun je stellen dat het dieper in III betekenisloos wordt. Aan de bovenkant is techniek de beperking, omdat meer data beschikbaar is dan tijdig en betaalbaar verwerkt kan (zeker als ook snelheid/volatiliteit wordt meegenomen). Aan de rechterkant is de complexiteit te beperking, omdat het niet haalbaar is consistente semantiek aan te brengen binnen de beschikbare resources. Hoe de grafiek er precies uitziet maakt ook niet veel uit, want het punt hier is dat BigData niet vanzelfsprekend zinnige/bruikbare/rendabele modellen oplevert. Er zijn echter manieren om wel binnen de bandbreedte te geraken.

Oplossingen

Hoe zorgt men ervoor om de juiste voorwaarden te creëren voor bruikbare modellen? Het moge inmiddels duidelijk zijn dat kwadranten II en IV de juiste omstandigheden reeds hebben. De uitdaging zit in kwadrant I en III.

Kwadrant I

  1. Snoeien in verzameling Hiermee worden de factoren 4, 5 en misschien wel 6 verlaagd. Het beperkt in ieder geval foutieve data en inconsistenties.
  2. Kies subdomein  Dit dwingt min of meer focus te houden en beperkt zo de complexiteit van klantgroep of catalogus.
  3. Semantic Synthesis De term Semantic Synthesis is voorgesteld door Primal.com. Het betekent: Leg vocabulaires aan en voorzie content van semantische annotaties. Maak het model idealiter zelf-lerend. Er zal tooling bij komen om als laag over de bestaande data heen te leggen. Ook vereist het een verhoogde systeem toegankelijkheid om dit de tooling ten volle te benutten.

Kwadrant III

  1. Koop data Door enerzijds het domein uit te breiden door gerelateerde (sub)domeinen bij te kopen, verschuift de positie in de grafiek naar rechts. Anderzijds door de hoeveelheid data te vergroten om statische modellen betrouwbaarder te maken, beweegt de positie omhoog.
  2. Koppel aan externe databronnen Zelfde voordelen als het kopen van data. Het voordeel hiervan is dat de toegevoegde data leeft, ofwel de diversiteit en omvang en vorm van de externe bronnen zijn veranderlijk en groeiend. Daarmee verhoogt de kans op het verkrijgen van nieuwe inzichten.
  3. Creëer een platform al dan niet met concurrentenHiermee wordt de systeemdiversiteit verlaagd en toegankelijkheid verhoogd/vereenvoudigd. Er is ook nog een schaalvoordeel in de gebruikte tooling op het platform, wanneer het platform met concurrenten wordt opgezet. Daarnaast gelden dezelfde voordelen als het kopen van of koppelen aan externe data.

Conclusie

Het antwoord op de subvraag of “Big Data voor elk bedrijf weggelegd is” luidt dus: Neen, niet elk bedrijf kan zondermeer waarde halen uit beschikbare gegevens, ook niet als er heel veel van is. Er zijn wel mogelijkheden om tot waardevolle inzichten te komen, maar die vereisen enige aanpassing van een of meerdere factoren. Die mogelijkheden worden in een aantal oplossingen beschreven. Mochten bovenstaande oplossingen niet passend of uitvoerbaar zijn, dan zou het volgende credo wel kunnen helpen.

Gewoon doen! Begin in een klein (sub)domein. Ook al is het onrendabel, misschien zal met tijd, oefening en ervaring ook een bewegen naar het juiste kwadrant plaatsvinden. Achteraf wordt dan misschien duidelijk wat er gaandeweg veranderd is.


Voetnoten

Big Data = Meer data dan een conventioneel Relational Database Management System (RDBMS) aankan, meer datasets samen, over tenminste twee van de drie assen Hoeveelheid, Snelheid en Diversiteit.

Analyse = De bewerking van onderzoeksgegevens met behulp van technieken van de beschrijvende en inferentiële statistiek. Inferentiële Statistiek is het toetsen van hypothesen en het schatten van steekproefgrootheden en hun betrouwbaarheid.

Correlatie = Min of meer (lineaire) samenhang tussen twee variabelen. Dit kunnen twee reeksen metingen of mogelijke waarden van twee toevalsvariabelen zijn.

1) Gebonden = klein feitelijk zoals ’lijsten met fietsonderdelen’

2) Ongebonden = subjectief zoals een politieke verhandeling

(3) Bij statistische methoden laat de relatieve schaarste van de gegevens met betrekking tot specifieke interesses grote gaten in de verkregen kennis modellen.

(4) Een ontologische benadering is een formele representatie van kennis over een set van concepten binnen een domein en de relaties tussen deze concepten. Zie http://www.w3.org/TR/owl-features/. Voor ontologische benaderingen maken grote collecties van complexe sub-domeinen binnen elk gebied kennistechnologie onbetaalbaar.

Economie van BigData

IT GOVERNANCE – BY ROSS AND WEILL

About the book

(2004, ISBN 978-1591392538)
Stop thinking about IT as an isolated function and start developing it as an organizational competency.

About the Authors

Peter Weill is the Director of the Center for Information Systems Research (CISR) and a Senior Research Scientist at MIT’s Sloan School of Management. Jeanne W. Ross is Principal Research Scientist at CISR

Outline of the book

Chapter 1 describes the introduction and goal of this book.

Chapter 2, 3 and 4. Those chapters review the questions governance must address respectively a) what decisions to make, b) who should make the decisions and c) how to make and monitor the decisions.

Chapter 5. Discusses how IT governance influences enterprise outcomes by showing how top-performing enterprises govern differently from typical enterprise.

Chapter 6. Discusses how enterprises can use the Governance Design Framework to design and assess governance.

Chapter 7. Focuses on the unique environments of not-for-profit and government enterprises.

Chapter 8. Wraps up by presenting a list of symptoms of poor governance and a list of ten management principles for effective IT governance. It also shows how incentives and reward systems affect IT governance design and performance.

Essence

Define IT Governance as specifying the decision rights and accountability framework to encourage desirable behaviour in using IT. IT governance is not about making specific IT decisions – that’s for managers and the same for implementing decisions – but rather determines who systematically makes and contributes to those decisions. Effective IT governance is the single most important predictor of the value an organization generates from IT. There are six key assets through which enterprises accomplish their strategies and general business value: Human Assets, Financial Assets, Physical Assets, IP Assets, Information and IT Assets, Relationship Assets. Enterprises with common governance mechanisms across multiple assets perform better. Governance is about answering only three questions:

  1. What decisions must be made?
  2. Who should make these decisions?
  3. How will we make and monitor these decisions?

For the first two questions there is a matrix called Governance Arrangement Matrix to plot how the Governance Archetypes are used for different types of decisions. The Archetypes are:

  • Business Monarchy: Top Managers;
  • IT Monarchy: IT Specialists;
  • Feudal: Each business unit making independent decisions;
  • Federal: Combination of the corporate center and the business units with or without IT people involved;
  • Duopoly: IT group and one other group;
  • Anarchy: Isolated individual or small group decision making.

The Types of Decision are:

  • IT Principles: Clarifying the business role of IT;
  • IT Architecture: Defining integration and standardization requirements;
  • IT Infrastructure: Determining shared and enabling services;
  • Business Application needs: Specifying the business need for purchased or internally developed IT applications;
  • IT Investment and prioritization: Choosing which initiatives to fund and how much to spend.

Also the book introduces the IT Governance Design Framework. The framework contains three fields which tell how to harmonize each field on enterprise strategy and what to harmonize between each field. [See figure 1-3 on page 13.]

How can this book help you

The goal of this book in the first place is to give executive readers specific ideas for management changes that will make a difference in the performance of their enterprise. IT Managers will have a framework, best practices and clear examples of how to work with their business colleagues to improve their IT Governance.

This book describes an approach to systematically planning IT input and decision rights in key IT decisions. The model it describes relies on two tools: The Governance Arrangement Matrix and the Governance Design Framework.

The book is also a call to action! The role and value of information has changed significantly in recent decade. [Maybe include page 22 information bullets] Information and IT are the least understood and most poorly utilized key asset in many enterprises.

Abstract

Chapter 1

Eight reasons to depict the importance of IT Governance.

It pays off

Study shows firms pursuing a specific strategy with above-average IT Governance had superior profits as measured by a three-year- industry-adjusted return on assets.

IT is expensive

As investment in IT increases rapidly and to ensure that value is created enterprises have to create or refine IT governance structures to focus on spending on strategic priorities.

IT is pervasive

IT spending originates from all over the enterprise.

New technologies bombard enterprises with new opportunities

To respond to technology-induced market changes, foresight is more likely if an enterprise has formalized governance processes for harmonizing desirable behaviours and IT principles.

Critical to organizational learning about IT

Value results not only from incremental process improvement but also from the ability to respond to competitive pressures. It can be difficult to determine in advance how much a new capability or additional information is worth.

IT value depends on more than good technology

Successful firms not only make better IT decisions, they also have better IT decision-making processes. Specifically, successful firms involve the right people in the process.

Senior management has limited bandwidth

Carefully designed IT governance provides a clear, transparent IT decision-making process that leads to consistent behaviour linked back to senior management vision while empowering everyone’s creativity.

Leading enterprises govern IT differently

All top performers’ governance made the tensions such as standardization versus innovation transparent.

Chapter 2 – Five key IT decisions: Making IT a strategic Asset

This chapter discusses the question what decisions have to be made. Therefore it introduces a framework “Key IT Governance Decisions”. [See figure 2-6 on page 54 for an overview of key questions to solve for each key decision field.]

IT Principles decisions

IT principles are a related set of high-level statements about how IT is used in the business. If they are not clear, it is unlikely that other decisions will coalesce meaningfully. IT Architecture decisions translate IT principles into requirements for integration and standardization and then delineate a technical roadmap for providing needed capabilities. IT investment and prioritization decisions marshal resources to convert principles into systems.

IT Architecture decisions

The IT Architecture is the organizing logic for data, applications, and infrastructure, captured in a set of policies, relationships, and technical choices to achieve desired business and technical standardization and integration. Process integration for instance provide a single face to customer or to move seamlessly from one function to the other.

IT Infrastructure decisions

The focus and timing of infrastructure initiatives can have a significant impact on the enterprise’s performance. Infrastructure applications are more stable, changing less with evolving business strategies than do the local applications. Determining where to locate infrastructure services, how to price services, when to update services, and whether to outsource services are key infrastructure decisions. Getting this right means providing cost-effective services that position the enterprise for rapid adoption of new business applications.

Business Applications decisions

Identification of business needs for IT applications often has two conflicting objectives – creativity and discipline. Creativity is about identifying new and more effective ways to deliver customer value using IT. Discipline is about architectural integrity. In other words, business application needs decisions require reconciling complex change and opposing organizational forces. Therefore managers responsible for defining requirements must distinguish core process requirements from nonessentials and know when to live within architectural constraints.

IT Investment and prioritization decisions

IT Investment decisions address three dilemmas.

  1. How much to spend. In successful firms senior management focus on the strategic role that IT plays in the organization and establish an enterprise wide function level that will enable technology to fulfill its objective.
  2. What to spend. As a commercial lens on IT investment, many enterprises find it useful to think of it as a portfolio, just as individual investors have. Implementing such approach requires each investment for each project or budget line item to be classified into categories reflecting business objectives.
  3. How to reconcile different needs – or Aligning IT investment with strategic priorities. The most important attribute of a successful IT. Investment processes must reconcile the demands of individual business units as well as demands to meet enterprise wide needs.

Chapter 3 Archetypes for allocating decision rights

[See figure 3-1 on page 59.]
This chapter is about putting the Archetypes and Decision types in a matrix. The decision types are split in an input and decision part. Research shows significant variation in governance patterns. Comparisons are a starting point to IT governance design. Ask the question: “Can you explain the difference between your enterprise’s governance and the most common approach?” An inability to describe the difference indicates a need to rethink governance design in your enterprise! [The most common/typical approach is depicted in figure 3-4 on page 64.]

Chapter 4 Mechanisms for implementing IT Governance

[Take a look at figure 4-3 on page 109 first.] This chapter shows different mechanisms to implement performing IT governance. Effective governance deploys three different types of mechanisms:

  • Decision making structures. Organizational units and roles responsible for making IT decisions;
  • Alignment processes. Formal processes to ensure that daily behaviours are consistent with IT policies and provide input back to decisions;
  • Communication approaches to disseminate IT governance principles and policies and outcomes of decision making processes.

Large enterprises find governance wanting unless they attend to all three types of mechanisms. The decision-making structures paragraphs discuss the mechanisms for every archetype. The key alignment processes are the Investment Approval Process, Architectural Exception Process, Service Level Agreement, Chargeback, Project Tracking, Formal Tracking of Business Value. The communicating approaches are intended to announce about IT governance decisions and processes and related desirable behaviours throughout the enterprise.

The mechanisms should exhibit three characteristics:

  • Simple. Mechanisms unambiguously define the responsibility or objective for a specific person or group;
  • Transparent. How the mechanism works is clear to those who are affected or want to challenge governance decisions;
  • Suitable. Mechanisms engage individuals in the best position to make given decisions.

Mechanisms do not act in isolation, however. The impact of governance mechanisms depends on interaction among the mechanisms. There are five principles for designing effective sets of mechanisms.

  • Choose mechanisms from all three types;
  • Limit decision-making structures;
  • Provide for overlapping membership in decision-making;
  • Implement mechanisms for multiple levels in the enterprise;
  • Clarify accountability.

Chapter 5 What IT Governance works best

To answer this question ask the question how to assess IT governance first. [See figure 5-1 on page 120.] To assess the governance performance there is a questionnaire in appendix B. Assessing this model shows seven characteristics of top governance performers.

  • More managers in leadership positions could describe IT governance;
  • Engage! (Communicate);
  • More direct involvement of the senior leaders in IT governance;
  • Clearer business objectives for IT investment (just a few important);
  • More differentiated business strategies (based on value disciplines);
  • Fewer renegade and more formally approved exceptions;
  • Fewer changes in governance form year to year.

Chapter 6 Linking strategy, IT governance and performance

If IT is not generating value, senior management should first examine its IT governance practices. [See figure 6-1 on page 149 which shows the essence of this chapter.] [more?]

Chapter 7 Government and not-for-profit organizations

In many ways, IT governance in not-for-profit organizations is the same as for profit-seeking firms. The differences are important and stem from a more complex value creation setting. Successful IT governance in those organizations relies even more on partnerships and joint decisions between business and IT leaders as well as heavier use of formal mechanisms such as committees. Changing governance arrangements less often in not-for-profit organizations is even more important as the time to communicate and implement new procedures is often longer.

Chapter 8 Leadership principles for IT governance

Good governance improves IT decision-making and performance. Governance design is about getting the right people to make IT decisions and monitor performance.

Symptoms of ineffective governance

  • Senior management senses low value from IT investment. If everyone on the senior management team cannot point to a record of how recent IT investment have been performing, governance is a problem;
  • IT is often a barrier to implementing new strategies. Typically these problems arise from application silos where systems were developed with no enterprise architecture;
  • The mechanisms to make IT decisions are slow or contradictory. Effective governance comes from a set of well-designed and well executes mechanisms that reinforce desirable behaviour. Also, if the exception process is not fast and predictable, individuals will be motivated to act outside the system. If renegade exceptions are in evidence, governance is a problem;
  • Senior management cannot explain IT governance. The ability to articulate the key components of the enterprise architecture and understand how they enable and constrain business processes is becoming an important managerial competency;
  • IT projects often run late and over budget;
  • Senior management sees outsourcing as a quick fix for IT problems. In other words, outsourcing as a quick fix motivated by frustration with IT outcomes suggests that governance is a problem. To be effective, outsourcing should result from a decision that particular competencies or services are better provided eternally;
  • Governance changes frequently. Governance need not be changed with every small strategic change or shift in emphasis. Management decisions typically change as strategy change. Governance is who makes the decisions, and thus changes less often than strategy.

Steps for reviewing and designing IT Governance

The above symptoms must be attacked by rethinking or redesigning IT governance.

  1. Map the enterprise’s current governance onto both diagrams – Governance Design Framework and the Governance Arrangements Matrix;
  2. Compare the two diagrams and ask how well the objectives on the Governance Design Framework are achieved by the arrangements of the Governance Arrangements Matrix;
  3. Audit IT governance mechanisms by asking the questions: How many mechanisms are in use and do they overlap? Are they effective independently or together?
  4. Debate the upper boxes of the Governance Design Framework in a senior management team meeting;
  5. Lead the change and use the diagrams in communication.

Top ten leadership principles of IT Governance

  1. Actively design governance (and regularly review);
  2. Know when to redesign. A change in governance is appropriate when a change in desirable behaviour is required;
  3. Involve senior management;
  4. Make choices. It’s not possible for IT governance to meet every goal, but it can and should highlight conflicting goals for debate. Top performing enterprise handle goals conflicts with a few clear business principles;
  5. Clarify the exception-handling process. Exceptions are how enterprises learn! In IT terms, exceptions challenge the status quo, particularly the IT architecture and infrastructure. The exception process is clearly defined, has only a few stages and successful exceptions are adopted in the architecture;
  6. Provide the right incentives. IT governance is less effective when incentive and reward systems are not aligned with organizational goals;
  7. Assign ownership and accountability for IT Governance. However, first, IT governance cannot be designed in isolation from the other key assets of the firm. Second, the person or group cannot implement IT governance alone. Third, IT assets are more and more important to the performance of most enterprises;
  8. Design governance at multiple organizational levels. The lower levels are influenced by mechanisms designed for higher levels. Thus, start designing for enterprise wide levels, but sometimes starting at business levels is more practical for focus or political reasons;
  9. Provide transparency and education. Effective governance needs confidence. Communicating and supporting IT governance is the single most important IT role for senior leaders;
  10. Implement common mechanisms across the six key assets. In designing IT governance, review the mechanisms used to govern the other key assets and consider broadening their charter to IT rather than creating a new, independent IT mechanism.

Current and future challenges of governance

Enterprises are striving to be more strategically agile. Agility will be achieved by recombining modular business processes and activities to meet the new need. Business process modularity will increasingly depend on an enterprise ability to create standardized, reusable systems, business processes and data components. Enterprises will have to make decisions more quickly. Enterprises will continue to outsource commodity IT services. In the future, describing how much an enterprise spends on IT will be meaningless. IT will be embedded in every process and budget, just like capital.

IT GOVERNANCE – BY ROSS AND WEILL

Book Review: THE ART OF DECEPTION

THE ART OF DECEPTION

Controlling the Human Element of Security

About the book

(2003, ISBN 978-0764542800)

Other books on corporate security focus on hardware and software technology, and do not adequately cover the most serious threat of all: human deception. The purpose of this book, in contrast, is to help you understand how you, your co-workers, and others in your company are being manipulated, and the barriers you can erect to stop being victims. The book focuses mainly on the non-technical methods that hostile intruders use to steal information, compromise the integrity of information that is believed to be safe but isn’t., or destroy company work product.

There’s a popular saying that a secure computer is one that’s turned off. Clever, but false: The pretexter simply talks someone into going into the office and turning that computer on. An adversary who wants your information can obtain it, usually in any one of several different ways. It’s just a matter of time, patience, personality, and persistence. That’s where the art of deception comes in. That’s where the book is about.

 

About the Author

“Despite the media-created myth of Kevin Mitnick, I am not a malicious hacker.” – Kevin Mitnick

Kevin Mitnick (http://en.wikipedia.org/wiki/Kevin_Mitnick) born August 6, 1963 is an American computer security consultant, author and hacker. In 1999, he was convicted of various computer and communications-related crimes. At the time of his arrest, he was the most-wanted computer criminal in the United States.[4] He now runs a security firm named Mitnick Security Consulting, LLC that helps test a company’s security strengths, weaknesses, and potential loopholes, and is the Chief Hacking Officer of security awareness training company KnowBe4.

Definition

Social Engineering uses influence and persuasion to deceive people by convincing them that the social engineer is someone he is not, or by manipulation. As a result, the social engineer is able to take advantage of people to obtain information with or without the use of technology.

Examples

The book is full of incredible examples and therefore a real pleasure to read. Every example concludes with some suggestions to prevent certain type of cons. The last few chapters put all those guides and principles together to form a good guideline for your company to harden and protect yourself to social engineers (assuming your technical security is in place).

The examples are somewhat lengthy for an abstract or book review, but they illustrate so well what the book is about and they are so amusing to read. Therefore I have picked two examples and put them at the end of this review. You could read them in advance if you like to get the idea.

Outline of the book

In Part 1 reveals security’s weakest link and shows you why you and your company are at risk from social engineering attacks.

In Part 2 you’ll see how social engineers toy with your trust, your desire to be helpful, your sympathy, and your human gullibility to get what they want. Fictional stories of typical attacks will demonstrate that social engineers can wear many hats and many faces. If you think you’ve never encountered one, you’re probably wrong.

Part 3 is the part of the book where you see how the social engineer ups the ante, in made-up stories that show how he can step onto your corporate premises, steal the kind of secret that can make or break your company, and thwart your hi-tech security measures. The scenarios in this section will make you aware of threats that range from simple employee revenge to cyber terrorism. If you value the information that keeps your business running and the privacy of your data, you’ll want to read Chapters 10 through 14 from beginning to end. It’s important to note that unless otherwise stated, the anecdotes in this book are purely fictional.

In Part 4 The corporate talk about how to prevent successful social engineering attacks on your organization is discussed. Chapter 15 provides a blueprint for a successful security-training program. And Chapter 16 might just save your neck – it’s a complete security policy you can customize for your organization and implement right away to keep your company and information safe.

Finally, a Security at a Glance section, which includes checklists, tables, and charts that summarize key information you can use to help your employees foil a social engineering attack on the job. These tools also provide valuable information you can use in devising your own security-training program.

Essence: THE HUMAN FACTOR

Testifying before Congress not long ago, I explained that I could often get passwords and other pieces of sensitive information from companies by pretending to be someone else and just asking for it. It’s natural to yearn for a feeling of absolute safety, leading many people to settle for a false sense of security. Consider the responsible and loving homeowner who has a Medico, a tumbler lock known as being pickproof, installed in his front door to protect his wife, his children, and his home. He’s now comfortable that he has made his family much safer against intruders. But what about the intruder-who breaks a window, or cracks the code to the garage door opener? How about installing a robust security system? Better, but still no guarantee. Expensive locks or no, the homeowner remains vulnerable. Why? Because the human factor is truly security’s weakest link. Security is too often merely an illusion, an illusion sometimes made even worse when gullibility, naivete, or ignorance come into play. The world’s most respected scientist of the twentieth century, Albert Einstein, is quoted as saying, “Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.” In the end, social engineering attacks can succeed when people are stupid or, more commonly, simply ignorant about good security practices. With the same attitude as our security-conscious homeowner, many information technology (IT) professionals hold to the misconception that they’ve made their companies largely immune to attack because they’ve deployed standard security products – firewalls, intrusion detection systems, or stronger authentication devices such as time-based tokens or biometric smart cards. Anyone who thinks that security products alone offer true security is settling for. the illusion of security. It’s a case of living in a world of fantasy: They will inevitably, later if not sooner, suffer a security incident. As noted security consultant Bruce Schneier puts it, “Security is not a product, it’s a process.” Moreover, security is not a technology problem – it’s a people and management problem. As developers invent continually better security technologies, making it increasingly difficult to exploit technical vulnerabilities, attackers will turn more and more to exploiting the human element. Cracking the human firewall is often easy, requires no investment beyond the cost of a phone call, and involves minimal risk.

 

Contemporary side note: TERRORISTS AND DECEPTION

Of course, deception isn’t an exclusive tool of the social engineer. Physical terrorism makes the biggest news, and we have come to realize as never before that the world is a dangerous place. Civilization is, after all, just a thin veneer. The attacks on New York and Washington, D.C., in September 2001 infused sadness and fear into the hearts of every one of us – not just Americans, but well-meaning people of all nations. We’re now alerted to the fact that there are obsessive terrorists located around the globe, well – trained and waiting to launch further attacks against us. The recently intensified effort by our government has increased the levels of our security consciousness. We need to stay alert, on guard against all forms of terrorism. We need to understand how terrorists treacherously create false identities, assume roles as students and neighbors, and melt into the crowd. They mask their true beliefs while they plot against us – practicing tricks of deception similar to those you will read about in these pages. And while, to the best of my knowledge, terrorists have not yet used social engineering ruses to infiltrate corporations, water-treatment plants, electrical generation facilities, or other vital components of our national infrastructure, the potential is there. It’s just too easy. The security awareness and security policies that I hope will be put into place and enforced by corporate senior management because of this book will come none too soon.

How can this book help you

I hope this abstract encourages you to read the book yourself. If you know enough by now, then, at least read the final two chapters which will explain how to harden your human pitfalls to social engineers and try to imagine how well you are prepared:

Information Security Awareness and Training and Recommended Corporate Information Security Policies

The measures in those chapters are rather general, all very true, but the most important and differentiating in this book are the tables and checklists below about how to Identify a Social Engineered Attack.

IDENTIFYING A SECURITY ATTACK

The Social Engineering Cycle

ACTION DESCRIPTION
Research May include open source information such as SEC filings and annualreports, marketing brochures, patent applications, press clippings, industry magazines, Web site content. Also Dumpster diving.
Developing rapport and trust Use of insider information, misrepresenting identity, citing those  known to victim, need for help, or authority.
Exploiting trust Asking for information or an action on the part of the victim. In reverse sting, manipulate victim to ask attacker for help.
Utilize information If the information obtained is only a step to final goal, attacker returns to earlier steps in cycle till goal is reached.

 

Common Social Engineering Methods

  • Posing as an employee of a vendor, partner company, or law enforcement
  • Posing as someone in authority
  • Posing as a new employee requesting help
  • Posing as a vendor or systems manufacturer calling to offer a system
  • patch or update
  • Offering help if a problem occurs, then making the problem occur, thereby manipulating the victim to call them for help
  • Sending free software or patch for victim to install
  • Sending a virus or Trojan Horse as an email attachment
  • Using a false pop-up window asking user to log in again or sign on with password
  • Capturing victim keystrokes with expendable computer system or program
  • Leaving a floppy disk or CD around the workplace with malicious software on it
  • Using insider lingo and terminology to gain trust
  • Offering a prize for registering at a Web site with username and password
  • Dropping a document or file at company mail room for intraoffice delivery
  • Modifying fax machine heading to appear to come from an internal location
  • Asking receptionist to receive then forward a fax
  • Asking for a file to be transferred to an apparently internal location
  • Getting a voice mailbox set up so call backs perceive attacker as internal
  • Pretending to be from remote office and asking for email access locally

 

Warning Signs of an Attack

  • Refusal to give call back number
  • Out-of-ordinary request
  • Claim of authority
  • Stresses urgency
  • Threatens negative consequences of non compliance
  • Shows discomfort when questioned
  • Name dropping
  • Compliments or flattery
  • Flirting

 

Common Targets of Attacks

TARGET TYPE EXAMPLES
Unaware of value of information Receptionists, telephone operators, administrative assistants, security guards.
Special privileges Help desk or technical support, system  administrators, computer ooperators, telephone system administrators.
Manufacturer / vendor Computer hardware, software manufacturers, voice mail systems vendors.
Specific departments Accounting, human resources.

 

Factors That Make Companies More Vulnerable to Attacks

  • Large number of employees
  • Multiple facilities
  • Information on employee whereabouts left in voice mail messages
  • Phone extension information made available
  • Lack of security training
  • Lack of data classification system
  • No incident reporting/response plan in place

Example 1 – CREDITCHEX

It’s standard practice at many banks to get a quick thumbs-up or thumbs-down on a prospective new customer credibility. One of the major companies that banks contract with for this information is an outfit we’ll call CreditChex. They provide a valuable service to their clients, but like many companies, can also unknowingly provide a handy service to knowing social engineers.

The First Call: Kim Andrews

“National Bank, this is Kim. Did you want to open an account today?”

“Hi, Kim. I have a question for you. Do you guys use CreditChex?”

“Yes.”

“When you phone in to CreditChex, what do you call the number you give them–is it a ‘Merchant ID’?”

A pause; she was weighing the question, wondering what this was about and whether she should answer. The caller quickly continued without missing a beat:

“Because, Kim, I’m working on a book. It deals with private investigations.”

“Yes,” she said, answering the question with new confidence, pleased to be helping a writer.

“So it’s called a Merchant ID, right?”

“Uh huh.” [confirmative]

“Okay, great. Because I wanted to male sure I had the lingo right. For the book. Thanks for your help. Good-bye, Kim.”

The Second Call: Chris Talbert

“National Bank, New Accounts, this is Chris.”

“Hi, Chris. This is Alex,” the caller said. “I’m a customer service rep with CreditChex. We’re doing a survey to improve our services. Can you spare me a couple of minutes?”

She was glad to, and the caller went on:

“Okay – what are the hours your branch is open for business?” She answered, and continued answering his string of questions.

“How many employees at your branch use our service?”

“How often do you call us with an inquiry?”

“Which of our 800-numbers have we assigned you for calling us?”

“Have our representatives always been courteous?”

“How’s our response time?”

“How long have you been with the bank?”

“What Merchant ID are you currently using?”

“Have you ever found any inaccuracies with the information we’ve provided you?”

“If you had any suggestions for improving our service, what would they be?”

And:

“Would you be willing to fill out periodic questionnaires if we send them to your branch?”

She agreed, they chatted a bit, the caller rang off, and Chris went back to work.

The Third Call: Henry McKinsey

“CreditChex, this is Henry McKinsey, how can I help you?”

The caller said he was from National Bank. He gave the proper Merchant ID and then gave the name and social security number of the person he was looking for information on. Henry asked for the birth date, and the caller gave that, too. After a few moments, Henry read the listing from his computer screen.

“Wells Fargo reported NSF in 1998, one time, amount of $2,066.” NSF – –non sufficient funds – is the familiar banking lingo for checks that have been written when there isn’t enough money in the account to cover them.

“Any activities since then?”

“No activities.”

“Have there been any other inquiries?”

“Let’s see. Okay, two of them, both last month. Third United Credit Union of Chicago.” He stumbled over the next name, Schenectady Mutual Investments, and had to spell it. “That’s in New York State,” he added.

The Con

All three of those calls were made by the same person: a private investigator, working on a case for a woman who would like to divorce, but first wanted to know where large parts of the marriage savings were secretly transfered to by her husband.

Analyzing the Con

This entire ruse was based on one of the fundamental tactics of social engineering: Gaining access to information that a company employee treats as innocuous, when it isn’t.

MItnick Message

Kevin ends every example with a message of how to help strengthen your security strategy and recognise the malintentions of a social engineer.

Example 2 – THE ART OF FRIENDLY PERSUASION

Angela’s Caller

Place: Valley branch, Industrial Federal Bank

Time: 11:27 A.M

Angela Wisnowski answered a phone call from a man who said he was just about to receive a sizeable inheritance and he wanted information on the different types of savings accounts, certificates of deposit, and whatever other investments she might be able to suggest that would be safe, but earn decent interest. She explained there were quite a number of choices and asked if he’d like to come in and sit down with her to discuss them. He was leaving on a trip as soon as the money arrived, he said, and had a lot of arrangements to make. So she began suggesting some of the possibilities and giving him details of the interest rates, what happens if you sell a CD early, and so on, while trying to pin down his investment goals.

She seemed to be making progress when he said, “Oh, sorry, I’ve got to take this other call. What time can I finish this conversation with you so I can make some decisions? When do you leave for lunch?”

She told him 12:30 and he said he’d try to call back before then or the following day. 

Louis’’s Caller

Major banks use internal security codes that change every day. When somebody from one branch needs information from another branch, he proves he’s entitled to the information by demonstrating he knows the day’s code. For an added degree of security and flexibility, some major banks issue multiple codes each day. At a West Coast outfit I’ll call Industrial Federal Bank, each employee finds a list of five codes for the day, identified as A through E, on his or her computer each morning.

 Place: Same.

Time: 12:48 P.M., same day.

Louis Halpburn didn’t think anything of it when a call came in that afternoon, a call like others he handled regularly several times a week.

“Hello,” the caller said. “This is Neil Webster. I’m calling from branch 3182 in Boston. Angela Wisnowski, please.”

“She’s at lunch. Can I help?”

“Well, she left a message asking us to fax some information on one of our customers.”

The caller sounded like he had been having a bad day. 

“The person who normally handles those requests is out sick,” he said.

“I’ve got a stack of these to do, it’s almost 4 o’clock here and I’m supposed to be out of this place to go to a doctor’s appointment in half an hour.”

The manipulation–giving all the reasons why the other person should feel sorry for him–was part of softening up the mark. He went on,

“Whoever took her phone message, the fax number is unreadable. It’s 213-something. What’s the rest?” 

Louis gave the fax number, and the caller said, “Okay, thanks. Before I can fax this, I need to ask you for Code B.”

“But you called me,” he said with just enough chill so the man from Boston would get the message. 

This is good, the caller thought. It’s so cool when people don’t fall over at the first gentle shove. If the, don’t resist a little, the job is too easy and I could start getting lazy. To Louis, he said,

“I’ve got a branch manager that’s just turned paranoid about getting verification before we send anything out, is all. But listen, if you don’t need us to fax the information, it’s okay. No need to verify.”

“Look,” Louis said, “Angela will be back in half an hour or so. I can have her call you back.”

“I’ll just tell her I couldn’t send the information today because you wouldn’t identify this as a legitimate request by giving me the code. If I’m not out sick tomorrow, I’ll call her back then.”

“The message says ‘Urgent.’ Never mind, without verification my hands are tied. You’ll tell her I tried to send it but you wouldn’t give the code, okay?”

 Louis gave up under the pressure. An audible sigh of annoyance came winging its way down the phone line.

“Well,” he said, “wait a minute; I have to go to my computer. Which code did you want?”

“B,” the caller said.

He put the call on hold and then in a bit picked up the line again. “It’s 3184.”

“That’s not the right code.”

“Yes it is–B is 3184.”

“I didn’t say B, I said E.”

“Oh, damn. Wait a minute.”

Another pause while he again looked up the codes.

“E is 9697.”

“9697–right. I’ll have the fax on the way. Okay?”

“Sure. Thanks.”

Walter’s Call

“Industrial Federal Bank, this is Walter.”

“Hey, Walter, it’s Bob Grabowski in Studio City, branch 38,” the caller said.

“I need you to pull a sig card on a customer account and fax it to me.”

The sig card, or signature card, has more than just the customer’s signature on it; it also has identifying information, familiar items such as the social security number, date of birth, mother’s maiden name, and sometimes even a driver’s license number. Very handy to a social engineer.

“Sure thing. What’s Code C?”

“Another teller is using my computer right now,” the caller said. “But I just used B and E, and I remember those. Ask me one of those.”

“Okay, what’s E?”

“E is 9697.”

A few minutes later, Walter faxed the sig card as requested.

Donna Plaice’s Call

“Hi, this is Mr. Anselmo.”

“How can I help you today?”

“What’s that 800 number I’m supposed to call when I want to see if a deposit has been credited yet?”

“You’re a customer of the bank?”

“Yes, and I haven’t used the number in a while and now I don’t know where I wrote it down.”

“The number is 800-555-8600.”

“Okay, thanks.”

Vince Capelli’s Tale

The son of a Spokane street cop, Vince knew from an early age that he wasn’t going to spend his life slaving long hours and risking his neck for minimum wage. His two main goals in life became getting out of Spokane, and going into business for himself. The laughter of his homies all through high school only fired him up all the more–they thought it was hilarious that he was so busted on starting his own business but had no idea what business it might be.

Secretly Vince knew they were right. The only thing he was good at was playing catcher on the high school baseball team. But not good enough to capture a college scholarship, no way good enough for professional baseball. So what business was he going to be able to start? One thing the guys in Vince’s group never quite figured out: Anything one of them had—a new switchblade knife, a nifty pair of warm gloves, a sexy new girlfriend, if Vince admired it, before long the item was his. He didn’t steal it, or sneak behind anybody’s back; he didn’t have to. The guy who had it would give it up willingly, and then wonder afterward how it had happened. Even asking Vince wouldn’t have gotten you anywhere: He didn’t know himself. People just seemed to let him have whatever he wanted.

Like the time he had to look into the bank accounts of a guy named Joe Markowitz. Joe had maybe worked a shady deal on a one-time friend of his, which friend now wanted to know, if he sued, was Markowitz flush enough that the friend might get some of his money back? Vince’s first step would be to find out at least one, but preferably two, of the bank’s security codes for the day. That sounds like a nearly impossible challenge: What on earth would induce a bank employee to knock a chink in his own security system? Ask yourself–if you wanted to do this, would you have any idea of how to go about it?

For people like Vince, it’s too easy. People trust you if you know the inside lingo of their job and their company. It’s like showing you belong to their inner circle. It’s like a secret handshake. He didn’t need much of that for a job like this. Definitely not brain surgery.

Vince: All I needed to get started was a branch number. When he dialed the Beacon Street office in Buffalo, the guy that answered sounded like a teller. “This is Tim Ackerman,” he said. Any name would do, he wasn’t going to write it down. “What’s the branch number there?” “The phone number or the branch number, he wanted to know, which was pretty stupid because I had just dialed the phone number, hadn’t I? “Branch number.” “3182,” he said. Just like that. No, “Whad’ya wanna know for?” or anything. ‘Cause it’s not sensitive information, it’s written on just about every piece of paper they use.

Step Two, call the branch where my target did his banking, get the name of one of their people, and find out when the person would be out for lunch. Angela. Leaves at 12:30. So far, so good. 

Step Three, call back to the same branch during Angela’s lunch break, say I’m calling from branch number such-and-such in Boston, Angela needs this information faxed, gimme a code for the day. This is the tricky part; it’s where the rubber meets the road. If I was making up a test to be a social engineer, I’d put something like this on it, where your victim gets suspicious–for good reason–and you still stick in there until you break him down and get the information you need. You can’t do that by reciting lines from a script or learning a routine, you got to be able to read your victim, catch his mood, play him like landing a fish where you let out a little line and reel in, let out and reel in. Until you get him in the net and flop him into the boat, splat! So I landed him and had one of the codes for the day. A big step. With most banks, one is all they use, so I would’ve been home flee. Industrial Federal Bank uses five, so having just one out of five is long odds. With two out of five, I’d have a much better chance of getting through the next act of this little drama. I love that part about “I didn’t say B, I said E.” When it works, it’s beautiful. And it works most of the time. Getting a third one would have been even better. I’ve actually managed to get three on a single call–“B,” “D,” and “E” sound so much alike that you can claim they misunderstood you again. But you have to be talking to somebody who’s a real pushover. This man wasn’t. I’d go with two. The day codes would be my trump to get the signature card. I call, and the guy asks for a code. C he wants, and I’ve only got B and E. But it’s not the end of the world. You gotta stay cool at a moment like this, sound confident, keep right on going, Real smooth, I played him with the one about, “Somebody’s using my computer, ask me one of these others.” We’re all employees of the same company, we’re all in this together, make it easy on the guy–that’s what you’re hoping the victim is thinking at a moment like this. And he played it right by the script. He took one of the choices I offered, I gave him the right answer, he sent the fax of the sig card.

Almost home. One more call gave me the 800 number that customers use for the automated service where an electronic voice reads you off the information you ask for. From the sig card, I had all of my target’s account numbers and his PIN number, because that bank used the first five or last four digits of the social security number. Pen in hand, I called the 800 number and after a few minutes of pushing buttons, I had the latest balance in all four of the guy’s accounts, and just for good measure, his most recent deposits and withdrawals in each.

 Everything my client had asked for and more. I always like to give a little extra for good measure. Keep the clients happy. After all, repeat business is what keeps an operation going, right?

Analyzing the Con

The key to this entire episode was obtaining the all-important day codes, and to do that the attacker, Vince, used several different techniques. He began with a little verbal arm-twisting when Louis proved reluctant to give him a code. Louis was right to be suspicious–the codes are designed to be used in the opposite direction. He knew that in the usual flow of things, the unknown caller would be giving him a security code. This was the critical moment for Vince, he hinge on which the entire success of his effort depended. In the face of Louis’s suspicion, Vince simply laid it on with manipulation, using an appeal to sympathy (“going to the doctor”), and pressure (“I’ve got a stack to do, it’s almost 4 o’clock”), and manipulation (“Tell her you wouldn’t give me the code”). Cleverly, Vince didn’t actually make a threat, he just implied one: If you don’t give me the security code, I won’t send the customer information that your co worker needs, and I’ll tell her I would have sent it but you wouldn’t cooperate. Still, let’s not be too hasty in blaming Louis. After all, the person on the phone knew (or at least appeared to know) that co worker Angela had requested a fax. The caller knew about the security codes, and knew they were identified by letter designation. The caller said his branch manager was requiring it for greater security. There didn’t really seem any reason not to give him the verification he was asking for. Louis isn’t alone. Bank employees give up security codes to social engineers every day. Incredible but true. There’s a line in the sand where a private investigator’s techniques stop being legal and start being illegal. Vince stayed legal when he obtained the branch number. He even stayed legal when he conned Louis into giving him two of the day’s security codes. He crossed the line when he had confidential information on a bank customer faxed to him. But for Vince and his employer, it’s a low-risk crime. When you steal money or goods, somebody will notice it’s gone. When you steal information, most of the time no one will notice because the information is still in their possession.

 

Mitnick message

Verbal security codes are equivalent to passwords in providing a convenient and reliable means of protecting data. But employees need to be knowledgeable about the tricks that social engineers use, and trained not to give up the keys to the kingdom.

Book Review: THE ART OF DECEPTION

Book Review: 101 Design Ingredients to Solve Big Tech Problems

According to the title, the book I ran into is a book about solving problems: 101 Design Ingredients to Solve Big Tech Problems. Since I have many problems to solve, I did not hasitate to buy and read it.

The author of the book is Eewei Chen. He is a former teamleader at Microsoft, creative director at Conchango, creative director at ThoughtWorks Europe, and design director at British Sky Broadcasting (BSKYB). I guess he knows stuff and sounds reliable on the matter. The publisher is well known for the series on programming languages, mainly Ruby, and product development using Agile methodology. This book is in that sense very applicable.

The book is easy to read. It is about common pitfalls and problems in projects. Problems are solved through an ingredient. Ingredients are then combined, as you may well know from your culinary experiences, into recipes, a recipe to achieve a goal. Indeed, a recipe will only work with the right ingredients, just like your homemade cake. Many of the examples and descriptions of the ingredients can easily be to related to. That aside, it is not in the least a technical book. Actually it describes typical project or entrepreneur pitfalls. The author abstracts those pitfalls into a few rules of thumb from which the ingredients have emerged.

Therefore the book will be a good reference in many future projects. In fact, before you start, think about your recipe for success and search for the right ingredients. Then integrate them in your projectplan or projectapproach.

Imagine a typical project and its context. Look at technique, approach and methodology as ingredients. The recipe is the description on how you will deliver your project, stating what should be done. This recipe should be transparant to the stakeholders. For example, read into ingredient 3: “Promote your team”. If we can not apply this ingredient, you should not start in the first place.

So much for the promotion. There is one little downfall, only one really: The magical number 101. Very lyric, but 51 would have been sufficient. There is much repetition of the essence of ingredients while they only differ in word or context. Nonetheless each and every of the 101 (and ten recipes) are very inspiring.

Book structure

All ingredients are divided into four groups, respectively:

1. Ingredients to get you started,
2. Ingredients to keep you going,
3. Ingredients to help you cross the finish line,
4. Ingredients to get more of what you want,

The book concludes with ten recipes for success. Every recipe is a combinations of ingredients and a description how to use them.

Ingredient structure

Each ingredient consists of a title, a witty cartoon with a motto and an appropriate quote of some respectable deceased person. Then a problem statement and its solution generally consisting of three rules of thumb. The ingredient is completed by the references it is based on.

Recipe structure

Finally, the author shows how several ingredients combined in a recipe help to solve a problem. A recipe has a title, a motto and a problem description. Then it lists a few appropriate ingredients with a description on how it should be applied by giving a real-live example. A recipe containing just ingredients is not very useful, so it ends with tips how and when to apply the recipe in general.

Example Ingredient

Let me give you one example by fully copy an ingredient. Of course to select one from 101 good ingredients was harsh and everyone else would have chosen another one. I have chosen ingredient 30: “Make It Easy”,  because my observation is that this one reflects a pitfall for many development teams.

Make It Easy

Quote:
“The less effort, the faster and more powerful you will be.” — Bruce Lee, martial artist

Motto: “If there is an easier way, do it that way.”

The Problem:

Teams try to do too much at the same time, so they end up delivering below-par results, leaving customers and investors confused and disappointed.

The Solution:

Help your team complete tasks as easily as possible by finding the path of least resistance.

Simplify decisions. Don’t make things harder than they need to be. Refer to Occam’s razor as a heuristic to find the fewest assumptions and risks needed to proceed with your project. If off-the-shelf software is just as good, cheaper, and easier to integrate, use it instead of building your own.

Do less. Expending extra effort increases the likelihood that you’ll be unable to complete a project. Promise less to start with, and over-deliver. Add functionality once you know it is needed. Do less to achieve more by managing complexity.80 Get rid of unnecessary functionality or processes.

– Give examples. Use relevant case studies to show your team and other stakeholders how new ideas have been successfully applied before. Refer to best practices they can access, adopt, and use to justify decisions. Make it as easy as possible for teams to understand, apply, and discover what’s possible until they are capable and motivated enough to continually apply the ideas themselves.

Example Recipe

There are only 10 recipes, so picking one as an example is easier. Especially the following is striking. It is so typical for a small agency trying to build a longterm relationship with a large enterprise with other large competitors working in the same field. This recipe describes how to become a preferred partner in such a situation.

A Recipe for Lean Startup in Large Organizations

Motto:
“Do the minimum and fine-tune what you’ve got.”

Lean startups validate their business models by testing their products or services with real customers early and often. There’s absolutely no reason why large organizations can’t embrace this philosophy to get cross-platform digital experiences validated within weeks of discussing an idea. I set up HaaYaa,271 a cooperative of highly creative and skilled individuals, to help large organizations create and refine proof-of-concept prototypes until there are no doubts that customers really want these organizations’ new products and services. At the same time, I ensure these organizations meet important business requirements. Being big doesn’t mean you can’t think small.

Looking to create awesome experiences that customers actually want and that businesses will see as a good investment? These ingredients will keep you lean, mean, and superkeen:

1. Test Your Biggest Hypothesis First

Test risky and mission-critical assumptions as early as possible. If you don’t prove or disprove these first, you will waste time building on unproven facts. I have taken unproven assumptions about what customers like or dislike, and used them to create digital concepts that can be tested within the first few weeks of the start of most projects—first in focus groups and later as interactive HTML prototypes. These can include new navigation ideas, payment models, and innovative interactions on mobile devices, tablets, and interactive TV.

2. Slice It Thinly 

Do the minimum needed to test your idea effectively. Focus on key functionality to get your core value proposition across clearly. Ensure the correct brand messaging is in place and aim to delight customers. I encourage putting systems into place for frequent and early testing of digital prototypes. This allows basic value-added services like saving or sharing to be validated before advanced features, such as personalization, are added. Build in more depth of functionality after you’re confident that the basics are in place and that you have created a core set of services customers find really useful.

3. Timebox It

Limiting the time to achieve tasks and still delivering something of value takes discipline, creative thinking, and a whole lot of trust. Start by prioritizing what’s important, and allow time to make changes when you fine-tune ideas later. I empower customer-experience teams to work with the entire business to reduce the time needed to complete tasks while still raising the dev and user-experience qualitybar. Shortening the time to complete and validate ideas means there is time to fine-tune and enhance ideas once they had been through usability testing. Be clear about what needs to be achieved in the time given, though.

4. Fail Fast, Fail Often

Get stakeholders to acknowledge it’s best to know as early as possible what does not work. Treat each stage of a project as an experiment you can learn from to make improvements. I urge customer-experience teams to run successive rapid iterative tests and evaluations to get customer validation and reveal new insight.I also challenge design and development teams to make improvements quickly between subsequent tests.

5. Check the Data

Identify data across key experiences that indicate success and failure. Analyse the data; gain enough insight and validated learning to make improvements. To keep track of the results of these improvements, I set up customer-experience teams to work with data-analytics teams on monitoring usage stats to see each improvement’s effect on groups of cohorts. I also recommend running multivariate tests on variations of a design concept to see which one is most successful.

6. Build Up Enough Momentum

Make continuous improvements until you have a product or service that truly delights. Multiple projects owned by different parts of the organization are usually run in parallel. The core functionality, enhancements, and new features of each project are tested, and then they are quickly connected, retested, and refined into one holistic experience. Constantly challenge, test for usability, and keep fine-tuning from proof of concept throughout delivery, until the customer experience hangs together well enough to go live.

Tips on How to Apply This Recipe

Start with small projects and show success quickly. Once these have proven to work, tackle larger projects. Find other departments you can approach, and show them the benefits of being involved in a new and more successful way of doing things. Try to get buy-in from peer and senior management. (I’ve been able get CEOs, CTOs, and CIOs to buy into the value of customer-experience design.) For example, you might agree to bring native mobile-perating-system design and front-end development resources into the customer-experience team. This can improve and speed up proof-of-concept creation, validation, and design iteration. I’m a huge lean-startup and lean-user-experience fan. Having worked for large media companies in the roles of design director and head of customer experience, I have always championed the need for early customer validation. I used the insight gained to reassess business needs and evolve projects to make them more relevant and effective before launch. I’ve also implemented post-launch support systems, using continuous design and improvement to ensure projects preserve their relevancy.

Book Wrap Up

In general the book is about driving innovation, demonstrate courage, commence small and simple, know the need, be clear, and build a team. It gives you the right clues how to achieve those higher goals whether you are an agency, a team member or a startup. Good luck with this useful guide to success!

Book Review: 101 Design Ingredients to Solve Big Tech Problems