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

systems

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

We will only cover the first 2 in this presentationFirst 2 ModelsExamplesMoore'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 DatabasesNon Relational DBsMap ReduceCloud ComputingSoftware As A ServiceInternet of ThingsDatabase Software As A ServiceSearch based Data DiscoveryVideo SearchLogical Data WarehouseNoSQL DBMSWeb AnalyticsSocial Analytics & Big DataMPP ComputingCloud based Grid ComputingCloud Collaborations ServicesCloud Parallel ProcessingTrend: We check our phones every 9.6 minutesIncreased social connectivity, greater user engagement, product variety and optionsTrend: Internet content tripled between 2010 and 2013Increased content volume, velocity, variety is increasingTrend: 90% of all internet traffic in 2017 will be videoLots of unstructured dataTrend: Hug your Data ScienstRefined target audiences, data-driven approach, data-to-business translationTrend: Sci-Fi is becoming a realityDrones <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 ModelLess Focus on data denormalizationCloud Computing & Platform Virtualization making easy transform from legacy systemsData Virtualization reducing a need to move dataTech FactorsNeed service faster, better, cheaper, online, oh and you tell me what i need!CustomizationSocial connectivityExtended data use of large data setsCompetitionBusiness FactorsGOALs: 1) To gain high-level understanding of data architecture, 2) Understand its current

landscape, and 3) Learn the technology

trends impacting it's future.OPPORTUNITY FOR US !WHATS MISSING for these TRENDS?

+ Architecture Patterns?+ Standards ???+ Best Practices ???+ Improvement ???+ New Emerging Technologies ???Database Software As A ServiceSearch based Data DiscoveryVideo SearchLogical Data WarehouseNoSQL DBMSWeb AnalyticsSocial Analytics & Big DataMPP ComputingCloud based Grid ComputingCloud Collaborations ServicesCloud Parallel Processing+ ??? we can define the next big thingWhat can you do to help?& OpportunityDATA ARCHITECTURE DETAILS:Data Entity/Data Component CatalogThe 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 ComponentData Entity/Business Function MatrixThe 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 UnitApplication/Data MatrixThe 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 createdThe Application/Data matrix is a two-dimensional table with Logical Application Component on one axis and Data Entity on the other axis.Conceptual Data DiagramThe 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 diagramsLogical Data DiagramThe 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 designersData Dissemination DiagramThe 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 DiagramData 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 DiagramData 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 DiagramThe 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 dataThis image is nothing but 1's and 0'sEven your body movement is captured in dataWe 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 industryIts amazing what you can do with various combinations of 1's and 0'sData architecture is not this !!!Some experts look at DA approach based on value it provides. But this view can be a bit vague and incompleteAlmost 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 architectureTOGAF's view of DA approach is probably the most complete and simpleDetailed view of TOGAF's approachThis view shows the two business models followed by enterprise data modelsSubject Area ModelBusiness Data ModelEntity-Relationship ModelFollowing is a high-level overview of a few modeling techniques. No one technique is perfect. An example of picking a DM TechniqueClient NameClient NameThis commercial is a perfect example of companies reacting to buzz words instead of realizing business value of using new technologiesBETTER BUSINESS VALUE