#data reference model

We all know that enterprise architecture is a strategic-level synthesis of business and technology information to drive enhanced decision-making. To develop the EA we must build out the individual perspectives, such as performance, business, information, services, technology, security, and human capital. This blog focuses on one of those, enterprise information architecture.

Enterprise Information Architecture (EIA) is the strategic-level information architecture for the organization.

Note: Information refers to both information (processed data) and data.

GOAL:

The overall goal of EIA is to provide the right information to the right people anytime, anywhere.

MANDATE:

Legislative:

The federal mandate in law enforcement is the Intelligence Reform and Prevention Act (IRTPA) of 2004. Further, The Office of the Director of National Intelligence (ODNI) has developed the Information Sharing Environment (ISE) Implementation Plan in 2006 and the Department of Defense created the Net-centric Data Strategy in 2001.

Common Sense:

We need information to perform our mission/business function and processes: we can’t do without it! Moreover, in an information economy, information is power and information is currency.

PROCESS:

Developing the enterprise information architecture is an outgrowth of developing the business, data, and system models to understand the business processes, the information required to perform those, and the systems that serve up the information.

According to the Federal Enterprise Architecture, Data Reference Model, there are three parts to developing your information architecture.

Data Descriptions—identify what your information needs are.

Data Context—determining how the information is related.

Data Sharing—developing the mechanisms for discovering and exchanging information.

Data Descriptions is the semantics and syntax. It involves developing your “data asset catalogue” and the metadata. This includes developing a lexicon or data dictionary with harmonized terms and schemas to describe them, as well as tagging the data. This helps define what the terms mean and identifies the rules for arranging them.

Data Context is the relationships. It includes categorizing the information using taxonomies and ontologies. It includes developing models, such as entity relationship diagrams (ERDs) to identify entities or information objects (and their attributes or properties) and associating them.

Data Sharing is the transactional processes. It entails the decomposition of information exchanges (in an Information Exchange Matrix or in a Information Exchange Package Description, IEPD) to determine the provider, the consumer, the trigger, the frequency, the media, the security, and so forth for each type of transaction. This phases also includes developing information repositories/registries, information sharing access agreements, and other mechanisms for sharing the information, such as portals, web services, enterprise service bus (ESB), and so on.

In the federal government, there is a Chief Enterprise Architect in the Office of Management and Budget (OMB) — this is a good thing.

But the question that I have is why there isn’t a Chief Data Architect as well?

We all know that one of the essentials to good architecture is having strong data architecture that provides for data descriptions (or metadata) to uniformly describe data, data context (or taxonomies) for discovery, and that supports data sharing (or exchange).

In the Federal Enterprise Architecture (FEA), there is a Data Reference Model (DRM). Moreover, in the FEA, data is the crucial touch point between on one hand, the business functions toward achieving desired performance outcomes, and on other hand, the services and technologies that serve up the data in order to perform the functions and activities of the enterprise.

Furthermore, in developing technology solutions of the enterprise, one very important question for the business is what their information and data requirements are. The answer to this helps drive the technology solution.

For the federal government, the benefits of maturing its data architecture could be significant, especially in being able to share vital information, and thereby fill gaps and reduce redundancy across the federal enterprise. Given the size and important scope of the federal government missions, the imperative is great!

The Chief Data Architect would focus on data issues and drive such things as data standardization, common lexicon, metadata development, exchange standards and directories, service oriented architecture, and overall information sharing.