Data Management & Decision Support

A new beginning

After you've done a thing the same way for two years, look it over carefully. After five years, look at it with suspicion. And after ten years, throw it away and start all over.  Alfred Edward Perlman, New York Times, 3 July 1958

I started my career with 5 years of working in the service of companies who need data
management¹ to support them in their efforts to be either more competitive or more reliable. Ahold, specifically Albert Heijn and the Pallas project², formed the basis of my career in data management and was also the first jelled team I was part of³.

The next 5 years I worked for various consultancy firms; Vertis (now Ordina), I3 and Cibit. Every one of those taught me valuable lessons in what worked and what did not work. Within Cibit I began giving masterclasses data warehousing in depth and tutoring prep courses for the CBIP certification. 

The last 5 years I was an independent 'jiggler'⁴ with a mission; enhancing the rigor and relevance of data management. Data management was and still is a young field of expertise with a thin body of knowledge, in practice as well as in science. One of the reasons is the extremely limited cross-pollination of other fields of expertise with data management; Quality, Manufacturing, Operational Research, Logistics, Software Engineering, Psychology, Economics, etc.. Hundreds of books and huge piles of academic papers have littered/light up (?!) my path the last 5 years and resulted in various papers, blog posts, tweets, conferences and workshops. In my 'jiggling' efforts I increasingly was able to use this wonderful knowledge for the benefit of my clients. I like to belief that I have had some impact on how we can deliver cost-effective quality data products.

In this day and age, the field of data management and its uses for decision support/enhancement is growing at an unprecedented pace and is getting more and more complex and intertwined. Combined with an evermore accelerating technology advancement, data explosion and increasing demand, we find ourselves in a fascinating era. For an indy like me, keeping up is vital and increasingly challenging.

Instigated by the quality literature, the agile approach in software engineering and the problem solving leadership course⁵ I took in 2011, I got convinced that 'the team' - when empowered - can achieve astounding results in the non-linear world we are living in. And like they say - there is no 'I' in 'TEAM'...

In short; I decided to search for an environment where I can make a difference, where I can learn and contribute and be part of a team of kindred spirits that share the passion of the trade we are in.

SAS and myself go back over a decade where we worked together for various clients. And over the years I became impressed with the company (great place to work, the history), the SAS employees, the approach to the market (very much value based), their products (a.o interoperability, breadth of products, expertise in analytics), their Dataflux subsidiary and a consulting company I admire for quite some time; Baseline Consulting, featuring giants like Jill Dyche and Evan Levy.

In short; I am leaving the lonesome cowboy act and join the SAS stable as of September
1^st 2012. As a Principle Business Solution Consultant I will remain to be focusing on (agile) data management, be part of the the SAS data management team, telling the story that needs to be told, continue blogging and tweeting and assisting customers in formulating their data management strategies and executing them.

Can't wait!

ps. A press release has been issued by SAS regarding my transfer (Dutch only)

1 - The best description of data management in my opinion is the one used by DAMA;http://www.dama.org/i4a/pages/index.cfm?pageid=3548
2 - http://www.grey-matter.nl/pubs/AH_Pallas_NL.pdf
3 - http://www.amazon.com/Peopleware-Productive-Projects-Second-Edition/dp/0932633439
4 - J.Weinberg: 'A jiggler gets an organization unstuck by providing a small change in how the client sees the world'
5 - Jerry Weinberg/Esther Derby/Johanna Rothman

Shu Ha Ri in Data Vault

This blog is loosely based on Lyssa Adkins - Coaching Agile Teams - a great book.

I get often asked whether or not a data vault model complies to the 'rules'. Or - just lately - I had a great free-format brainstorm on a friday afternoon with a data warehouse team of an organization who already practised data vault for like 3 to 4 years. Before I came they said to me - 'Ronald, we might have deviated on data vault rules, so please be aware - it might not be to your liking'.

'Oh my god' I thought to myself - for two reasons;

