A Future-Oriented Approach

Enterprises take on a wide range of projects in the name of “Digital Transformation”. Or seek to set up programs for Data Governance, Master Data Management, Data Catalog, Business Glossary, Data Protection, Data Strategy, etc.

However, legacy systems and technical debt continue to impede many organizations' efforts. And any attempt to use such a burdened environment as a launchpad for future-proof “data” projects and programs is most likely doomed to fail.

Recommendation

The future of informational infrastructure needs to be based on a business-data-driven reference system with well-defined, distinct responsibilities. Prerequisites are

• a Chief Data Office/r as introduced earlier in my post "Pondering on Data and CDO (Chief Data Officer)"
• business division managers who are ready for additional duties, but are also flexible to give up on existing influence...

Here is the industry-agnostic approach that I propose:

1. For each business unit, record the major organizational processing activities
2. For each processing activity, record the major created & updated (business) data structures
3. With recorded data structures, derive (business data) entities & relationships
4. With entities & relationships, build the Enterprise Information Management Map (= high-level concept model)





Example of High-Level Concept Model in Liability Insurance [Click to Enlarge]



5. In the Enterprise Information Management Map, identify master entities and the relationships among them
6. In the Enterprise Information Management Map, assign responsibility for modeling master entities & relationships to Chief Data Office(r) as their Data Domain Owner.
7. Divide the Enterprise Information Management Map by grouping all other entities & relationships into distinct data domains based on similar processing activities and assign modeling responsibility for each data domain (= Data Domain Ownership) to exactly one business division [Note: If necessary, restructure processing activities in a way that each data domain and its creating / updating processing activities belong to only one responsible business division.]

Example of Data Domains in Liability Insurance [Click to Enlarge]

Result

The above approach introduces a reference structure where each data domain within the enterprise concept model is represented by exactly one business division that is responsible to develop & maintain the related business data names, descriptions and constraints for business entities, attributes and relationships.

Outlook

In subsequent posts I will elaborate on this frame to show how to advance enterprise-beneficial data programs and projects.

Risk Management

Organizations are exposed to business risks in varying degrees. These risks can be categorized as:

• Operational / strategic risk, which includes anything that could impede the organization's performance due to
  • external events (e.g. pandemics, natural catastrophes, climate change)
  • internal events (e.g. labor issues, strike)
  • technology problems (e.g. increasing technical debt)
  • vendor choice / turnover
  • security issues (e.g. CyberSecurity)
• Reputational risk, which summarizes potential harm to the organization's
  • internal perception by its employees and shareholders
  • external perception by customers and the general public
• Compliance risk, which is related to the organization's responsibilities under applicable laws and regulations
• Environmental, Social and Governance (ESG) risk, which pertains to the organization's business ethics and practices (e.g. environmental management, respect for human rights, anti-bribery/-corruption, financial reporting)

Since risks often affect multiple business units or the whole organization, it is important to centralize risk management, i.e. the responsibility for identifying, assessing and mitigating threats that may significantly impact the organization in its ability to conduct its current and future business. Particular attention needs to be paid to cumulative risks, i.e. the organization’s total exposure that amounts from the existence of several parallel, but independent risk factors with the same impact (e.g. several vendors that process personal data on behalf of a certain organization could independently suffer a data breach).

 

Risk management is typically headed by a corporate executive, the Chief Risk Officer (CRO). Small and medium sized organization may not establish a separate position for risk management, but assign the related responsibility to another executive (for the sake of simplicity, hereinafter also called “CRO”). The CRO should ideally report to the CEO or the Board. As most of the risks have a financial impact, the CRO may instead report to the Chief Financial Officer (CFO).

 

Having a horizontal responsibility (such as the CFO, Chief Human Resources Officer (CHRO), or Chief Data Officer (CDO)), the CRO needs to be an excellent communicator and influencer.

 

The CRO’s responsibility includes the following tasks of risk management:

• Document process maps with focus on risk to both information and material, both in transfer and in rest
• Analyze the organization’s risk profile in terms of potential operational, strategic, reputational, compliance and ESG risks
• Identify risk factors that could have the same impact 
• Determine and quantify the organization's risk appetite
• Develop action plans to mitigate risks to the organization – both strategic and tactical
• Seek insurance coverage for remaining risks 
• Integrate risk management priorities into the organization's overall strategy
• Plan and oversee budget for risk management and related projects 
• Monitor the progress of risk mitigation efforts
• Communicate risk analysis and mitigation progress to the organization’s executives, board members and heads of business units

The Importance of Data Literacy

