Development of a data-centric enterprise architecture requires a new approach to data management, one that respects business requirements.
Moving toward a data-centric enterprise architecture also affects relationships between 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.
How to design and implement a data sharing agreement (DSA)
The provision of data services is at the heart of the development of a data-centric architecture. It is enabled 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 (DSA) 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 opposability to the DSA. However, this scope may only be relevant in the relationships between an internal stakeholder and an external stakeholder in the enterprise architecture.
More generally, as suggested by DAMA International, this 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: is the requester of the data and the client of the data service (s);
- The data producer: is the provider of the data and the supplier of the data service (s);
- Data Broker (s): is 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 among 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.
The industrialization of this framework helps to empower all stakeholders, to limit misunderstandings and to improve interoperability inside and outside the enterprise architecture.
Figure 1: Data Office Framework
Within an application management lifecycle, in accordance with the scheduling defined in the diagram above, the DSA can be explained as:
- 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.
What is data governance?
Data governance is exercised over shared data and other related capabilities. It aims to:
- Create a 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
- Establishing 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.
What are the Data Office role, responsibilities, and 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 four 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 direct various actions by staff to carry out these missions:
- Identifying business challenges, data, 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;
How to insert a Data Office into the enterprise organization
A Data Office can be inserted either 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, such as the Chief Financial Officer (CFO). Alternatively, it can be independent of the business and IT and be attached directly to the CEO.
The company business model is important when positioning the Data Office and attaching the Chief Data Officer. There are three models 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 any 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 in which the IT strategy or Operations strategy is directly carried by the CEO. In this case, the Chief Data Officer is attached to the CEO or equivalent.
A Data Office is an essential component of every organization since it oversees and manages the disciplines of data and information creation, definition, usage, and control. Data and information are critical assets to any enterprise, and the development and sustainment of an office / program to manage these assets can help to ensure the continued viability of the organization.