1) - Who do they think I am - the data vault police?

2) - Please - BREAK THE RULES

 

In agile the wording Shu Ha Ri is often used.

 

Shu: Follow the rule

Ha: Break the rule

Ri: Be the rule

In using Data Vault at first, I understand the need for strict rules, binary answers, right or wrong, black or white. Fine - we want to 'follow the rule' - we are in Shu- state.  

While practising - Ha is reached. The basics has been attained and now time is spend on 'reflecting on the truth of everything'. One comes 'to a deeper understanding of the art than pure repetitive practice can allow' (Cockurn 2008). Put in other words; one begins to 'break free of the rigid instruction of the teacher and begins to question and discover more through personal experience (Shuhari Dojo Martial Arts). Although one breaks free, one still upholds the principles underlying the data vault practice. For example; if you trully understand the princples and motives of modeling the business keys, if you trully understand the deeper meaning behind that...then maybe you are ready to break the rules that implements it!!!

In Ri 'There are no techniques...all moves are natural' (Sensei's library). One is now advancing more through self discovery than by instruction. When in Ri, one may decide to replace certain 'rules' with something else entirely - the replacement is still in line with the principle....You are now the rule...

It is this path that ensures advancement in anything. We need teams, people to surpass the masters, both in knowledge and skill. This is the source of improvement in Data Vault as a whole. If the master is not surpassed, then Data Vault will deteriorate. 

Taking this a bit more generic one might say that people like Dan Linstedt reached 'Ri' state in data warehousing and decided to master their masters and invent new rules - to be that rule. Data Vault came out of that and it improved the practise of Enterprise Data Warehousing.

If peeps/teams are making up new rules - will there eventually be 'Data Vault'? That is a philosophical question and an interesting one. What will remain are the principles, what will evolve are the rules. 

DO NOT EMBRACE 'DATA VAULT', embrace the principles and discover the rules, make new rules, be that rule and thereby contributing to advancements in data warehousing.

Back to the initial question; Ronald - 'Does our model comply to Data Vault Rules'.

What would you think the correct answer is......?

"Data Kwaliteit moet omhoog"

[DUTCH] published on a government discussion blog on february 26, 2012

Tja - als ik weer eens een blog lees met die zin 'Data Kwaliteit moet omhoog' krijg ik toch lichte vorm van uitslag. Vaak zie ik vervolgens een fors betoog waarom dit moet en een appel op (vaak) management om zich hiervoor in te zetten. Vooral in veel bedrijven zie of hoor ik nog wel eens de 'target': 'De data kwaliteit moet dit jaar x% hoger'. Je kunt net zo goed roepen dat je wereldvrede wil…

Alleen al het roepen hiervan resulteert bovendien in het tegenovergestelde effect, zoals Demming in zijn boek Out of of the Crisis uit 1982 al betoogde in zijn 14 points for management: management by objectives (targets) encourages low quality.

Het roepen dat data kwaliteit omhoog moet is simpelweg niet voldoende en zal bovendien resulteren in het tegenovergestelde als daarvoor niet een goed plan is gemaakt om dit te bereiken. Bovendien moet duidelijk zijn welke data kwaliteit. Het is voor mij erg eenvoudig om aan te tonen dat een willekeurige database een enorm slechte data kwaliteit heeft. En ik zou daarvoor een groots plan kunnen maken om e.e.a. te verbeteren, ik sla dan echter wel ff een belangrijk stapje over. Namelijk welke problemen met data kwaliteit zijn relevant.

Het bepalen van relevantie is wat mij betreft de belangrijkste stap; het identificeren van die data kwaliteit problemen die een niet acceptabele direct of indirecte impact hebben op de burger.

Dit is niet makkelijk - sterker nog - dit is moeilijk en vereist mensen met een grote variatie aan competenties. Management, domein experts, analyse experts en technische experts (bij voorkeur met ervaring en kennis van kwaliteit in processen). Het vereist ook dat de handen letterlijk heeeeel vies moeten worden gemaakt - de vingers moeten in de modder en ja dit moet heel dicht bij het primaire proces plaatsvinden. Data kwaliteit kun je niet ff eenzaam op een kantoortje verbeteren. 

Na identificatie van de relevante data kwaliteit problemen komt er een proces van verbeteren. Ook hier zie ik nogal wat naïeve aanpakken. Ik besef trouwens dat ik aan het preken ben nu.....maar goed - aan de lezer de keus om de preek te blijven bijwonen ;-)

