Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Data Architecture

NOTE: Remember to run in FULL SCREEN mode. You can select this from bottom right of the above presentation screen. Then you can use ARROW KEYS (->) to navigate. Enjoy. Naveed Asem


on 4 May 2018

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Data Architecture

01 |

02 |

03 |

Traditional Approach & Future Trends

Presented By:
Naveed Asem

1 - Why Data?
3) Its COOL
1 0 1 0 1 0 1
0 1 0 1 0 1 0
1 0 1 0 1 0 1
0 1 0 1 0 1 0
1 0 1 0 1 0 1
0 1 0 1 0 1 0
2 - What is Data Architecture?
Structure of and relationship between data
A few other definitions:
Microsoft SQL Server 2012 Bible:
Data Architecture is the overarching
of the database, how database should be
, and how it

My Comments: TOO NARROW !
A Manager's Guide to Data Warehousing:
Data Architecture
how data is
to support the development, maintenance, and use of data by


My Comments: ALMOST THERE !
The Enterprise Data Model: A Framework for EDA:
How data is
processed, stored, and used
systems or people
Allows organizations to
, how it meets

business strategic needs.

What I would add:
Data Management, Data Governance, Data Mastery, and Enterprise Data Model
It's the data and what value it provides that's important and not the technology.
1 - Data Architecture Approach
2 - Data Architecture Components
3 - Enterprise Data Modeling Techniques
1 - Trends Impacting Business
2 - Tech Trends Impacting BI
3 - Tech Trends Impacting Data Architecture
Typical Components:
Business Data Model
Enterprise Data Model
Data Management Process Model
Data Entity/Business Function Matrix
Data Interoperability Requirements

We will only cover the first 2 in this presentation
First 2 Models
Moore's law
= observation that, over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years. The law is named after Intel co-founder Gordon E. Moore, who described the trend in his 1965 paper.
In-Memory Databases
Non Relational DBs
Map Reduce
Cloud Computing
Software As A Service
Internet of Things
Database Software As A Service
Search based Data Discovery
Video Search
Logical Data Warehouse
Web Analytics
Social Analytics & Big Data
MPP Computing
Cloud based Grid Computing
Cloud Collaborations Services
Cloud Parallel Processing
Trend: We check our phones every 9.6 minutes
Increased social connectivity, greater user engagement, product variety and options
Trend: Internet content tripled between 2010 and 2013
Increased content volume, velocity, variety is increasing
Trend: 90% of all internet traffic in 2017 will be video
Lots of unstructured data
Trend: Hug your Data Scienst
Refined target audiences, data-driven approach, data-to-business translation
Trend: Sci-Fi is becoming a reality
Drones <Internet?> , self-driving cars, bitcoins, 3D Printing;
Due to rise of DB appliances & MPP computing,
Inmon & Kimball modeling techniques not sufficient
Unstructured Data now part of Enterprise Data Model
Less Focus on data denormalization
Cloud Computing & Platform Virtualization making easy transform from legacy systems
Data Virtualization reducing a need to move data
Tech Factors
Need service faster, better, cheaper, online, oh and you tell me what i need!
Social connectivity
Extended data use of large data sets
Business Factors
1) To gain high-level
of data architecture,
2) Understand its

, and
3) Learn the

impacting it's future.


+ Architecture Patterns?
+ Standards ???
+ Best Practices ???
+ Improvement ???
+ New Emerging Technologies ???
Database Software As A Service
Search based Data Discovery
Video Search
Logical Data Warehouse
Web Analytics
Social Analytics & Big Data
MPP Computing
Cloud based Grid Computing
Cloud Collaborations Services
Cloud Parallel Processing
+ ??? we can define the next big thing
What can you do to help?

