Since a Data Office has become a reality in many organizations, what are the foundational components of a successful data office?
Moving towards a data-centric enterprise architecture affects relationships among the organization’s data stakeholders and requires rethinking the data management organization and rules. It also suggests that the integration of these changes in an enterprise architecture can be carried out according to a scheme that respects the enterprise business model.
A data sharing agreement
The provision of data services is at the heart of the development of a data-centric architecture, and the implementation of a data office. Providing data services can be implemented through the formalization of a data services contract, also known as the “data sharing agreement” (DSA).
According to Alvaro E. Arenas & al. (2010), a DSA is a “contract between two or more entities that governs how they share the data. The agreement is generally represented as a set of clauses expressed using the deontic notions of obligation, prohibition and authorization “.
This definition considers the data sharing agreement as a document with a formal structure consisting of:
- Permissions: Clauses that specify the actions allowed to the principal roles, as well as the associated time and location constraints
- Obligations: Clauses that specify the actions to be performed by the principal, or the underlying infrastructure, based on an event and within a time-period known to the parties
- Prohibitions: Clauses that define constraints on permissions, prohibiting actions to specific roles, times, and places
In this definition, the notion of “contract” tends to confer a scope of legal expectations within the DSA. However, this need for legal support may be relevant only in the relationships between an internal stakeholder and an external stakeholder in the enterprise architecture.
More generally, as suggested by DAMA International’s DAMA-DMBOK©, a DSA is an “agreement between the parties that describes the permitted activities, uses and restrictions of data shared between the parties”. Within such an agreement, stakeholders can play one of three roles:
- The data consumer: the requester of the data and the client of the data service (s);
- The data producer: the provider of the data and the supplier of the data service (s);
- Data Broker (s): the issuer and / or receiver of the data and acts on behalf of the data producer and / or the data consumer, respectively.
The diagram below reproduces the articulation between the stakeholders. It breaks down the data sharing agreement by:
- Usage contract: specifies the expectations (data quality requirements, data security, service levels, etc.) of a data consumer vis-à-vis a data producer, as well as the terms of the data delivery
- Interface contract: involves one or more data brokers, providers of data service, and specifies the technical and operational details of the data delivery.
Deploying this framework helps to empower all stakeholders, to limit misunderstandings and to improve interoperability inside and outside the enterprise architecture.
Figure 1: Relationships and actions among stakeholders
Within an application management lifecycle, in accordance with the scheduling defined in the diagram above, the DSA may reflect the following actions:
- The consumer informs the producer of desired data, intended uses and quality, life cycle, security or confidentiality requirements, with associated service levels.
- The producer informs the consumer of the requested data specifications and of the limits of use.
- Each data broker receives the data specifications and associated service level requirements from its client.
- Brokers agree on the technical terms of the data delivery.
- The consumer and the producer plan to record and communicate metrics for service levels monitoring purpose.
- The producer plans to issue a certification (report) based on collected metrics.
- The consumer in turn plans to issue a signoff in agreement with the producer.
Data Governance and a Data Office
Data governance is exercised over shared data and other related capabilities. It aims to:
- Set the common framework for sharing data management capabilities
- Control the implementation and the proper functioning of the common framework
The first objective requires:
- Developing vision and principles of action (policies)
- Setting up a dedicated organization (roles, responsibilities and governance bodies)
- Orienting action plans (strategies)
- Communicating and managing change
The second objective requires the development of mechanisms, procedures and tools for evaluating, monitoring, escalating and resolving data issues. These help to monitor the continued and sustainable implementation of the common framework.
Data Office role, responsibilities, plans
The Data Office is an enterprise architecture building block that manages shared data and other related capabilities. It is also the organizational unit that is responsible for managing this building block.
More specifically, the Data Office provides 4 major missions:
- It develops and supports the execution of the data management strategy
- It develops data services and maintains the catalog of data services
- It develops data management standards
- It develops and ensures the sharing of knowledge and data management standards
These missions are carried out under the direction of a Chief Data Officer (CDO) and in coordination with the data governance bodies. The Chief Data Officer can use a variety of activities to carry out these missions:
- Understanding business challenges, data and its effective management, legacy systems, data issues and data opportunities to develop data management strategy
- Defining the target data architecture to develop the data services catalog
- Managing the shared capabilities’ repositories (tools, architectures, models, procedures, etc.) to ensure the correct creation, use and delivery of data
Inserting a Data Office into the enterprise organization
A Data Office can be inserted at the IT level, with attachment to the Chief Information Officer (CIO). It can also be inserted at the business level with attachment to the Chief Operating Officer or equivalent. It can finally be independent of the business and IT and be attached directly to a CEO.
The company business model is important when positioning the Data Office and attaching the Chief Data Officer. Three models have emerged according to the role of the information system in company operations:
The first is the one in which the information system is at the heart of the business model, in the sense that its unavailability leads to a cessation of the company’s operations. Online retailers (Amazon, eBay, etc.), technology services (Google, Netflix, etc.), financial operators (NYSE, Euronext, etc.), etc. fall into this category. Because the information system is an important part of the business strategy, it is relevant to insert the Data Office at the IT level and to attach the Chief Data Officer to the CIO.
The second is the one in which the unavailability of the information system penalizes without causing the interruption of the company operations. This model remains widespread and applies to banks (excluding online banks), public services (excluding e-administration), etc. In this context, it is more relevant to insert the Data Office at the business level, with attachment to the Chief Operating Officer.
The last is a variant of this first two options, where the IT strategy or Operations strategy is directly managed by the CEO. In this case, the Chief Data Officer is attached to the CEO or equivalent.
In general, in the last two models, a Data Custodian Office can be implemented as an IT relay for the Data Office. The Data Custodian Office mission is to ensure the proper delivery of data services, in addition to the Data Office which has the ultimate responsibility for the proper creation and use of data.
Every organization should have a Data Office and a Chief Data Officer, which are empowered to develop, implement, and manage the enterprise’s data strategy, its data governance, its enterprise data architecture, and relevant other activities.