'We gaan een project doen' of erger nog 'we gaan beter inspecteren/testen'.

En dan gooi ik de handdoek in de ring. Hou maar op. Stop maar. Zonde van de investering.

Alle iconen in de kwaliteit literatuur (Demming, Juran, Crosby, Weinberg, English, etc..) en de daaruit resulterende kwaliteit inzichten (ISO 9001, Six Sigma, TQM, Agile software development,Lean, etc..) geven een duidelijke en beargumenteerde aanpak die ervan uitgaan dat kwaliteit in de mensen en in het proces/produkt moet zitten. Dat ontwerp je dus niet...dat implementeer je dus niet. Dit gaat veel verder.

In termen van mensen; zorgdragen voor een veilig omgeving waar iedereen kan bijdragen aan het oplossen van problemen. Het onderliggende positieve mensbeeld daarbij is dat alle medewerkers in principe bereid zijn om betere kwaliteit na te streven - altijd! 

In termen van processen; zorgdragen voor een proces dat zichzelf continu kan verbeteren door bijvoorbeeld goed te meten, te interpreteren (statistiek is essentieel hier, bijvoorbeeld kennis van variantie) en te verbeteren. Ook hier moet het adagium zijn dat we meten om te verbeteren, niet om te straffen (zie vorige punt mbt tot veilige omgeving).

Dus - geen project...maar gewoon een reguliere lijn activiteit. En ja, misschien moet je in den beginne data kwaliteit institutionaliseren, maar op de lange termijn natuurlijk niet – het staat op gespannen voet met het principe dat kwaliteit in het product/proces moet zitten en niet in een apart kwaliteit/test-proces of groep mensen die de kwaliteit (te laat) beoordelen.

 

Whitepaper: Kimball Revisited – Context is our guide

Taking sustainability and agility in data modelling to the next level

 

Intro

Both authors (Frederik Hofstra and myself) of this whitepaper are involved in a data warehouse project with a university in the Netherlands. This university implemented a new SAP module; Student LifeCycle Management. A comprehensive module covering all processes from enrolling students, to credit scoring, to progress reports, to eventually graduating. This module is also the main source for master data like the academic structure of programmes and modules, as well as the organisational structure (faculties, divisions, subdivisions, etc.) and the student information.

The strategy of the university is to deliver a service to their organisation that is capable of delivering data in various ‘truths’ to people or information systems and with an array of functionality (e.g.: reporting, analysis, etc.).

The solution architecture consists of two storage layers. The first one is based on Data Vault principles and heuristics and the second one is a dataset layer. The latter is the object of discussion in this paper. This solution architecture is currently available in production mode and is - as such - a proven solution.

 

Abstract

 This paper is all about delivering quality data products. However, quality is by definition a relative construct. Its requirements can only be fixed by the time the user needs the data. Context - as we use the word in this paper - is a function of the person involved at a specific moment in time with the quality attributes he desires. And these contexts change all the time. Accommodating these constant changes is partly covered by continuous innovation in technology. However, the use of innovative technologies does not free us from proper software design. This paper addresses a software design perspective to offer the required agility.

It is a continuing effort in trying to evolve the work of giants like Dr. R. Kimball, W.H. Imnon, B. Devlin, C.Imhoff, D.Linstedt and many many more.

Download 2011 - Damhof, Hofstra - KimballRevisited-Contextisourguide

Tales of a consultant in decision support and data management (3) - Saying 'I don't know'

