Three kinds of a MDM Data Model that comes with a tool

Differences in an off-the-shelf model, a buildable model and a dynamic model, when buying MDM solution from a vendor. #AbhiSrivastava, #MDM, #MDMDataModel

Liliendahl.com

Master Data Management (MDM) is a lot about data modelling. When you buy a MDM tool it will have some implications for your data model. Here are three kinds of data models that may come with a tool:

An off-the-shelf model

This kind is particularly popular with customer and other party master data models. Core party data are pretty much the same to every company. We have national identification numbers, names, addresses, phone numbers and that kind of stuff where you do not have to reinvent the wheel.

Also, you will have access to rich reference data with a model such as address directories (which you may regard as belonging to a separate location domain), business directories (as for example the Dun & Bradstreet Worldbase) and in some countries citizen directories as well. MDM tools may come with a model shaped for these sources.

Tools which are optimized for data…

View original post 185 more words

Advertisements

UK introduces new Data Protection Bill, because, you know, GDPR

Digital Minister Matt Hancock has confirmed the UK government will introduce a new data protection law. “It will provide everyone with the confidence that their data will be managed securely and safely.

Source: UK introduces new Data Protection Bill, because, you know, GDPR

GDPR: PII Data vs. Personal data

b8218ceb-2e27-4405-88eb-541da0d8237c

The European Union’s new General Data Protection Regulation (GDPR), which goes into full effect in May 2018, significantly strengthens the data privacy rights of consumers and the requirements on companies that solicit and retain customer identities. Positive part about GDPR is that companies cannot hide, and It applies to all companies anywhere in the world those do business in Europe and/or retain EU citizen’s data.

The US-based Personally identifiable information (PII) and the European concept of Personal Data make up a critical demarcation line related to data types and privacy consequences. To get compliant with GDPR, one has to understand the difference between the way two-legal systems approach the concept of personal information and its meaning in the context they are used. PII is any data that could potentially identify a specific individual. Any information that can distinguish one person from another and can be used for de-anonymizing anonymous data can be considered PII.

PII, or SPI (sensitive personal information), as used in information security and privacy laws, is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. PII term is used in US context that is created on the basis of commonly used US law. Examples of PII data–full name, maiden name, social security number, phone number, email address, asset information, owned properties etc. Little variation may be observed from states to states.

Personal Data is defined in the EU Directive 95/46/EC and it covers much wider range of information that may include transaction history, social media posts, photographs and other data that relates to an individual or identifiable person, directly or indirectly. Personal data term applies to all 28 EU states of European Economic Area (EEA). The concept reflects European law maker’s intention to bring the concept of privacy as a fundamental human right and draw the accountability of handling this sensitive data by business.

We can say all PII data is personal data but not all personal data is PII data. It is important that data and IT architects along with Data Protection Officer (DPO) consider personal data beyond the narrow scope of PII, especially US based companies, to build a successful GDPR compliance program.

GDPR Data Portability and Master Data Sharing

The title of this blog caught my attention for it talks about data portability between competitors. Yes….This scenario is not very far when competitors will share the customer profiles…may be via DaaS (Data as a service). Henrik calls it another “Sunny side of GDPR”. #AbhiSrivastava, #GDPR, #DataArchitecture, #DataPortability

Liliendahl.com

PortabilityOne of the controversial principles in the upcoming EU GDPR enforcement is the concept of data portability.

In legal lingo data portability means: “Where the data subject has provided the personal data and the processing is based on consent or on a contract, the data subject shall have the right to transmit those personal data and any other information provided by the data subject and retained by an automated processing system, into another one, in an electronic format which is commonly used, without hindrance from the controller from whom the personal data are withdrawn.”

In other words, if you are processing personal data provided by a (prospective) customer or other kind of end user of your products and services, you must be able hand these data over to your competitor.

I am sure, this is a new way of handling party master data to almost every business. However, sharing master…

View original post 40 more words

Building an Enterprise Architecture Practice

Encountered this great article by David Torre. He covers some key aspects of Enterprise Architecture practices, EA values, its challenges and deliverables. Read on here –

Center Mast Consulting

Enterprise architecture is similar to electricity in more ways than one. Like electricity, architecture is often out of sight, out of mind. That is until it stops working, at which point it becomes painfully obvious that something integral is missing.

Architecture bears another similarity to electricity: throughout history, plenty of people lived their lives without it. I would have loved to have witnessed some of the early-era electricians trying to “sell” homeowners on the concept of electrification. While the electricians knew how useful electricity was, the homeowners probably rebutted that they got along “just fine” without electricity for many years, so why fork out the hard-earned cash for this newfangled fad called electricity? In many ways, organizations without an enterprise architecture practice have a similar mindset today.

