BACKGROUND
There have been several articles about the role of a Chief Data Officer (CDO) of an enterprise. In this white paper, I discuss the role of a CDO in a business domain within the enterprise. By “business domain”, I am referring to a business area within an enterprise which could either be a line of business (LOB) having a P&L or a shared service such as finance, HR, IT or modeling and analytics. To save space, I will use the terms “domain” and “business domain” interchangeably. While the discussion centers around the modeling and analytics (MA) domain and is based on my experience as a domain Chief Data Officer (CDO) in the financial services industry, the key points carry over to any business domain, across industries, that uses data and analytics in driving its business goals e.g., LOBs, finance, marketing, sales, HR.
List of Acronyms
- CDO: Chief Data Officer
- MA: Modeling & Analytics
- EDO: Enterprise Data Office
ROLE OF A BUSINESS DOMAIN CDO
There is often the question of whether a business domain needs a CDO and, if so, what the role of such a function should be. If this CDO is responsible for meeting the data needs of the domain, like the enterprise CDO is for the enterprise, then what are the skills and capabilities that should be housed within this function to make it most effective.
The MA domain typically produces a lot of data and provides it to the rest of the enterprise and, in many cases, externally as well. Given the importance of this data and the fact that it is produced from the output of complex models and analytic processes that are developed by and well understood only within the MA domain, it is important that the domain take full ownership of such data. Along with governing the data and ensuring its quality, the MA domain is also responsible for any risks associated with the data. The MA domain also needs the capability to respond rapidly to changing business conditions in developing these data solutions.
For any domain that has a scope of data needs comparable to that of the MA domain, it is very effective to have a function – the domain CDO – with single point accountability to meet these needs. For that to happen, the domain CDO function needs to be able to transform and curate data, build necessary data pipelines, govern the data and ensure data quality while maintaining a strong capability for innovation, agility and speed in doing the above. Such a CDO function would, therefore and at a minimum, include data engineering, data governance and control functions. It would also need to develop intimate knowledge of the business domain as well as close working relationships with other functions across the domain, which is typically best enabled when the CDO function resides within the domain.
A domain CDO is also responsible for developing the data strategy for the domain. Within a business domain, there is often a clearer line of sight from the day-to-day activities to the business objectives which can make it easier to envision and execute data strategy. On the other hand, the demands of tactical day-to-day execution call for some discipline to carve out time and space for data strategy planning and execution.
I have discussed the data strategy for a domain at some length separately. A key responsibility of the domain CDO is owning data governance for the domain with purview over all data used and produced by the domain. Other key responsibilities include managing a data quality process for the domain and instilling a data culture within the domain.
In the end, the domain CDO’s primary accountability is to the domain leadership for the success of the domain goals which is another key argument for why the domain CDO needs to be situated within the domain. At the same time, the domain CDO is also connected to the Enterprise Data Office (EDO) and has the responsibility to support it by contributing to the development of enterprise data strategy and standards as well as by simultaneously ensuring that their domain conforms to such standards for data and governance.
Another very important relationship for the domain CDO is with the IT teams both at the domain level and at the enterprise level. While the domain CDO team is more focused on prototyping and developing solutions rapidly, the IT functions are responsible for scaling up these solutions, where needed, and for implementing them in production. IT also serves as a control function by ensuring that the business uses solutions that meet IT enterprise standards and, further, is responsible for technology functions such as platform management, disaster recovery, IT security etc. The domain CDO and IT functions are key partners in meeting current data needs and in growing the capability to meet future needs for the domain. In turn, the domain CDOs and IT functions across the various domains are key stakeholders in enabling the enterprise CDO to deliver similarly for the enterprise.
APPLICABILITY TO OTHER DOMAINS
As noted earlier, the above discussion on the role of a domain CDO and of the domain data strategy applies to any domain which uses analytics in its business decision making. These would include, among others, LOBs, finance, marketing, sales, and HR. Some of these domains e.g., marketing also make use of models in addition to analytics.
The MA domain in financial services has tended to more “defensive” in terms of data strategy as it typically is responsible for measuring risk and supports regulatory and financial reporting objectives such as stress testing of capital and loss reserving. That has started to change in recent years though, in most cases, the domain’s data strategy is still defensive. Domains such as marketing and sales tend to have more “offensive” data strategies as they are looking to use data to uncover new business opportunities or broaden existing ones. The above discussion applies across both defensive and offensive domains and the data quality and data governance process can be calibrated to the needs of the domain e.g., financial reporting typically has a high requirement for data quality since the data feeds financial statements that are reviewed by external stakeholders.
CONCLUSION
Business domains increasingly consume and produce a great deal of data and the goal should, therefore, be to empower them so that they can act with speed and agility in meeting their business objectives, as also recognized by the data mesh concept. A domain CDO’s role in taking ownership of the domain’s data needs by designing and executing a domain data strategy is often key to the domain’s and the overall enterprise’s success.
Comments 1
Pingback: Data Strategy for a Business Domain: An Application of Data Mesh - Ventera