In my previous post on this topic I talked about  saying 'I don't know' when you do not know how long it takes to finish (say) a project.

But, when pressured enough, engineers are going to guess - and I completely understand!

STOP PRESSURING US.

When planning, if you don't know the answer, don't guess. Explain in your plan exactly what you are going to do to get the answer. Then, when more information is available, update the plan. 

Now, why isn't senior management keen on this? And this is really bugging me, because I want to understand. We - as engineers - really don't know...really...we don't. Why would you insist on an answer you know is not correct at all??

My take on this: because it's not easy. It means that management have to participate throughout the project to make decisions about each tasks as sufficient information becomes available (Agile manifesto principle 4)¹.

 

¹Integrating CMMI and Agile Development- Paul E. McMahon -2011

Agile Data Warehousing - Ralph Hughes visits Data Vault customers

Wednesday November 16^th 2011 Ralph Hughes from Ceregenics was in the Netherlands. Ralph is author of the book 'Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XP'. Ralph is currently under contract to write more books on the topic of agility in data warehouse development.

I had been in contact with Ralph for some time; he wanted to know more about data vault, getting the facts, how it is actually used, what customers use it, how they develop and deploy, how it contributes to agility and how it impacted the business.

Of course, anything can be explained in writing or conceptually, but the 'real proof of the pudding, is in the eating'. Opportunity knocked when Ralph was in the Netherlands for his TDWI course on Agile data warehousing. He asked me whether or not I could arrange some customer visits in Amsterdam. Customers that use and deploy Data Vault and have attained a high agree of agility.

Tom Breur and me were hosts for Ralph and we visited the Free University (client of mine) and BinckBank (client of Tom), both in Amsterdam. Hans Hultgren (Genesee Academy) happened to be in the Netherlands that week and joined us as well. We met with both management and technical team members of the university and BinckBank.

Both clients were particularly interesting because their data warehouses are in production and in a mode of constant change. Both clients showed a remarkable predictability and reliability in coping with these changes. Change equated to 'business as usual'. I remember Ralph asking an engineer 'how long does it take to deploy a new data element to the warehouse?' The engineer replied: 'do you want to know the lead-time including my coffee break?'.

Ralph, Tom, me and Hans were impressed with the accomplishments of these clients in getting their data warehouse deployment in control while constantly adding value/changes to the business in a predictable fashion. 

I will not transcribe the whole interview in this blog - that is simply too much - send me a note if you want to know more. Interesting differences between Free University and BinckBank were the fact that they used different automating techniques and also the level of business key integration differed slightly. Free University used templating (generating XML and import in Business Objects Data Services) for data warehouse automation and the data warehouse was driven by business keys. BinckBank used Quipu for data warehouse automation and the data warehouse was partly driven by business key, and some by surrogate key (see also my presentation on the Data Vault advanced seminar about different Data Vault species - slide 25-30). In terms of software development methods, BinckBank used the Scrum method and Free University was based on waterfall/iterative with lots of lean practises being used.

I will try to summarize both visits from the perspective of me and Tom, particularly slanted towards Agile software development, by asking my blog readers, three questions: 

1. Why is it that you can build and deploy extremely small particles in Data Vault and not in other approaches, without having an increase in the overhead and coordination of these particles? In other words; 'Divide and Conquer to beat the Size / Complexity Dynamic'¹
2. Why is it that you can re-engineer your existing model and guarantee that the changes remain local? Something that is hugely beneficial in data warehouses that - by definition - grow over time.
3. Why is it that - as your (Data Vault based) data warehouse grows - your costs grow ‘merely’ in linear fashion initially, and as you approach the end state marginal growth in cost decreases exponentially (as opposed to exponential cost increase for Kimball warehouses)?

I want to thank Free University as well as BinckBank for offering their time, their energy and enthusiasm to the general cause of knowledge sharing. Of course I want to thank Tom Breur and Hans Hultgren for putting in their time as well. 