In this article, I’ll articulate the key value proposition of enterprise architecture and enumerate several of my own “lessons learned” during the instantiation of…

View original post 1,724 more words

Data Architecture: How to build the castle?

HNL-gallery-900x400-03_0“Architecture is frozen music.” This famous quote is from 18th-century writer Johann Wolfgang von Goethe. The statement reveals a quality of architecture as a creative discipline. Both architecture and music are wide open to interpretations; however, they intrinsically bind things in harmony. Data architecture is a symphony of data that is collected, stored, arranged, integrated, and put to use in corporations. We dealt with the data architecture definitions and its need with house analogy in my last blog “Data Architecture – What is it and why should we care?”. In the current article, we will recount how to put together the fortress of data architecture.

Architecture frameworks such as TOGAF, Zachman, DoDAF offer us a method to think about systems and architecture. Although plenty of consortia developed, proprietary, defense industry, government and open source frameworks are available, one should use them judiciously because one might overdo things than necessary. There are many research papers available that show that EA frameworks are theoretical and impossible to carry out. With this in mind, experts agree that foundational artifacts are needed to document data architecture. Organizations decide these foundational set of artifacts based on the potential value they provide and the investment they have to make in creating them. These artifacts are integrated set of specifications to define data requirements, to guide integration and control of data assets, and to align with business’ information needs and strategy. An Architect must make sure the coherency and integrity between the artifacts created whether a diagram, data models, and other documents.

DAMA DMBOK divides Enterprise data architecture artifacts into three broad categories of specifications –

  1. The enterprise data model: The heart and soul of enterprise data architecture,
  2. The information value chain analysis: Aligns data with business processes and other enterprise architecture components, and
  3. Related data delivery architecture: Including database architecture, data integration architecture, data warehousing/business intelligence architecture, document content architecture, and meta-data architecture.

Picture2
Enterprise architecture includes data, process, application, technology and business architecture in practice. The business architecture may include goals, strategies, principles, projects, roles and organizational structures. Process architecture has processes (functions, activities, tasks, steps, flow, products) and events (triggers, cycles). Application architecture has macro-level and micro-level application component architecture across the entire application portfolio governing the design of components and interfaces, such as a service-oriented architecture (SOA).  Enterprise architecture includes these aspects.

Picture1

To create the data architecture, one has to define business information needs. The core of any enterprise data architecture is an enterprise data model (EDM). The EDM is an integrated subject oriented data model defining the essential data created and consumed across the enterprise. Building enterprise data model is the first mark in establishing that need and data requirement. Organizations cannot build EDM overnight. Each strategic, and enhancement project should contribute to building it piece by piece. Every project that touches data assets of the organization with its limited scope classifies the inputs and outputs required. These details should list data entities, data attributes, and business rules. One can thus organize these by business units and subject areas. Proper categorization and completeness is key to building the enterprise data model.

Planner View (Scope Contexts): A list of subject areas and business entities.

Owner View (Business Concepts): Conceptual data models showing the relationships between entities.

Designer View (System Logic): Fully attributed and normalized logical data models.

Builder View (Technology Physics): Physical data models optimized for constraining technology.

Implementer View (Component Assemblies): Detailed representations of data structures, typically in SQL Data Definition Language (DDL).

Functioning Enterprise: Implemented instances.

The enterprise data model by itself is not enough. The data model is part of the overall enterprise architecture. It is important to understand how data relates to business strategy, organization, process, application systems, and technology infrastructure. In forthcoming articles, we will go over EDM, information value chain analysis, data delivery architecture and some additional aspects of data architecture.

Plug and Play – The Future for Data

Are we still thinking “Plug and play” is limited to electronic devices only? Not anymore says, Ken O’Connor. Data architects have to think about seamless integration not only within the organization but with the entire business ecosystem.

Liliendahl.com

What does the future for data and the need for power when travelling have in common? A lot, as Ken O’Connor explains in today’s guest blog post:

Bob Lambert wrote an excellent article recently summarising the New Direction for Data set out at Enterprise Data World 2017 (#EDW17). As Bob points out “Those (organisations) that effectively manage data perform far better than organisations that don’t”. A key theme from #EDW17 is for data management professionals to “be positive” and to focus on the business benefits of treating data as an asset. On a related theme, Henrik on this bloghas been highlighting the emergence and value to be derived from business ecosystems and digital platforms.

Building on Bob and Henrik’s ideas, I believe we need a paradigm shift in the way we think and talk about data. We need to promote the business benefits of data sharing via

View original post 587 more words