Enterprise Information Architecture

From MIKE2.0 Methodology

Activity: Enterprise Information Architecture

Objective

This Activity defines the Enterprise Information Architecture relevant to the scope for improved Information Governance. It provides a conceptual model for showing:

• How KDEs relate through the Enterprise Data Model
• What systems KDEs are stored in
• The mastering rules for KDEs
• Propagation requirements for when KDEs should be shared to meet business requirements
• Data Definition and business rules for KDEs
• Map KDEs into one or more of the Four Layers of Information

This is an architectural model that is built out over time, for each increment in the programme. It can be used as an iterative approach to building a complete Enterprise Information Architecture. Current-state artifacts will provide valuable input into building this model – organisations vary greatly in their maturity of having a documented Enterprise Information Architecture.

Major Deliverables

• Enterprise Information Architecture

Tasks

Define Enterprise Data Model

Objective:

The purpose of this task is to define out the organisation’s Enterprise Data Model. It is done at a Conceptual Level, focused on modeling the KDEs across the enterprise environment. The complete model does not need to be built, only that which is relevant to the implementation. This conceptual model can be built out over time.

Input:

• Data Specification Standards
• Data Modelling Standards
• KDEs
• Existing data models

Output:

• Conceptual Enterprise Data Model (focused on in-scope KDEs)

Overlay System Architecture on Enterprise Data Model

Objective:

Once the Conceptual Enterprise Data Model is established, the current-state and future-state application architecture models can be overlaid on top of this model. This is done at a high level, its primary purpose being to show where KDEs reside.

Data Flows between systems can also be shown as part of this architectural model, showing high-level system interfaces and time periods for when data is synchronized.

Input:

• Conceptual Enterprise Data Model (focused on in-scope KDEs)

Output:

• System Architecture mapping to Enterprise Data Model

Define Master Data Management Architecture

Objective:

The Master Data Management Architecture defines the Systems of Record that provide the authoritative source for storage and retrieval of key data elements. When multiple candidate systems exist, the system that provides the highest quality source of the data element and can also meet the timeliness and accessibility requirements will be the preferred source. When a data element is stored in multiple databases, quality information architecture uses the system of record as the source of replication.

The Master Data Management Architecture is determined by mapping a candidate system of record to each KDE using a Data Mastering Model. The Data Master Model defines:

• Primary Masters (System of Record) Primary Master is a system having ownership of a business event and is seen as the authority on this data. There may not always be a primary master for a business event and there can never be more than one primary master.
• Secondary Masters: The Secondary Master has the ability to update relevant elements, but only on reconciliation from the primary master and other secondary masters.
• View Only: A View Only system cannot update, and is only a receiver of data changes.

This task can be done in an iterative fashion, with obvious candidates being defined first. The Data Governance Council reviews this model and can be used to resolve disputes when multiple candidates exist.

Input:

• System Architecture mapping to Enterprise Data Model

Output:

• Data Mastering Model policy governing its usage
• Updated Metadata Repository with Data Mastering Model

Define BusinessTime Model for KDEs

Objective:

Most organisations will have highly federated environments where KDEs will be represented in many systems and data will need to be integrated and exchanged between databases throughout the enterprise.

Time-sensitivity varies by KDE and business event, depending on factors such as:

• Who uses the data?
• What do they do with it?
• What are the business processes supported?
• How do they access the data?
• What is the data quality required?
• What analytics are required?

Using a BusinessTime model for Data Integration provides information to systems based on the time-sensitivity of the operation needed to be performed.

This task should be focused on what is required to meet the needs of the business as opposed to merely showing the current-state. High quality data integration enables the exchange of data in the timeframe required by the business. It is acceptable for some data to be exchanged in batch mode, while the business requires access to other data at the point the business events occur. Data integration should apply commonly to data exchanged within and between enterprises.

Input:

• Business Requirements for Increment
• Data Mastering Model policy governing its usage

Output:

• BusinessTime model, specifying data interchange requirements
• Updated Metadata Repository with Data Mastering Model

Define Data Definitions and Business Rules

Objective:

Data & business rule definition describe the meaning of the data that the enterprise needs to know and specifies the policies that govern business behavior and constraints. This metadata should be stored in a repository and/or data dictionary as opposed to a document-based form. Steps in this task include:

• Documentation of business entities and attribute definitions
• Document business rules for KDEs
• Review KDEs with information users and gain their approval
• Run sample testing to confirm poorly understood business rules.

High quality data and business rule definition completely and accurately describe the meaning of data and the usage of data required by the enterprise. High quality definition is inclusive of all operational and MIS uses of key data elements.

Representatives from the Data Governance Council should review the Data Definitions and Business Rules and has formally approved.

The Business Analysts that conduct the work with the Business Owners will need significant domain experience to actively participate in data definition and business rule definition

Input:

• In-scope KDEs, defined within Enterprise Data Model

Output:

• Definition of key Data Definitions
• Approved KDE Data Definitions and Business Rules are in a metadata repository and make available to information users and IT staff.

Core Supporting Assets

• Business Time Model for Information Development

Yellow Flags

• Very complex Data Mastering rules are identified, i.e. there are many secondary mastering systems or there are no masters in the architecture but there is still a desire to integrate systems
• The organisation wants to make a major shift in their BusinessTime model with little experience in real-time or near real-time integration

Key Resource Requirements

• Business Architect
• Business Analysts
• Information Architect
• Data Stewards

Potential Changes to this Activity

To be a complete Enterprise Information Architecture this should also include a model to incorporate unstructured content. For this to be done, a few tasks would be added to define unstructured content and then bring this together with structured data. This downside of this approach is that it could add complexity - not many organisations are looking this comprehensively at this stage.