My special thanks of course to Ralph Hughes as being an open minded, inquisitive and knowledgeable peer. It was great being your host in the Netherlands. 

 

^{1 - Gerald M. Weinberg - Quality Software Management - 1992}

Photo #1: Left in the corner sits Ralph Hughes, next to him Tom Breur. On the other side the Free University; Jaap Roos (project manager), Dorien Heijting (Data Warehouse Engineer), Erwin Vreeman (Project Lead).

Photo #2: Sitting with the american flag - Ralph Hughes and Hans Hultgren. At the top of the table - BinkBank: Michel Uittenbogaard (Data Warehouse Engineer) and on the right Paul Delgman (BI manager). 

Photo #3: Sitting near the window looking down: me, myself and I

Tales of a consultant in decision support and data management (2) - Saying 'I don't know'

It is hard to admit that you don't know something - this is human nature. But a lot of the time, the pressures mount up. 

CFO: "Ronald, we need the product to be done asap, when do you think it can be ready?"
Me: "well, I can tell you when we will finish, but I will not know exactly what will be done" (I don't know)
CFO: "Huh? Aren't you the expert? We pay you for being the expert, so spit it out"

Now - ask yourself - what kind of consultant are you? Will you eventually cave in to the pressure and call out a number? Or do you dig your heels and persist in 'I don't know'. If you call out a number; please be reminded that the software graveyard is strewn with the carcasses of partially completed projects that were three to five times larger than anyone dreamed¹.

There is a subtle difference between speed and progress. You can drive with 200 miles per hour, but without a map, your progress will be zero. In other words, you need some kind of 'map'/plan and some kind of thoughtful analysis of the problem you wish to solve.

But even so, a plan is just what it is; 'a plan'. THE PROJECT WILL NEVER GO ACCORDING TO PLAN. Why; because most plans I come across envision some kind of fixed end-result. This end-result is often described by means of requirements. Even if we were to embark on a monumental requirements gathering process where we interview all people involved and write down all quality attributes, we would still not have a complete requirements specification that covers the quality demands of our business users (simply because they themselves do not fully comprehend them²). But  apart from that; such an elaborate process simply isn’t attainable.

If the finish line is not precisely known, the number of miles to the finish line is not known either. So - writing down in your 'plan' that the project will take '42' weeks to finish, is just another way of caving in to the pressure of calling a number. Don't do it.....resist....Do not comply.

 

 

If the finish line is not known, why not say 'give me xx amount of time and I will know precisely when I will finish, but I don't know exactly what I will deliver'. Or as Mike Cohn wrote it: 'When we acknowledge that the result is both somewhat unknown as well as unknowable in advance, planning becomes a process of setting and revising goals that lead to a longer term objective'³.

 

So - shouldn't we make a plan? Of course you should make a plan and a thoughful analysis of the problem you want to solve, but refrain from 'painting the finish line'. 

¹ Humprey - Managing the Software Proces - 1990
² Which is especially true for data products where the future use of the data is - by definition - not fully known
³ M.Cohn - Agile estimating and Planning - 2006 

Tales of a consultant in decision support and data management (1) - IT Governance

I often get asked by clients to help them jiggle¹ their decision support or data management efforts. The pattern that unfolds can be described as follows:

1) As any consultant I always want to know why I am being hired. In other words, I ask: 'what are your current problems?' 'Any new challenges on the horizon?'

2) Client; 'we need new tech/tools'

3) Me: 'Then you don't need me, just write a check to the vendor. But again, what problem are you trying to solve?'

4) Client: 'Look, we have all the tech money can buy (me: I’m not kidding, this actually happens), but it is just not working at the moment'

5) Me: 'Hmm, why is it not working for you?'

6) Client: 'it's expensive, changes take forever, business is extremely unhappy and we keep buying more expensive hardware to increase performance'

7) Me: 'ok, so leadtime, quality and costs are a problem?'

8) Client: 'aye'

9) Me: 'and why do you think new tech will help you out?'