Data Entity/Data Component Catalog
The purpose of the Data Entity/Data Component catalog is to identify and maintain a list of all the data use across the enterprise, including data entities and also the data components where data entities are stored. An agreed Data Entity/Data Component catalog supports the definition and application of information management and data governance policies and also encourages effective data sharing and re-use.
The Data Entity/Data Component catalog contains the following metamodel entities:
• Data Entity
• Logical Data Component
• Physical Data Component
Data Entity/Business Function Matrix
The purpose of the Data Entity/Business Function matrix is to depict the relationship between data entities and business functions within the enterprise. Business functions are supported by business services with explicitly defined boundaries and will be supported and realized by business processes. The mapping of the Data Entity-Business Function relationship enables the following to take place:
• Assign ownership of data entities to organizations
• Understand the data and information exchange requirements business services
• Support the gap analysis and determine whether any data entities are missing and need to be created
• Define application of origin, application of record, and application of reference for data entities
• Enable development of data governance programs across the enterprise (establish data steward, develop data standards pertinent to the business function, etc.)
The Data Entity/Business Function matrix shows the following entities and relationships:
• Data Entity
• Business Function
• Data Entity relationship to owning Organization Unit
Application/Data Matrix
The purpose of the Application/Data matrix is to depict the relationship between applications (i.e., application components) and the data entities that are accessed and updated by them.
Applications will create, read, update, and delete specific data entities that are associated with them. For example, a CRM application will create, read, update, and delete customer entity information.
The data entities in a package/packaged services environment can be classified as master data, reference data, transactional data, content data, and historical data. Applications that operate on the data entities include transactional applications, information management applications, and business warehouse applications.
The mapping of the Application Component-Data Entity relationship is an important step as it enables the following to take place:
• Assign access of data to specific applications in the organization
• Understand the degree of data duplication within different applications, and the scale of the data lifecycle
• Understand where the same data is updated by different applications
• Support the gap analysis and determine whether any of the applications are missing and as a result need to be created
The Application/Data matrix is a two-dimensional table with Logical Application Component on one axis and Data Entity on the other axis.
Conceptual Data Diagram
The key purpose of the Conceptual Data diagram is to depict the relationships between critical data entities within the enterprise. This diagram is developed to address the concerns of business stakeholders.
Techniques used include:
• Entity relationship models
• Simplified UML class diagrams
Logical Data Diagram
The key purpose of the Logical Data diagram is to show logical views of the relationships between critical data entities within the enterprise. This diagram is developed to address the concerns of:
• Application developers
• Database designers
Data Dissemination Diagram
The purpose of the Data Dissemination diagram is to show the relationship between data entity, business service, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained.
Additionally, the diagram may show data replication and application ownership of the master reference for data. In this instance, it can show two copies and the master-copy relationship between them. This diagram can include services; that is, services encapsulate data and they reside in an application, or services that reside on an application and access data encapsulated within the application.
Data Security Diagram
Data is considered as an asset to the enterprise and data security simply means ensuring that enterprise data is not compromised and that access to it is suitably controlled.
The purpose of the Data Security diagram is to depict which actor (person, organization, or system) can access which enterprise data. This relationship can be shown in a matrix form between two objects or can be shown as a mapping.
The diagram can also be used to demonstrate compliance with data privacy laws and other applicable regulations (HIPAA, SOX, etc). This diagram should also consider any trust implications where an enterprise's partners or other parties may have access to the company's systems, such as an outsourced situation where information may be managed by other people and may even be hosted in a different country.
Data Migration Diagram
Data migration is critical when implementing a package or packaged service-based solution. This is particularly true when an existing legacy application is replaced with a package or an enterprise is to be migrated to a larger packages/packaged services footprint. Packages tend to have their own data model and during data migration the legacy application data may need to be transformed prior to loading into the package.
Data migration activities will usually involve the following steps:
• Extract data from source applications (baseline systems)
• Profile source data
• Perform data transformation operations, including data quality processes:
○ Standardize, normalize, de-duplicate source data (data cleansing)
○ Match, merge, and consolidate data from different source(s)
○ Source-to-target mappings
• Load into target applications (target systems)
The purpose of the Data Migration diagram is to show the flow of data from the source to the target applications. The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability. This diagram can be elaborated or enhanced as detailed as necessary. For example, the diagram can contain just an overall layout of migration landscape or could go into individual application metadata element level of detail.
Data Lifecycle Diagram
The Data Lifecycle diagram is an essential part of managing business data throughout its lifecycle from conception until disposal within the constraints of the business process.
The data is considered as an entity in its own right, decoupled from business process and activity. Each change in state is represented on the diagram which may include the event or rules that trigger that change in state.
The separation of data from process allows common data requirements to be identified which enables resource sharing to be achieved more effectively.

Everything around us is data.
Data Architects see things in terms of data and find ways to manage & manipulate data
This image is nothing but 1's and 0's
Even your body movement is captured in data
We are creating TONS and TONS of data.
Cisco predicted we will cross the 1 Zettabyte data usage by year threshold in 2015. We are getting there ...
A study showed how companies are benefiting from this massive amounts of data by industry
Its amazing what you can do with various combinations of 1's and 0's
Data architecture is not this !!!
Some experts look at DA approach based on value it provides. But this view can be a bit vague and incomplete
Almost every enterprise architecture book talks about data integration layers. This is a glimpse of such a view. It seems too complicated and it is missing information architecture
TOGAF's view of DA approach is probably the most complete and simple
Detailed view of TOGAF's approach
This view shows the two business models followed by enterprise data models
Subject Area Model
Business Data Model
Entity-Relationship Model
Following is a high-level overview of a few modeling techniques. No one technique is perfect.
An example of picking a DM Technique
Client Name
Client Name
This commercial is a perfect example of companies reacting to buzz words instead of realizing business value of using new technologies



My interests:
Data | Books | Photography | Sketching
Data Architecture:
Traditional Approach & Future Trends

Make sure to view this in

Full transcript