Since EVERY person performing tasks at a (virtual or real) desk for professional reasons works with data, Data Literacy is a basic qualification for EVERYONE with an “office job” and not only required for Data Analysts, Data Engineers, Data Scientists etc. and their managers. (Note: ... as reading and writing are basic qualifications for everyone, not only for those who want to pursue an academical career.)

This been said, I suggest the following definition:

 

Data Literacy is the ability of an individual or a group within their rights and responsibilities in an organization to

• understand the definition and meaning of data
• interpret data in their respective context
• apply data terms correctly and communicate clearly and concisely about data to other individuals or groups inside and outside of the organization
• select, extract, compose, transform, create, and delete data under corporate rules & standards
• judge the quality of data for the potential impact on the purpose of subsequent processes in the organization.

In brief, Data Literacy is “knowing what (data) you are talking about, what you are doing with those data and why”.

 

A Data Literacy program must emphasize educating and sensibilizing particularly rank and file employees in business units who lay the "data groundwork" by collecting data and entering them into the respective systems, often from (unstructured) sources outside the organization such as online forms, letters, emails, messages, phone calls etc.

 

Organizations need to train employees based on 

• a Business Data Glossary related to the subject area Data Model that corresponds to the employee’s respective responsibility
• a subject-area / job-task-related Process Model with its technical and organizational measures showing
  • the potentially available sources of data
  • what to do with those data
  • the potential recipients of data inside and outside the organization

and make those artifacts available for reference.

 

Managing Business-Driven Data Models

In my previous post "Managing Data Models" I emphasized the Logical Enterprise Model as the center piece of model management.

Since the Logical Enterprise Model builds over time, a CDO suggested to me that she would like to integrate a “Corporate Map” into the model management process. This map would be developed in moderated sessions with C-suite members to provide guidance to corporate leaders and stakeholders how business areas are related, which Data Strategy to choose and which projects to prioritize. 

Our conversation brought us quickly to what I introduced as an “Enterprise Information Management Map” in my past posts using an example for the insurance industry:

 

 

Click to enlarge

 

Adding the development of an Enterprise Information Management Map to the model management process for a more business-driven top-down approach:

 

Click to enlarge

 

Managing Data Models

A functioning data modeling environment could look like this:

 

 

Too complex? Not if you consider that most organizations need to maintain legacy systems in parallel to developing new applications – and both in a flexible or even agile manner.

 

Though delimitations between model levels may vary among readers, this image suggests the principle steps and resulting artifacts to proceed from institutional knowledge in  business departments to structures of files and databases.

 

While I may revisit this approach in future discussions and explanations, I will restrict myself here to a few key comments prioritized by recent discussions with clients.

 

1. First and foremost, using a structure like this effectively and efficiently obviously necessitates a professional tool set of well connected components. (Though I am biased* regarding the choice of tools, the approach outlined here should not impose a particular technical solution.)

 

2. In overcoming departmental silos, the Logical Enterprise Model plays a central role connecting business attributes with potentially multiple physical occurrences in different application systems and databases (Data Catalog). As opposed to the (failing) approach of creating a “complete” enterprise data model first, I suggest to build the Logical Enterprise Model by integrating partial Logical Data Models from ongoing business projects. Due to its central role, this integration process and the maintenance of that model needs to be assigned to a central BUSINESS unit, e.g. the Chief Data Office. Since naming and definitions are a mandatory part of business data modeling, a Business Glossary is an implicit component of the Logical Enterprise Model. 

 

3. It is not uncommon that organizations operate production databases which were developed in another (incompatible) project environment 20 or more years ago, i.e. those legacy databases may be insufficiently documented and/or the last knowledgeable programmer / database administrator has meanwhile left the organization. To simply shut down those databases may not on be an option, if they still support valuable business processes, at least not without first migrating the enclosed data to a new storage system. Both maintaining or migrating a database require to know its structure (tables, columns, keys, etc.). Fortunately, professional data modeling tools support “reverse engineering”, i.e. they can recreate the physical data model usually directly from a database.

 

However, the reverse engineering process may leave expectant users with frustration as cryptic, abbreviated physical names in databases are common and do not reveal the semantics necessary to understand and document the purpose of tables and columns. Also, the sheer number of tables can be overwhelming.

 

The best strategy “forward” to identify the relevant submodel (“Physical Business Data Model”) is to find the meaning of core tables (i.e. tables that have multiple relationships) and from the subset of interest to navigate to neighboring objects.

 

The necessary business semantics to enrich the model with logical names and definitions can be obtained

• as part of the reverse engineering process if the developers of the database used in-line documentation features (as e.g. supported by Oracle or SQL Server).
• from database-external sources (e.g. ERP systems often hold the necessary business information in a separate dictionary).