10) Client: 'we think this new appliance stuff - super-dooper-in-memory-shared-nothing-all-in-one-box - can save our asses'

By now, a quote comes to mind from Einstein: 'The significant problems we face cannot be solved by the same level of thinking that created them.'

11) Me: 'so how does this new super-dooper tech stuff help increase quality?'

12) Client: 'ehhhhh'

13) Me: 'Is it an idea to first perform a root-cause analysis? Lets try - together with stakeholders - to specify the problem'

14) Client: "We know the problems - we just need tech'

Obviously I am polarizing a bit, but this pattern seems to repeat itself over and over again. Of course, it could also be me ;-), but I do not think I am that special.

There is a lot of publicly available research which proves that technology is an extremely small part of any IT failure. By far the biggest part of the problem is management itself. More precisely: IT governance, or the lack thereof, usually is the core of the problem. Allowing technology to be purchased without proper IT governance is the same as creating waste.

It would be much better to just donate the money to charity.  

If management in IT is incapable of clearly explaining by whom and how decisions are made regarding the use of IT, then how do you expect conformance to principles? Or how do you expect to attain some kind of sustainable robust/pervasive architecture? How do you expect infrastructure (including shared and standard applications) to accommodate the needs of the many? How do you cope with business needs and how to align it with IT? How are investments in IT justified? Who is prioritizing? Who monitors the ROI (and acts on deviations)? Etc.

Obviously in the pattern I described above, I urge my clients to invest in a proper root-cause analysis and retrospective (what went wrong and how can we improve). Then I will try to establish some leading principles, all in the context of data management and decision support. These leading principles will be translated to an 'organizing logic for data, BI applications and infrastructure, captured in a set of policies, relationships and technical choices to achieve desired business and technical standardization and integration'².  

Technology choices, tool choices, vendor choices can be logically derived from this exercise. And don't be surprised if it turns out that you already have all the technology/tools/skills/people you need.....

15) - client: 'ehh....Ronald, that's a lot of work - are you sure - I just wanna buy tech.'

16) - me: 'aye - I am sure - but don’t be fooled - you, my dear management, are in the center of the problem that needs to be solved. It will be hard work...'

Two scenario's unfold now:

1) - Client: bye, bye, Ronald - I think we need another consultant. This happens to me occasionally, and I am perfectly fine with it. I am congruent with myself in my consulting because I sincerely believe this is how it can work. I would not be congruent with myself if I went along in a technology selection process of some kind or implementing some tool that will never solve the real problem.

2) - Client: ok - lets do this.

 

 

1 - A jiggler gets an organization unstuck by providing a small change in how the client sees the world

 2 - IT governance, 2004, Weill, Ross

 

A seminar about valuable innovation in data warehousing

For those of you not present at the Data Vault automation seminar (oct.6 2011); hereby the foreword of the conference proceedings. We are still debating how we will publish these proceedings - will let you know.

Attendees to the Data Vault Automation Seminar,

We would like to welcome you to - what we expect to be - a wonderful conference dedicated to the innovation of passionate people in the industry of data warehousing and business intelligence. These people and their companies discovered methods to further enhance the maturity and professionalism in which we - as an industry - developed data warehouses. Of course, to the great benefit of clients; either to adhere to compliancy regulations, being able to deal with constant changes in the business, boost innovation in product development or to improve and control operational costs.

Tom and myself came up with the idea of this conference simply because we both feel that there is a lot to gain from automating data warehouses. Of course ‘automating’ as such, did not came out of the blue. Examples of companies that laid the groundwork are Kalido and BIReady (where the latter is of Dutch origin). Then in 2007, Data Vault was introduced in the Netherlands¹ by Dan Linstedt, Ronald Damhof, and DNV/CIBIT. Back then we did several courses with mainly senior data warehouse consultants - and we had a blast! The rest is history. Data Vault skyrocketed and the number of Certified Data Vault modelers has since increased rapidly. Without any scientific research to back backing up this claim, it is estimated that the majority of new data warehouse projects in the Netherlands are now based on Data Vault.

