Data and Integration Architecture
Creating a roadmap for service orientation and service consolidation through process execution

models, policies, rules and standards that govern how data is collected, created, stored, transformed and organized


Contextual data models define data architectures that are important to the planner or stakeholder and show how data is interconnected with various parts of the organization. Each contextual model shows "what could happen" if an architecture is adopted. The contextual model gives an overview of what is trying to be achieved. Do you have a series of contextual models for your organization?


Conceptual data models are typically referred to as Entity Relationship Diagrams (ERD). These diagrams describe data from the business domain perspective and detail more structure than Contextual Models. Are your data structures documented into ERDs? Do you know what data models affect each area of your enterprise?

The typical ERD or Conceptual Model shows how data structures are utilized and how they move data in and out of your organization. As such, certain patterns apply when creating these models. There are various disciplines and methodologies that can be used but the endstate should reflect what your data should be doing.


Though an ERD is not required, it is helpful to expand on the Conceptual Data Model and abstract out master data entities, operational and transactional data built on a technology or solution agnosticism. Typically Database Administrators or Systems Analysts design and document the Logical data models. These models show how the data can be replicated, federated, managed and secured. Logical data modeling is an art but can be very effective when looking at current versus future state data architectures.


Physical models are the implementation view of the Logical ERDs. Each physical model is developed so as to be instantiated on a database server. Scripts, tables, columns, constraints, indexes, etc. should be detailed and executable as part of the Physical Model. While it is common to build a relational model, many newer "Big Data" solutions require modeling indexes of documents containing unstructured data.

Developing structured and unstructured data models is not for amateurs. Service Stratum has the experience and understanding to perform this function for your organization. Solid data modeling is essential to fulfill this key architecture.

Developing Master Data Architectures at the various layers of abstraction takes a keen understanding of the organizational stratum.

Figure 1: Open Modeling Group Unified Data Model