Research Post

Enabling data

Enabling data

14 March 2016

Improvements to business process can deliver high-quality enterprise-wide data. The following five tests can improve your processes – the results of which could dramatically improve the inner workings of your firm.

The origin of poor data quality is poor data ownership. Without a clear understanding and good ownership practice in place, data quality controls and governance are treating the symptom but ignoring the cause. Fortunately a lot can be borrowed from successful technology design approaches in order to address this.

Good data quality demands:

  1. that ownership resides within the appropriate place in the organisation,
  2. a sound understanding of what ownership means in practice.

These are two highly interdependent issues. Within this comment piece we briefly explore the first point before exploring the second in some detail.

 

DATA VALIDATION AND ENRICHMENT

All functions within a firm consume data, store data and create data. Every business function needs to validate its inputs because it cannot absolutely trust its quality points to a broader organisational flaw.

Data validation and manipulation locks a large and unnecessary overhead into many organisations. Aside from quality issues, functions that require data enrichment from other sources in the firm often points to poor organisational/process design: the user of the data is duplicating effort that can more readily be undertaken by the provider of the data.

The remediation of these validation and enrichment requirements is addressed in Design rules for business and technology architectures. These issues demand change in the design of the firm.

 

DATA OWNERSHIP

For the other two data management activities – creation and storage – it helps to have clear guiding principles on what ‘ownership’ means in practice.

There is a key difference between the two activities: data creation is a process by which information is sent from your function to the rest of the organisation. These may be KPIs or management information or any attribute required by other business functions. These outputs are part of the purpose of your function, and the consumers are dependent upon them.

Data that is stored but is neither an input or an output of the function is presumed necessary for its operation. In computing terminology this is often referred to as ‘state’ data, since it is generally used to control the flow of computing processes, and therefore the machine can be said to be in a particular ‘state’ or mode of operation. A head of trading may wish some desks to be able to override pre-trade limit breaches, but other desks cannot. This configuration choice is your data.

Data that is created by a business function is data that needs to be properly owned by it; failure to gain ownership hurts the provider of it, the consumers of it and the organisation as a whole. Conversely, data that is an input to a function is data that the function does not and should not own.

But what do we mean by ownership? Are there tests that can be conducted or principals that can be applied to assert good ownership in practice?

In the past, poor data ownership by a systems process (a program or an app) resulted in a ‘core dump’ or ‘general protection fault’... the machine crashes. To avoid these crashes software engineers such as Bjarne Soustroup arrived at some very tight rules on acceptable practices. These rules can be practiced and tested, and readily translate into human activities.

 

THE FIVE TESTS OF DATA OWNERSHIP

The tests are:

Data ownership rule 1: responsibility

As a business function, one aspect of your role is to provide data to whichever other functions require it. This is your responsibility and therefore you own this data. You obtain it, you create it, you maintain it. Its accuracy and the consequences of its use are your responsibility; you are accountable for it.

Data ownership rule 2: authority

If, for whatever reasons, you do not have control over the data that you output then you do not have the authority that you need to meet your responsibility. This can happen with shared technology assets: databases, market data and valuations are common culprits. In such cases it is often the good intentions of ‘maximising reuse’ that have resulted in unintended and disastrous consequences.

Sometimes authority is undermined through organisational factors – other functions are providing data that relates to your function and you do not have authority over it (e.g. you are responsible for valuations, but other business functions perform their own valuations in competition to yours). If you do not have the authority over the data that is socially associated with you then you cannot be responsible for it: therefore, you do not in truth own it.

Data ownership rule 3: commitment

People who have authority over their data are empowered with the information to optimally perform their roles.

Yet the flipside of empowerment is obligation, and this relates to how your duties are performed. If you have responsibility for data provision and the authority to perform it to the required standard (e.g. timeliness and accuracy), but you fail to do so, then your ownership will ebb – others will take control into their own hands (we are all familiar with the concepts and consequences of ‘overrides’).

The first two rules of responsibility and authority are binary; you either own each data item or not. The rule of commitment to the quality of your data is more qualitative, and it is down to the consumers of your data to inform you of their requirements for accuracy and timeliness.

Many banks identify the result of a ‘data definer’ – an independent role operating under the remit of the chief data officer to encourage and ensure firm-wide consistency. Sometimes this data quality requirement takes the form of a service level agreement, e.g. around outsourced administrative functions or between the middle office functions of finance and risk, and their front office suppliers of data.

In any complex organisation there is a high level of interdependency between functions. The performance of the organisation as a whole is limited by the weakest link within it.

Data ownership rule 4: citizenship

Whereas the measure of ‘commitment’ focuses on ‘how’ you meet your responsibilities internally, ‘citizenship’ assesses how you undertake your obligations within the broader context, both across the organisation and over a defined period of time.

Trust is a measure of how predicable you are; if the data that you own is provided to the continual satisfaction of its users, then you are doing your bit in creating a high-trust organisation. But if you are making short-term sacrifices with longer-term implications (for example, high staff turnover leads to erratic trade capture and poor data quality), or if you are imposing conditions on other parts of the organisation (e.g. reconstructing multi-legged trades) then you are not acting as a good corporate citizen.

The citizenship test identifies structural deficiencies within your ownership of data. If other functions have to compensate for you (e.g. build up a historical time series of your data), either now or in the future, then your ownership is incomplete.

Data ownership rule 5: recognition

Finally, in order for you to be considered the proper owner of your data, it is important you are recognised as the owner of it. Functions that own the same, similar or overlapping data are not only increasing the costs for managing it, but potentially adding additional expense for reconciling it.

Conflicts in P&L between the front office and finance are one common example, and likewise there is plenty of overlap between the data required for risk and finance. The recognition test demands very precise definitions of data that embody the quality (the service level) associated with it and thus define its useful purpose.

The recognition tests lie not with the producer of the data, nor with the consumer, but with the other organisational functions who need to be aware that such data is available.

The first two of these tests (responsibility and authority) are introspective – each business function can itemise the data that they are responsible for and express their view as to whether they have sufficient authority over it.

The second two rules (commitment and citizenship) are based upon the views of the consumer of the data. The consumers can likewise itemise the data they are dependent upon and express their views on the quality they receive. If their providers do not pass these tests then the ownership of the supplier needs to be addressed.

The fifth test (recognition) is conducted by unifying the inventories produced from the earlier four tests. If there is a gap between the data that the providers itemise in rules one and two versus what the consumers expect from rules three and four, then this can be closed.

If there is data being generated in rules one and two for which no consumer can be identified, then this data can be dropped and costs can be saved. If there are apparent similarities across the data provided from rules one and two, or between consumers in rules three and four, then these may present opportunities for functional consolidation, and further cost savings.

 

APPLYING THE TESTS OF OWNERSHIP

These five tests are sufficiently tangible to be applied in practice. They can facilitate:

  • analysis of the efficiency and competency of an organisation as pertains to data management on a firm-wide perspective,
  • programmes of organisational design, such as operating models and workflow,
  • detailed analyses of particular business functions, particularly where there are common root causes of breaks,
  • programmes of governance (KPIs) to ensure continual organisational improvement.

For a firm to have proper control over its data and data lineage, every business function needs to pass these five tests. Upgrading an organisation to fulfil these is not simply a matter of regulatory compliance, nor purely an op-risk exercise or a cost reduction exercise. A firm that has concise definitions around all of its functions is a firm that is very adaptable to change – and can bring substantial agility together with massive scale to form a highly competitive and versatile enterprise.

Back to Articles