What is Enterprise Data Management? In some organizations, this is an easy question to answer. However, in others – especially those with an analytical mission – it is much harder. Often the function is put under the Enterprise Architecture team. One often hears that “the Enterprise data folks just do not get it”. As one executive in a large financial organization put it: “EA is where rubber hits the air”. So how do we define a role for the data function within an Enterprise Architecture team?
This post is not about how to organize effectively in order to align with the business units to show business impact – although a worthy topic. This post is about suggesting a role for the enterprise data management team when that team is organized under the CIO within the Enterprise Architecture function of the organization. In order for the data function to be deemed valuable to the business stakeholders it must be understandable, actionable and tied to the business objectives.
Data is everywhere. When we talk about “Enterprise Data Management” the temptation is for managers to say – well that means we manage all data in all locations. As enterprise data managers, we must know all about everything! Really? Have you ever seen this work? This leads to the top down mandate of the “canonical” approach where the objective is a single standard, a single canonical model – a single ring to rule them all! This rarely works well (if at all). Business requirements, analytical activity, market trends, and evolutions in technology all lead to a core business requirement for flexibility. Additionally, there is a fundamental need to recognize that the “ground truth” is almost always with the business side of the house – and “truth” is often a shifting concept in the real world. This is part of the reason why the Enterprise Data Warehouse (EDW) “single version of the truth” is problematic for analytical and BI staff and for the rise of Hadoop as a more flexible environment. As an analytical or BI person, my version of the truth – or the right data – depends on the context of a particular decision.
So how do we focus the EDM team on what makes sense? The graphic in this excellent article on risk architecture caught my eye. I have modified it a bit to identify some core activities that I see as foundational for organizations seeking to mature their data management in general, and specifically, the integration of the enterprise architecture team in the data management process. The original graphic is attributed to Naomi Clarke currently at Credit Suisse.
Based on the above, the role of EDM is simple; manage data assets to expose those attributes that are needed to answer key business questions about data assets:
- What are they?
- Where are they?
- What has happened to them?
- What are they related to?
To do this, one needs a data management “hub”. I call it a Hub as this provides flexibility for discussion purposes. Some would call it a Managed Metadata Environment (MME), others perhaps a Metadata Registry. Regardless, the goal is the metadata ecosystem that can support key functions related to governance, curation, quality, usability and discoverability. This view suggests the following regarding the roles of the EDM team – especially when it is organized within the EA Team:
- The Team needs to only manage three inputs: lineage metadata; definitions, and the physical location (what, where and change). The way the organization creates those three inputs is part of an overall data strategy, but not something the EDM team drives – these are driven by the business. By focusing in this way, the Enterprise team leaves it up to the business or operational components to determine the optimal approaches.
- Definitions are aligned to business terms and to “Concept Systems” (as defined in the ISO 11179 Specs). This enables discoverability and complex search approaches based on an understanding of semantic equivalence.
- Data Assets can be classified within the context of an enterprise data reference model (DRM). In most organizations, this supports the governance process. However, in government organizations, the DRM is also used to align policy and strategy objectives to IT activities. See Federal Enterprise Architecture framework for how this works in the US.
- Capabilities to support governance functions must be provided: vocabulary management tools with the capability to curate and link ontologies, taxonomies, controlled vocabularies, etc, data quality tools, and governance tools.
If one can limit the INITIAL scope of the EDM team to these items, it is much easier to tie enterprise activities to the business needs, and provide a set of capabilities that address challenges of high value to the organization: search, discoverability and integration. Evolving the role once these benefits are established is a much easier task.