In absence of these tool-supported options, the reverse engineering approach is limited to tap some business users' knowledge to semanticize the reversed model. While this can be a tedious process including trial and error, it is inevitable to do it, if neither shutting down the database nor continuing to operate it as-is are viable options. Legal obligations (e.g. to comply with applicable data privacy laws) may cause additional pressure to follow this inconvenient, but necessary path to reduce technical debt.

 

I welcome your questions and comments.

 

[* In the spirit of full disclosure: I represent Grandite, the supplier of the SILVERRUN Business Architecture Tools]

 

Protecting Consumer & Employee Data In The Cloud

Cybersecurity has quickly emerged from a technical task to a problem that keeps executives up at night.

Why is that? Consumers expect to interact with businesses through a multitude of channels. Organizations do not only need to offer more and more online services, but also want to collect behavioral data about how users navigate, what are their shopping preferences etc. To do so comprehensively, organizations depend on vendors to provide the necessary technology.

Given the usual push for functionality while security is an afterthought, it is only a matter of time until vulnerabilities of such an ecosystem are exposed and exploited. May this be inadvertently caused by employees or vendors, may this be intentionally pursued by bad guys outside.

Remote working has only exacerbated the risk as employees now work in environments that – from a security perspective – are even less under control of the organization. Employees working from home may copy data about consumers or fellow employees to their computer or to their personal cloud (which may not be secured at all) or fall prey to a phishing email that they deem to be authentic and inadvertently disclose their credentials.

This been said, I want to emphasize that Cybersecurity is not a mere technical issue, but requires a culture where the organization, its employees as well as its suppliers collaborate in lock-step and follow the same charter of data protection.

Furthermore, I’d like to point out that whenever we talk security, we need to accept that higher security comes with a price, and perfect security is not possible. So it becomes critical for any organization to define its risk appetite and its level of risk tolerance. Therefore, data protection issues in general and cybersecurity issues in particular can only be tackled in a risk-based approach.

If you like to hear more about this approach, please join the upcoming non-technical webinar “Quantifying And Managing Cloud Risk For Consumer & Employee Data” on December 9, 2020 at 11 am EST. Being one of the panelists, I will take on a compliance perspective for protecting personal information in the Cloud. You are welcome to register here.

A Privacy Regulation Applying in the USA and Canada (and Everywhere)

Although the General Data Protection Regulation (GDPR)* was passed more than three years ago and entered force more than one year ago, there is still confusion and misconception about the regulation’s sphere of impact.

In a new series of posts, I will share some advice** drawn from experience in projects that I have conducted since the inception of the regulation, but also include updated guidelines that the European Data Protection Board (EDPB) recently published*** regarding the regulation’s territorial scope (Art.3 GDPR). To avoid amendments and editorial notes to my original post under this subject, I offer below a complete rewrite.

Although I encourage everyone to read the provisions of the GDPR as well as the above mentioned EDPB guidelines (which illustrate typical cases by example), here are the major takeaways regarding the GDPR's territorial scope:

• GDPR is a regulation to protect personal data of individuals ("data subjects") who are physically present – and may it only be temporarily - in the EEA (European Economic Area – which includes all EU member states plus Iceland, Liechtenstein and Norway). Data subjects’ protection rights are not dependent on their citizenship or residency.
• All organizations worldwide whose activities "intentionally, rather than inadvertently or incidentally, target" individuals being in the EEA are obligated to comply with the GDPR.
• Organizations established in the EEA have additional obligations: They must comply with GDPR regardless of where in the world data subjects are located.

The following matrix shows under which conditions GDPR applies:

However, in a world of international trade and high mobility of individuals, organizations can obviously not control the data subjects’ whereabouts while a business transaction takes place or thereafter. (Even data subjects’ IP addresses captured during electronic communications do not prove presence in or absence from a certain territory since individuals can legitimately – and will increasingly – hide their real geographical location by employing Virtual Private Networks.) Therefore, I recommend that organizations as of row B conduct all their activities related to processing personal data in a GDPR-compliant manner.

From a practical perspective, the above matrix can then be simplified as follows:

In conclusion, any organization offering products or services worldwide must presume, by default, that GDPR applies to them. On the complementary, non-EEA businesses whose commercial target area is outside of the EEA will be exempt from GDPR compliance.

 

* Published at https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1528874672298&uri=CELEX%3A32016R0679
** Legal disclaimer: This blog post is not intended to be legal advice, but to raise awareness that it is recommended to consult a lawyer.
*** Published at https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_3_2018_territorial_scope_after_public_consultation_en.pdf