In this turmoil of new ways to deliver data warehouses, innovative people and organisations saw opportunities to support and increase the velocity and quality of the delivery process. One of those areas of opportunity is the automation of data warehouse production. And although we originally intended the seminar to be generic, we ended up with automation innovations particularly oriented towards Data Vault.

This conference is a platform for the various innovations to show us their stuff and teach us how we can benefit from their hard work. It is also an opportunity for the attendees to ‘gauge the temperature’ the market of Data Vault innovations by listening and talking to the people behind these innovations. And finally we hope that you take the opportunity to catch up with the community. It is safe to say that just about everybody who has an opinion on Data Vault, will be present.

We would like to thank DIKW- academy and the sponsors for sharing our passion and making it possible to keep the fee for this conference low, thereby contributing to sharing of knowledge and improving ourselves as a community.


Ronald Damhof & Tom Breur

 

 

 

¹ Data Vault was published way before 2007 by of course Dan Linstedt himself and others as well (M.Ketelaars for example)

IQCP, a means to an end - it is all about quality

May 2011 I was given an opportunity to be part of the first group of pioneers that field-tested the IQCP program. IQCP stands for Information Quality Certified Professional and is organized by IAIDQ - the International association for Information Quality and Data Quality.  To be fair; I really do not like certifications. It is said that with certification, clients can have some kind of objective measurement regarding knowledge and skill. Well, for the majority of certifications this is utterly deceiving.

That being said, why did I go for IQCP?

For one thing; IAIDQ is a not-for-profit organisation and vendor-neutral. People involved in IAIDQ are people with a passion to spread the word with regard to quality in general and Information Quality in particular. 

Second; the certification process was extremely well prepared, grounded in known research and adheres to widely accepted standards and regulations such as the ISO/IEC 17024 and the Standards for the Accreditation of Certification Programs, published by the USA National Commission for Certifying Agencies (NCCA, 2002).

Third; I was not mainly interested in the certification as such....To put in poetic; I was interested in the journey, not the destination. The IQCP certification is based on a reference list of books and articles, carefully selected by people who know their stuff. The certification was a ‘carrot on a stick’ to me, pressuring me to actually study and invest time. The deadline was end of July 2011 - I have never in my life read so many books, but I have never in my life been so authentically interested in a subject as well. I just kept reading, because there is so much clever stuff written out there.

Fourth and maybe the most important reason; in may 2011 I also happened to follow the legendary PSL (problem solving leadership) workshop given by Jerry Weinberg, Esther Derby and Johanna Rothman. What I have learned is immense and influences me daily. The root of this workshop is - in my opinion - founded in quality principles; learning, continuous improvement, root-causes, self organizing team, people, communication, understanding the problem, understanding context and so much more. The people I met in this workshop were incredible and a huge inspiration. A lot of the attendees came from the world of context-driven testing and agile software development. Both - in my opinion - strongly rooted in quality principles. 

It somehow all got together when I was asked to participate in the first batch of people to go for IQCP.

For me; IQCP was the means to an end - I have studied amazing books (for a reference list download this pdf) go to written by people like Edwards Deming, Joseph Duran, Jerry Weinberg, Kaoru Ishikawa, Masaaki Imai, Richard Wang and so many more. My library has grown very rapidly lately and I have still so much more to read (learn). Somehow, all I have read, learned and still learning are pieces of a puzzle that fit seamlessly in my field of expertise #datamanagement #decisionsupport #datagovernance #dataquality #datavault #architecture #softwaredevelopment.

The journey never ends....

My gratitude goes to Tom Breur, IAIDQ, Jerry Weinberg, Esther Derby, Johanna Rothman, those crazy canadians ('it is what it is'), Testsidestory, Olav, Markus, Griffin and so many more.

ps. I passed the exam.....I am now an Information Quality Certified professional