Data Quadrant Model: how to organise the data domain

The Data Quadrant Model (DQM) is typically a model that can be used by an organisation to make sense of their data domain. One of the sense making aspects is 'how to organise' and although every organisation should translate the DQM to an organisation model that fit their context (culture, maturity, timing, people, system landscape, etc..), there might be some heuristics that help you on your way. 

In general the DQM - if travelled from I to II, IV to III (see figure) - will be characterised by increasing
entropy, something I have tried to explain in an earlier blogpost. For the sake of simplicity in this blogpost, the question regarding 'How to organise' is translated into the degree of centralisation versus decentralisation. 

Heuristic: systems with lower entropy are more prone to centralise as opposed to systems with high entropy which are prone to decentralise.

So, quadrant I and quadrant II have the highest propensity to be organised centrally and quadrant IV and quadrant III have the highest propensity to be organised decentrally. 

Easy, peasy..? So we need one central quadrant I organisational entity. Lets go overboard and give it a name; a Data Service Center (DSC). The DSC is comprised of Data- and Information modellers, engineers and architects that model, validate and process the data and give access to the data to serve application development (II), BI professionals (II), data scientists (IV) etc.. 

But how is the DSC organised in different operating models? Lets refresh our memory a bit with the four quadrant model developed by Ross and Weiss in their landmark book ' Enterprise Architecture as strategy'. They identified four types of operating models; diversification, replication, coordination and unification. Yes, my dear data architect, this is stuff you need to know. This is stuff you need to be able to translate to the data domain and advise your management on the consequences. 

I know....I am preaching....sorry

1. In the Diversification quadrant there is low integration as well as low standardisation. There is no shared data and business processes in the different business units are unique. Every business unit will have its own DSC. Hell, every business unit will have its own unique implementation of a DQM. 
2. In the Replication quadrant there are similar business processes across business units but there is no shared data. Every business unit will have its own DSC. Hell, every business unit will have its own DQM. BUT it makes sense to replicate the artifacts (for example, the data models, definitions, tools, etc..).
3. In the Coordination quadrant, business processes in each business unit are unique but several data components (often master data) need to be shared (customers, products, etc..). I would strongly consider one central DSC (one DQM strategy/architecture). The organisational entities on the pull/demand side of the DQM I would tend to decentralise though.  
4. In the Unification quadrant we have globally integrated business processes with support of enterprise systems, data sharing is crucial. This is a no-brainer. A central DSC (one DQM Strategy/architecture)  and even the pull/demand side has a strong tendency to be fairly centralised. 

This all sounds pretty dandy, but the operating model is not the only independent variable that determines how you organise the data domain. Another independent variable is the scarcity of resources. In the data domain we need expertise that might be pretty scarce and an organisation might be forced into centralising/sharing the skills although the operating model is not in sync with it. 

Yesterday, I spoke at the SAS Insight session in the Netherlands and I got asked several times who owned/managed the DQM as a whole? Certainly, the data domain needs central coordination? A good question which of course (?!) got the ultimate consultancy answer; it depends. 

It depends on the operating model and the scarcity of resources. With Coordination and Unification operating models you need one DQM and I would suggest a high level executive that is accountable, either a CIO, CDO (Chief Data officer)¹ or whatever you might call him or her. 

¹ I wrote a blogpost on the CIO versus the CDO last year. 

 

 

Comments

[Ronald Kok]

Hello Ronald, yes you are preaching.

The time is right to open the Damhof church and raise more Damhoveneers. And this is not me being sarcastic.

People abuse data just to keep their job and feel safe. Data is poison. Do not swallow. I don't think we will ever disrupt the money-driven society, but let's give it a try and energize people in gaining trust, energy and a higher quality of life. Let's shift Data from poison to honey!

Are you in?