The Playbook for Informatica Axon Data Governance 6...1. Informatica Enterprise Data Catalog (EDC) 117 The EDC Interface in Axon Has Evolved 118 Manage Catalog Links Interface 119

The Playbook for Informatica Axon Data Governance 6.2

Introduction 7 Who Should Read The Playbook? 7 What’s In this Playbook 8 ...And What’s Not... 8

Chapter 1 - The Data Governance Approach 10 Axon Data Governance 10 The 5 Must-Dos of Data Governance 11 The Value of Governance 13

Chapter 2 - Key Concepts in Axon 14 Introduction 14 Functional Basics: Axon is Organised Into 24 ‘Facets’ 14

Hierarchical Facets 15 Data & Technology Facets 16 Business & Change Facets 21 Organisational Facets 24 Regulatory Facets 28 Segmentation Facets 28 The ‘Ref’ Field 29

Best Practice for the Ref Field 30 Loading Assets - Object Dependencies 30

Functional Basics: Search 31 Fuzzy Search for Keywords in Axon 6.2 31 Quick Search 31 Unison Search 31

Three Unison Search Examples 32 Functional Basics: Connections - Relating Objects Together 33

Relationships & The Glossary 33 Data Sets & Glossary 34 Attributes & Glossary 36

Functional Basics: Informing the Community 38 Unison Search 38 Stakeholders Tab 38

Axon & RACI 39 Workflow 39 Notifications 40

The Axon Data Governance Playbook for Axon 6.2 1/150

My Account 40 Activity Email 41

Functional Basics: Profiles, Stakeholders & Licenced Users 42 Axon Profiles 43 Permissions (WebUsers) 44

Does a new role cost a licence? 44 Monitoring Licence Usage 45

Functional Basics: Dropdown Descriptors 45 Frequently Asked: Changing Axon’s Meta Model (Custom Fields) 46

Best Practice for Custom Fields 47 5 Tests To Validate A Request 47

Context & PII Flags 48 Custom Field Creation 50 Custom Field Maintenance - Editing/Deleting 51 Axon Users & Custom Fields 51

Frequently Asked: Deleting Content 52 The History Tab 52

History - Difference Report 52 When Can/Should Content be Deleted? 53 Bad Reasons to Delete Content 54

Win/Win 55 How to Remove Content from Axon 55

Chapter 3 - Starting Your Governance Journey 57 The 5 Principles of an Axon Implementation 58

Engagement & Adoption above all else 58 Think Big, Start small 59 Be guided by practical usage 59 Breadth over depth 59 Do not model 60

Find Your Way 60 Start In the Right Place 61 Start Small, Make Mistakes, Learn and Improve 61 Starting With Axon: The Informatica Network 63 Starting Out - Typical Activities to Consider 63

...and Common Mistakes 64 Activity 1: Make a Plan - Use Cases 65 Activity 2: Start Collecting Data Before Axon Install 65 Activity 3: Initial Configuration & Customisation 66

3.1 Configuration - General Approach 66 3.2 Stakeholder Framework 66

3.2.2 Role Permissions 68


3.2.3 Everyone Is An Admin? 68 Activity 4: Creating an Enterprise Glossary 69

4.1 Common Misunderstandings of a Glossary 70 4.2 What is a Glossary? 72 4.3 What is an Enterprise Glossary? 73 4.4 Characteristics of an Axon Enterprise Glossary 73 4.5 Characteristics of a good Definition 74 4.6 Creating an Enterprise Glossary 101 - Do’s & Don'ts 74

4.6.1 Let the Glossary Find Its Own Structure 74 4.6.2 What is Glossary Typing? 75 4.6.3 Don’t add technical content to a business glossary 77 4.6.4 Deduplicate - Literal Duplicates 77 4.6.5 Deduplicate - Clarify Conceptual Duplicates 78 4.6.6 Deduplicate - Repetition of Same Concept 79 4.6.7 How to Name Your Concepts 79 4.6.8 Supporting Multilingual Organisations 80

4.7 Glossary Unification 80 4.8 Managing Glossary Definition & Evolution 81

4.8.1 Use of Workflow for Definition Approval 81 4.9 Axon Glossary and Data Models 83

4.9.1 Axon Glossary & Physical Models 83 4.9.2 Axon Glossary & Logical Data Model (LDM) 83

Activity 5: Creating Policy, Process & Project Objects 83 Activity 6: Relating Assets Together 85

6.1 Relationships Are More Meaningful Than Descriptor Fields 85 6.2 How To Create Relationships 86

6.2.1 Standard Relationships 86 6.2.2 Relating Assets to Data Sets & Attributes 87 6.2.4 Relationships vs. Custom Fields 88

Activity 7: Data Quality 89 7.1 Local DQ Rules 89

7.1.1 Dependency on Attribute in same Data Set: Add Item 90 7.1.2 Dependency on Attribute in another Data Set: Measured Against 90

7.2 Standard DQ Rules 91 7.3 Glossary > Data Quality Tab 91

Activity 8: Workflow 92 8.1 Default Workflows vs Custom Workflows 92 8.2 Workflows & Change Requests 93 8.3 Mandatory Workflow Approval 93

Activity 9: Managing Stakeholders & Communications 93 9.1 Introduction and Navigation 93 9.2 Bulk Acceptance of Roles 94


9.3 Supporting New Users 94 9.3.1 Language Support 95 9.3.2 Walkthroughs 95 9.4 Basic Troubleshooting 95

Activity 10: Creating Lineage 96 Interfaces vs. Attribute Lineage (or Dotted Lines vs. Solid Lines) 97 Interfaces vs. Lineage: when to use 97

Chapter 4 - Production Considerations 100 Structuring & Staging Environments 100 Roles & Permissions (again) 101 Admin/SuperAdmin Responsibilities in Production 101

Map Threshold Values 103 Monitoring & Measuring 104 Advanced Features for Maturing Users 104

1. The Data Discovery Tool 105 2. Mandatory Change Request / Approval Workflows 105

Actions to Configure 106 Executing Mandatory Approval 107

3. Rollup 108 Manual Rollup 108 Controlling Rollup - Manual vs Automatic Control 109

4. Scorecards 110 5. Semantic Relationships (Glossary x Glossary) 110 6. Saving and Sharing Searches 111

Managing Saved Searches 111 7. Dashboards 112

Pre-Configured Dashboards 112 Custom Dashboards 113

Dashboard & Widget Creation 114 New Release News 115

Chapter 5 - Making Integrations Work 116 Integrations with Informatica Products 116 1. Informatica Enterprise Data Catalog (EDC) 117

The EDC Interface in Axon Has Evolved 118 Manage Catalog Links Interface 119 Ingesting Content from EDC - Overview 120 A. Manual Onboarding 120 B. Intelligent Glossary Association 123

Axon Glossary > EDC Domain Linking the Axon UI 123 C. Automatic Onboarding 124

Curation 125


2. Informatica Data Quality (IDQ) 125 The Axon View of Measurement & Data Quality 126 The Data Quality Measurement Process 127 Aspects of Axon Data Quality Rules 128

Linking an Axon Local DQ Rule to IDQ 128 DQ Automation 129

What you get: 129 3. Data Security - Secure@Source 129

Data Privacy & Protection 130 Secure@Source/Axon Integration Steps 131 Secure@Source Data Store vs. Axon System Facet 132

Creating The Link - System Facet 132 Secure@Source - The Policy Facet 132

Viewing Security Information (in System/Policy Facets) 133 EDC vs Secure@Source 134

B. Integrations to Other Products via API 135

Chapter 6 - Common Use Cases 136 Use Case: Privacy Regulations e.g. GDPR / CCPA 136

Retention Policies 137 Article 30: Report on Processing Activities 137

Use Case: Regulatory Reporting (e.g. BCBS239, Solvency II) 138 Use Case: Data Acquisition 139 Using Data Sets: Schemas & Physical vs Conceptual Views 140

Example 1: Many Uses For One Large Table 141 Example 2: Representing Different Views Of Data 141 The Axon Answer 142 Example 3: Reports - Combining Physical and Conceptual Data 142

Demonstrating Links to Physical Data: Via Attributes Tab 143 Demonstrating Links to Physical Data: Via Lineage 143

Conceptual Data Sets and Integrations 144 Use Case: Reference Data 144 Use Case: Building Lineage 146

Basic Lineage 146 Attribute X Attribute & Relationships Tab 146 Lineage Maps - Objects vs Unison Maps 146

The Interface Facet 148 The Interface Facet: Showing How Lineage Hops Happen 148 The Interface Facet: Scaffolding 149

Glossary of Terms Used 149


© Copyright Informatica LLC 2018-19 Informatica Axon Data Governance (the software product) and associated documentation are provided only under a separate license agreement containing restrictions on use and disclosure. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica LLC. A current list of Informatica trademarks is available on the web at https://www.informatica.com/trademarks.html. Portions of this software and/or documentation are subject to copyright held by third parties. Required third party notices are included with the product. This software is protected by patents as detailed at https://www.informatica.com/legal/patents.html The information in this documentation is subject to change without notice. If you find any problems in this documentation, please report them to us in writing at Informatica LLC 2100 Seaport Blvd. Redwood City, CA 94063. Informatica products are warranted according to the terms and conditions of the agreements under which they are provided. INFORMATICA LLC PROVIDES THE INFORMATION IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT


https://www.informatica.com/legal/patents.html

Introduction Hello! Thank you for downloading the Playbook. We hope that you find it useful. You’re going to find a lot of information in here - we’d love to have written something shorter and simpler, but the reality is, that with hundreds of customers using Axon, we’ve had to cover a lot of bases. You probably have a lot of questions about your governance program, whether it is setting it up from nothing, or just one aspect of operating it. If we haven’t answered it in here, please let us know (you can provide feedback on the page you started the download). One important thing - the ‘Axon 6.2’ suffix tells you that this version of the playbook includes some comments about some features in the latest release of Axon. However, most of the features described have been in the product far longer, so if you are using an earlier version of Axon, you’ll still get a lot of value from this document. We’ve tried to indicate in which version specific features became available.

Who Should Read The Playbook? This playbook has been written to support the Data Governance (DG) activities of customers supported by Informatica products. The primary focus is on Informatica Axon Data Governance (‘Axon’). Axon is just one part of the wider Informatica solution to support governance, but is often seen as the common element that brings all parts of the organisation together. Unlike other Informatica products, Axon assumes no specialist technical knowledge, or business specialism. The goal is to try and unite everyone’s activity in one place, in a way that makes it understandable to the ‘average’ business user. We will talk a lot about this mythical person throughout the playbook. The playbook seeks to help users:

1. Get started with a DG initiative. 2. Understand how to use Axon for different goals, and offers best practice advice

based on numerous customer engagements. 3. Understand how Axon fits into a wider governance initiative, working with other

products. In particular we will cover: a. Informatica Enterprise Data Catalog (EDC). b. Informatica Data Quality (IDQ). c. Informatica Secure@Source.

Whilst the Playbook is primarily directed towards those directly involved in a Data Governance program, whether you are just starting out, or running a mature program, it can also be used to inform other members of the organisation, who may be only infrequent users of the tool. Readers are of course welcome to follow the playbook end to end if they wish. However, we expect most to dip in and out, to look for information on specific topics. Any methodology or


approach outlined in the document is merely a suggestion, based either on our own original design, or observation of customer usage over the last few years. Alternative approaches may work just as well, and we’d be happy to hear about these. DG is a topic that can and should touch everyone in an organisation (some companies we work with actively promote the idea that everyone is a data steward). As such, consistent with the Axon approach to DG, this guide will seek to describe ideas for conducting your program in a way that allows the average business user to understand the contents.

● The main goal of a DG program should be user adoption, so this is a key test. If people can’t understand the descriptions and content you add to Axon, you’ll lose them before you go anywhere.

Where we need to dip into technical terms we’ll try to make this clear and brief. There is also a Glossary of terms at the end of this document which may give further clarity.

What’s In this Playbook ● Discussion of common key topics and suggested approaches. ● Outline of where and when to use these. ● Real life examples of problems and solutions.

We’ve tried to organise it along the lines of a typical governance program:

1. What is (Modern) Data Governance. 2. Common Questions you’ll get from the community. 3. Starting a Governance Program & POC projects. 4. Moving to steady state governance. 5. Effective use of Automation. 6. Typical Use Cases.

Chapter 2 might look out of place, but we’ve often found that kick-off meetings for new initiatives are more about reassurance and support, so you can’t get far without answering a bunch of philosophical and functional questions - Chapters 1 and 2 should give you what you need to handle those. Chapter 3 is where we start getting things going.

...And What’s Not... ● This isn’t a training manual for Axon features and functions, so we may gloss over

which buttons to press to achieve something we describe. ● We will provide some detail on how to position/use certain features of Axon, but other

resources should be consulted for detailed information, including: ○ The online user guide that ships within Axon. ○ Informatica University provided training courses - consult their website for

more details on available dates and courses. https://www.informatica.com/services-and-training/informatica-university.html


https://www.informatica.com/services-and-training/informatica-university.html

○ Axon Community Pages, part of the The Informatica Network - free to subscribe https://network.informatica.com.

■ Documents and Videos - on products and governance thinking. ■ Knowledge Base articles. ■ Product/Technical release notes.


https://network.informatica.com/community/informatica-network/products/data_quality/informatica_axon_data_governance/overview

https://network.informatica.com/

Chapter 1 - The Data Governance Approach

Axon Data Governance Building on what we said above, our vision of data governance seeks to bring clarity and shared understanding through greater cohesion - we need to unite and clarify activities that often happen every day in complete isolation of each other - your fellow employees don’t know what their colleagues and neighbours are doing, and whether it could be of use to them:

1. The business community, who create requirements for data, and then consume it... 2. ...with those of the technical community that support and deliver that data.

Axon doesn’t have to do this alone, we’ll talk about how other products can come together to deliver this vision. What Axon does do is to bring together multiple strands of activity and allow them to be viewed in one place, showing relationships and context. We do this by creating an easily accessible and searchable enterprise wide inventory of key data elements and activities. Central to this is an enterprise glossary that allows us to relate and contextualise diverse activities that occur in isolation of others (this is really important, so see Chapter 3 for an extended discussion of this). We also encourage assignation of individual responsibility, and an ability to interact with these people to ensure content is kept up to date and relevant. Traditional methods of aligning these viewpoints have often relied on rigid adherence to methodologies and models, that invariably cannot bend to every need. Whilst models have their time and place, as you will see as you read the playbook, we place more value on usability and adoption by a community spread across your organisation. Some people may have a different perception of what ‘Data Governance’ means when you first introduce the topic to them. It will be important to realise and address this when engaging with your community of users - even the meaning and practice of ‘governance’ has evolved over the last 10-15 years, so you can’t even be sure that when you mention the term that everyone understands the same thing. Indeed, some people will say that you are better off not using that term at all, because of the historical connotations... So, your first governance challenge is to assess your understanding and preconceptions of “Data Governance” before you start talking to others. As you read this document be prepared to think differently, and perhaps to allow some flexibility into your approach to DG. Clients who have embraced this idea have found adoption easier to achieve and governance efforts more effective.


The 5 Must-Dos of Data Governance Our view of best practice for Data Governance, as supported by Axon, is derived from five core principles:

1. Break Out Of DG Silos

Classical DG implementations often established a very much top down operating mode of policies, councils, committees and roles. By doing so they create a governance silo. The data challenge in large organisations is a horizontal problem. Think outside the classical vertical of defining policies, standards, roles, definitions silo etc. We need to understand how data is being used in the firm and make data easier for everyone to engage with - not just the chosen stewards. We need to expose how data and organisation hang together, we need to expose the data and governance network.

2. Go Beyond Data Definitions

Everyone can understand a story because it pulls pieces of information together as it progresses. Definitions do not tell a story. The value of data is in its usage. We need to understand usage and context to initiate the dialogue with those business communities. If we want business adoption we need to include the business metadata of requirements, usage, pressures etc. and not just content ourselves with data definitions.

3. Facilitate - Don’t Police

Our ability to police and enforce is minimal. Let's focus our energy on creating the right environment for people to do well around data - let’s make data easier for people, let’s make it easier for people to understand what is already out there, what to reuse and align to. The policing approach doesn’t work. Culturally it’s unpopular - it scares people - it also creates too many rules which take effort to maintain and can never be fully enforced.

4. Embrace The Chaos

There is a lot of diversity which needs to be considered in order to meaningfully engage the organisation at large. At the same time that diversity and the constantly changing organisation carries a lot of energy and opportunity; don’t fight the chaos - leverage the change to realise alignment and ensure adoption of a new way of working.


5. Do Less, Achieve More

No Chief Data Office or Data Stewarding team is ever going to be big enough to keep up with the ever-changing organisation. Successful DG implementations are LESS about the doing or imposing and MORE about empowering, enabling others to succeed… ...whilst being mindful to what is already there and promoting reuse.

Old/Traditional DG was an IT led/owned activity. Modern governance should be driven by the business.

● Axon was designed to the lens by which anyone in an organisation can view and understand different activity around the firm, and what its dependencies and interrelationships are. Axon doesn’t replace any tool you have - it isn’t a tool for cataloging all your data, nor is it for process modelling or DQ measurement etc.

● Axon can represent elements of all such activity, but in a way that is accessible to anyone in the firm. We can only achieve this if the content is understandable to the average employee, wherever they are. That means dropping the jargon, whether it is e.g. technical or legalese, and softening the amount of detail included in these descriptions. Axon shines a light on activity, it does not need to describe it exhaustively.

○ Don’t just recreate information already available - IT e.g. have lots of tools to help them do their jobs effectively already.

● Axon is there to give the business a way of understanding the data that they see, recognise and use, and explain why they need it.

Aspire to create a culture where good practice just happens with minimum conscious effort.

● This new culture cannot exist in committee rooms, because that won’t touch/affect enough people. Our visions of effective governance culture is all about:

○ Engagement & People, not data. ○ Acceptance. Governance has to talk about the reality - what is actually

happening, not some ideal from a planning construct. This reality is far messier than anyone would like it to be, never mind that individual perceptions of a situation are different. Seek to guide people down the right path through principles and outlines rather than rigid rules

○ Mistakes (e.g. in perception / understanding) should be embraced, not criticised. Having the opportunity to publicly address them is invaluable - it provides answers to those that didn’t dare ask, or never thought to. Axon provides a description of how things work, that can be easily updated, with input from the community affected by each change.

● Iteration - share your knowledge and invite feedback, then learn from it.


The Value of Governance Data Governance is a key driver to manage data as a key asset of the organisation. Not only does effective DG create a community of users that might not otherwise communicate effectively, it has more tangible benefits which include resolving key business problems e.g.:

● Understanding and trusting where the data you use came from: ○ Data Validation. ○ Report Validation.

● Defining Key Business Metrics. ● Understand the effects of changes to definitions - who will be affected, where is this

data used, for what? ○ Consult/warn them in advance

● Better cohesion in change projects - understand up/downstream effects. ● Better designed change because the right people are identified and consulted.


Chapter 2 - Key Concepts in Axon

Introduction To help support your understanding of how to use Axon, this chapter is a collection of short discussions of common governance tasks, and how Axon features support them. If you are tasked with explaining Axon and governance to new communities in your organisation, this can be useful information to have in order to assure different stakeholders that you have thought about their needs - even if your initial deliverables do not touch everything we mention here. You’ll also find that we introduce other useful features in Chapters 4 and 5, when your understanding of DG and usage of Axon is maturing. We do not assume that you will need to put everything we described in this chapter into practice straight away. However, if you are completely new to Axon/DG, this whole chapter is a good introduction to Axon and the common questions that are raised at some point on a typical governance journey. The content of this chapter will probably answer some burning questions you have, and will allow us to focus on the core tasks users typically need to undertake in the early stages of implementing governance, which are outlined in Chapter 3, followed by the move into steady-state governance and automation, which are discussed in later chapters. As such, we’ll refer back to parts of this chapter throughout the rest of the playbook.

Functional Basics: Axon is Organised Into 24 ‘Facets’

Facets, sometimes also called Inventories are really just organised lists of different things in use around your organisation. The facet construct was created to help users review content with some form of meaningful structure that separates different types of assets. As you’ll read many times in this document:

● You’ll only want to populate Axon facets with objects that are directly relevant to your DG initiative.

● Your use of facets will expand over time - don’t worry if you only need to use a few facets initially.

Since we have so many different facets, there’s no need to force all your content into the same one. By separating ideas and using Axon relationships to connect them, you’ll create a powerful context and knowledge graph, that scales naturally as you continue to add more content to represent an ever increasing number of Use Cases.


It is essential that new users familiarise themselves with these facets, and ask questions of their implementation partner. We’re often asked what kind of information should be put in each facet when designing the strategy for content load. We’ve provided some guidance below. Many facets will have obvious links to your assets, but try to be open and flexible when considering how to represent content. Axon is about expressing the reality of a situation, not some ideal found in a planning document. As you’ll find out later, we fully appreciate the value that different modelling constructs give to some members of an organisation. However, we’ve yet to find one that facilitated meaningful enterprise wide debate, so we avoid relying on them and the limits they place on expressing how things work. Axon tries to give the business a way of describing what is important to them. The tables that follow seek to indicate both typical and possible uses for each facet.

● Informatica Professional Services, or your chosen implementation partner, can help you assess how to translate your data assets/artefacts (we’ll use these terms interchangeably in this document) into objects listed in Axon facets.

● Note in particular any comments on the use of the facet’s Type field to differentiate assets that share the same Axon facet, even though you might initially think they need their own, separate facet. They are co-located because they share similar characteristics. We’ll try to explain the most common examples, especially why we treat reports and database tables as Axon Data Sets (see Chapter 6 for an extended discussion on using Data Sets).

Hierarchical Facets Many facets below are described as being hierarchical. By allowing description of a parent/child relationship, assets can be subdivided into nested structures that allow logical groupings that help explain business context.

Unison View Note the Parent column, which shows each object’s immediate parent.

Object View Parent/Child relationships create a nested hierarchy, as shown by the indentation.


When creating hierarchies, start small and expand - start at a higher level, and add in more granularity if the need evolves. Plan to keep it as simple as possible.

The tables below describe our view of how to use each facet. These tables are structured in sections to match the Axon user interface. There is a key in each field to denote:

● (H) The facet is hierarchical ● (S) The facet can be used to create a segmented view/apply a specific lens on

collection of multi-facet assets. The ‘segmentation facets’ are described in the section following.

Data & Technology Facets

Glossary (H)

The core Axon facet. Hierarchical. Creating an enterprise glossary is fundamental to governance, and is perhaps the most important activity at the beginning of the DG journey. There is an extended discussion of how to approach the glossary in Chapter 3, and we strongly recommend that all readers review this. An Axon glossary is an enterprise glossary - it seeks to benefit the whole organisation. It should not be used to support one department/area’s view in isolations of others’. Multiple glossaries managed locally in different departments often have to be combined into one using Axon, eliminating all duplicates. An enterprise glossary allows everyone to access and understand key concepts and definitions, and align their own activity (which can often use a different name for the same ‘thing’) to these central definitions. In other words it gives a translation of the local language and terms often used in one part of an organisation, that everyone can understand. As a result of this, each concept should be described only once.

● From a modelling standpoint you may see ‘Customer’ as e.g. both an Entity and a Domain.

● As you’ll see, Axon captures the concept in the glossary facet, and usage is captured through relationships to objects in other facets.

Common misunderstandings:

- An Axon glossary defines ideas/concepts, it should not be used to describe ‘real’ data such as tables (data sets) or fields (attributes). The glossary describes what a thing is/looks like - other facets will capture examples of usage of that ‘thing’ in use. If that thing is a policy, process, table, field etc, we have another facet that can be used to describe it.

- An Axon glossary is not a Data Dictionary. Do not try to use it to inventorise all columns/fields found in all tables in a


database. The glossary will describe concepts that appear as fields in multiple tables - those fields are Axon attributes, and all such attributes are manifestations of the concept. They can be linked to the single Glossary object to show the many uses that concept is put to.

- One common question that arises in early data loads is what type of content to add. Highly technical content, such as join types, boolean fields etc is rarely relevant to the business, and as such is unlikely to be suitable content for an Axon glossary.

System (H)*

We often describe a system as ‘a high level data container’. In other words it may hold multiple, separate collections of data within it. The most common example is a mainframe database that contains many hundreds of tables (some of which may later be represented as Axon Data Sets if relevant to the business). Other potential sources are sharepoints and productivity tools such as spreadsheets, documents etc. This flexibility is needed to manage the multiple types of asset that an organisation might rely on - effective data governance requires us to declare any useful data wherever we find it. We also want to represent what’s actually happening rather than an intended design, which may only have been correct at a point in time. Some of these sources may not be discoverable via technical scanning into a cataloging tool. Some of them might not be approved, authorised sources at all! We still need to describe the reality. Unison System Lineage maps have different icons for some commonly used system types, which make them easier to read. Note that these typings and icons cannot be changed. Axon admins can add new system types, but these will use the same default icon. (H)* Finally, you may notice that the System facet has a field for describing a parent. Clients often view a system as a collection of modules/applications that together provide some value to the organisation. This may be vital information to the functional teams that support the system. However, many of these individual elements are not visible to the business, most typically because they don’t contain data - if they don’t have data the business uses they are of no interest to the business, and are therefore not relevant to Axon. It is sometimes useful to show that there’s more than one data store, if important to the business - however, any close relationships these data stores have will be shown through lineage anyway.

● Note that Axon maps will not use parent/child relationships to co-locate parent/child system objects in a map - the lineage will show objects in a way that best describes the data flow.

Large enterprise software vendors often have bespoke applications/modules for different industries or departmental functions.


Whilst they may use common technology and require a common team of experts to maintain that technology, the usage of each module is what’s interesting to governance. As such each module should be described in isolation, so that the uses, lineage, policies and processes etc controlling this can be easily seen. Giving all modules a common parent is possible, but has limited value.

Data Set Any identifiable collection of data. ● The most typical example represented is single named table,

found in a database*. ● However, an Axon Data Set can be any collection of data

points - it doesn’t have to be tied to some logical/physical modelling construct.

○ If you use a collection of data points, wherever and whatever it is, record it in Axon.

*Note that Axon should not be used to exhaustively catalogue every available table - only add those that are relevant to the organisations’ governance aims. If you are describing a physical table, only add the Fields (as Axon Attributes) that are relevant to the business - assume that Fields are not relevant until it is agreed otherwise.

When using data sets you will need to describe many different reasons a Data Set exist - just like with systems (and other facets), we do this using the Type field. Typical Types you will need are supplied out of the box in the default configuration that ship with Axon:

1. Data Set: Any database table / spreadsheet / collection of data points/attributes

2. Report: reports, e.g. regulatory reports are named collections of data with a prescribed list of data points (attributes). These are held in the Data Set facet to allow exploration of the lineage that ultimately supplies the data through transformations, calculations, filters etc.

○ Remember that Axon only records the metadata - it doesn’t matter that a source table might have millions of rows, which is ultimately linked to a report with only one row of data.

○ The sources, calculations and Data Quality are what we’re trying to understand.

3. Value List: Demonstrates reference data management, and where some attributes/columns depend on this (rather than a full enterprise reference data capability, such as the Informatica Reference 360 tool).

When creating an Axon Data Set, users are asked to associate it to one glossary object. That glossary object should be that which most closely describes the business purpose the Data Set supports.


● We are often asked to extend this model to allow relationships to multiple glossary objects. This is not the purpose of this glossary association

● Capturing the multiple subject matter of a data set can be achieved by relating the individual attributes to appropriate glossary objects. Any Unison Search on the Data Set will then return all these glossary relationships.

● We’ve seen some clients relate all data sets to a glossary term of ‘Data Set’. If you are tempted to do this, please speak to Informatica Professional Services or your implementation partner for advice.

See Chapter 6 for some examples of common questions and challenges using the Data Set facet.

Attributes Individual data points found within an Axon Data Sets. These might represent Fields/Columns found within physical data sources such as database tables. Equally, they could just as easily be data points in a report used by management, or sent to a regulator (after all, at a meta data level, there isn’t much difference between a table with millions of rows and a report that has one data point per field). We encourage users to ensure as many attributes as possible are associated to Glossary objects. This allows the ‘local’ names used every day to be captured, whilst the link to the official glossary concept clarifies the purpose of the attribute for the wider community. The picture below shows a collection of attributes with such diverse naming, that are all aligned to the same glossary term (note that Unison search is limited to 1 of 620 glossary objects, and all attributes have the same Glossary value (last column)).

In the preceding description of Data Sets, above, we said that you should only record those assets that are directly relevant to the governance needs of the organisation. The same is true with Attributes. If the Data Set you wish to record happens to be a table with dozens/hundreds of columns, not all of these should be added to


Axon - we typically find that limited numbers of these have direct relevance to business users. Axon attributes are the core of describing lineage. We may find that an attribute we use in one Data Set is created elsewhere and moves around systems and data sets before it arrives in a Data Set of interest to the governance community. It is often crucial to understand the provenance of this lineage.

● Lineage appears on maps as SOLID lines ● How to create lineage is discussed later in this document

Interface Interfaces describe transfers of information between systems - they help understand how data is transferred across an organisation. Some organisations support specific data flows, such as regulatory reporting, with specific packages of data transferred on a regular basis. This means that there can be multiple interfaces between the same two systems.

● Interfaces are not just for such IT supported regular transfers. ○ They can describe manual/partially automated

transfers, such as email. ● They are one directional. Where system exchange information

in both directions, a second interface object is required. ● Can be associated to data lineage to show how lineage is

supported, as shown in Chapter 6. Notes on Interface:

● An interface is often a concept not immediately understood by business users when first using Axon, so don’t worry if this does not immediately strike you as something worth recording. If they become relevant later they are easily added.

● Conversely, other clients have started using Interfaces to map out systems within the scope of an initial rollout. By connecting them together they give the user group something tangible to work towards. We call this scaffolding.

● Interfaces create DOTTED lines between systems in lineage maps.

○ The interface’s arrowhead shows the direction of flow. ○ The scope of when an interface is displayed on a map

is different to more detailed lineage.

Data Quality The DQ facet captures rules that measure some aspect of a particular attribute in a given data set. Axon expresses DQ information at two levels:

1. Standard Rules - generic rules, described at the glossary (conceptual) level.

2. Local DQ Rules - actual measurement of specific attributes in a specific Data Set.

The Informatica Data Quality (IDQ) tool records the desire to measure quality at two levels (it also performs other functions, such as profiling,


which are not relevant to Axon). 1. The general rule that describes measurement objectives -

broadly similar to Standard DQ Rules. 2. Specific mappings, i.e. the application of one such

measurement against one specific attribute in one table/Data Set - these are Axon Local DQ Rules.

Other aspects of DQ, and automation, are described in Chapter 4.

Business & Change Facets

Committee (H)

This hierarchical facet seeks to list and describe activities conducted by bodies, groups (and, yes, committees...) that bring together people from multiple disciplines, functions and departments to support/conduct/approve specific activity. A commonly found example of this is a Data Definitions Council (exact name varies) that meets regularly to review and approve new/amended definitions. For now, the primary function is to declare and describe the different bodies that exist, so that their purpose can be understood.

● We have observed that many clients prefer to record only one or two officers from each committee, to give a contact point for interested parties.

○ Whilst the Committee facet does offer the ability to list all members of the body, this is optional - it can create low-value workload in maintaining the list of members.

○ If required, the description field can hold a URL link if the membership list is maintained elsewhere.

Policy (H)

A policy is a documented set of principles/standards that set the direction for a given business purpose/requirement, or any restrictions placed upon their use. They are created internally - they are often created to describe the response to an external regulation. Equally, they may also relate to contractual limitations placed upon the organisation, or other internal initiatives such as ethical data policies. Axon is not a policy management repository, but describing policies, and more crucially relating them to other Axon objects gives valuable context - visibility of what the policies affect, or their dependence on other assets. The facet is hierarchical - this is often used to break down one headline policy into multiple parts (business rules) which can be more


accurately related to other Axon objects to give clear context and applicability. Policy and Process are often used together:

● Policy: What the rules are ● Process: Steps followed to complete a given activity, related to

the policy rules that control such activity.

Process (H)

Process is a documented set of repeatable steps to achieve a desired outcome. We have observed that client processes are documented in a wide variety of ways, either in process management tools or in various diagrammatic forms. As useful as these are to the people that know about and have access to them, exposing them to the community in Axon makes them more accessible. More importantly, relating them to other activities/objects helps everyone understand the context of why the processes exist, where they are applicable, and what resources they depend on when executed. The facet is hierarchical - this is often used to break down one headline process into multiple parts (individual steps) which can be more accurately related to other Axon objects to give clear context and applicability. The process map below shows the flow of steps within a Process, overlaid with the systems used at each step (all these steps have the same parent object).

Policy and Process are often used together to show what control/restrictions are placed upon your assets (Policy), with Process used to evidence actual use/demonstrate adherence to policy.

Project (H)

A project is any combination of people and resources that is initiated to achieve a particular aim. They are typically not regarded as Business


as Usual activity, and often their aim is to effect large change initiatives in the organisation.The facet is hierarchical. Projects are often described in Axon in order to relate them to all the objects that are likely to be affected by the project, so a proper assessment of the scope, dependencies and community of stakeholders can be made. This allows for greater transparency and reduces the likelihood of missing key elements, thus avoiding unintended consequences of implementing change.

Change Requests

A Change Request (CR) is a way in which the wider community can interact with the people that actively curate Axon objects day to day. They can ask questions, suggest new/corrected information to help more people understand assets and the applicability. The facet lists all Change Request objects that have been raised against objects in any facet across Axon. A CR can be raised by any logged-in Axon user who wishes to contribute to, or get guidance from the collective knowledge of the community. Change Requests are created by visiting an object in any facet and initiating the request via the Actions button (which may be labelled Edit for certain users). Each object is permanently connected to the object against which it was raised, and serves as a record of a particular activity - examples of this are recording approval for a definition, assessing requests to make changes. Whether such a request is approved or not, users can review the content, and learn from it. Once created, each new CR is notified to the objects’ stakeholders. Each object may have a variety of available workflows, and the stakeholders will choose which is appropriate of the request.

Role The role facet is not a typical facet. You cannot create roles here, as you would in other facets. Instead, this facet lists/summarises all stakeholder roles that have been assigned to objects all across Axon. By showing the details of the object, role, individual responsible etc. in Unison it facilitates a number of powerful searches that help you report on and control your DG program. One useful feature that is often missed: The bulk update option (available only to Admin users) in Unison, allows easy transfer of responsibilities from one person to another when stakeholders leave/change roles.


Organisational Facets

Business Area (H) (S)

The Business Area facet allows users to create a list of usable functional delineations that may mean more to the business that the rigid HR view expressed in the Org Unit facet. OrgUnit names tend to be very granular and can often be too specific for general use. Sometimes you just need to know that Marketing, Operations or Sales are relevant to an object in some way, rather than an HR-derived Org Unit such as Technical Sales - Western Europe. The Business Area facet can help show general functional dependencies on key assets, and can use different relationship types to declare the reason for the association.

● This is different to declaring object stakeholders, which must be individuals found in the People facet.

For example, we may find that a number of departments (Finance, Marketing, Sales) all feel that they should have some say on assets that they rely upon, such as a glossary definition. We don’t allow teams/departments to be an object stakeholder, but we can show that all three departments have a strong interest in the asset by creating Business Area x Glossary relationships. The facet is hierarchical. This facet is similar in purpose to the Product and Client facets, users should ensure structures do not overlap.

Capability (H) (S)

A Capability is an organisational ability, feature, function or skill. The organisation makes the capability tangible by leveraging People, Processes and Technology. In other words capabilities typically link to the other resources and assets that make up and support that capability. The capability facet is hierarchical. In terms of business viewpoints, the capability facet provides a macro view/lens for more senior stakeholders to engage with the governance of data and the business assets they support. In recent years regulators have started to prefer to express regulatory requirements in terms of principles and organisational capabilities. As a result the capability facet has been commonly used as part of those use cases. Examples of capabilities are the organisation’s capability to submit a given regulatory submission, ability to onboard clients, ability to capture or settle trades, ability to fulfill orders etc. A common use case for this facet is regulatory reporting, often called Business Outcomes by Financial Services firms. These are collections of regulatory reports (Data Sets), and the Processes that deliver them.


They can be brought together, so that a Unison Search can easily find them.

● Use of the Capability facet for Business Outcomes is so common we are often asked to change the name of the facet.

● As discussed above, we see other uses for the facet, and would therefore recommend an alternative approach:

○ Use the Capability Type field to make this differentiation ○ Configured a Type = Business Outcome in the Admin

Panel.

Client (H) (S)

The Client facet allows users to create a particular cut of Axon data that can be useful for some users. In other words, this is an additional set of classifications that might inform high level business cases. If you need the ability to answer a question like ‘what kind of business activity would need to be aware of this asset’, the Client facet may be appropriate to give context and facilitate easy Unison Search. Some example client types:

● Financial Services: Corporate Client / Personal Client / Mortgage Client

● Healthcare: Animal Health / Human Health Contents can be similar to other segmentation facets, e.g. Product and Business Area, so ensure their structures do not overlap. This facet is hierarchical.

Legal Entity (H) (S)

The Legal Entity facet allows you describe the internal structure of an organisation, e.g. different companies/corporate bodies within a group, or 3rd party companies that perform day to day activities on your behalf (such as data processors in GDPR). Using the Legal Entity facet to make relationships to assets allows you a lens to break down these assets between these different parts of the organisation. It’s quite common to find that a group owns a collection of companies that can work together day to day almost seamlessly. This makes it hard to know e.g. which of these legal entities owns hardware, software etc that is accessed by the wider group. Activities such as regulation, acquisitions and disposals may require this view to be understood.


The facet is hierarchical. It should not be confused with the Geography facet, which allows a view based on political classifications such as country/region. Many facets can make links to this facet. Where this view is likely to be important to you, you should require this relationship to be created as part of your operating model. Note that Legal Entities can be related to specific objects in the separate Geography facet.

Org Unit (H)

The Organisational Unit facet records the HR (Human Resources) view of a company - Axon user John Adams works in North America - Alliance Marketing:

● It is a mandatory association when creating Axon users in the People facet.

It is needed to add context to all employees/Axon users, and may also be needed as part of enabling Single Sign On to Axon. The HR view can often be more rigid/detailed that is required for some activities. We gave the example above of John Adams working in North America - Alliance Marketing. Sometimes we just need to know that something is relevant to Marketing. The Business Area facet, described above, can be used to make more generic, business friendly constructs and associations to objects. The facet is hierarchical, which can allow a Group > Division > Country > Department structure. However, many clients don’t require this view in Axon, and are happy to load a flat Org Unit structure. Especially when running a PoC/performing initial data loads into Axon, we’ve observed that clients often enter placeholders rather than real, HR sourced values.


People The People facet lists all members of your organisation that have been granted user access to Axon. If you have a user account you can log into Axon

● If not you may still be able to view the content, unless general access is controlled by your systems team.

● If you can view Axon without logging in, you won’t be able to contribute to workflows, take stakeholder roles etc.

Although you may use Axon’s Bulk Upload to add users in the early stages of an Axon deployment, most clients choose to enable Single Sign On to make management of users easier going forward. Creation of a new People object requires that a user Profile is selected (WebUser/Admin/SuperAdmin). Almost all users will be a WebUser. See the section below on Profiles for more information on how this affects a user’s ability to interact with Axon. The People facet does not currently support creation and management of groups to facilitate asset ownership to a group of users, although this is on our roadmap.

Product (H) (S)

Another facet (like Legal Entity, Geography, Client, Business Area) that allows a lens to be placed on your assets. In this case the facet allows you to record and describe from a product perspective. Note that Axon is not a stock management system, so the classes of product that we recommend are higher level concepts such as:

● Banking: Mortgages, Saving Products ● Retailer: Domestic Electronics, White Goods, Garden, Home ● Insurance: Life, Non-Life

Many facets can make links to this facet. Where this view is likely to be important to you, you should require this relationship to be created as part of your operating model. This facet is similar in purpose to the Client and Business Area facets, ensure structures do not overlap.


Regulatory Facets

Regulation (H)

Primarily designed to capture and describe external regulations. These can then be related to the organisation's internal response, as detailed in the Policy facet. This is a hierarchical facet, that allows users to choose the level of detail captured. For example the recent GDPR regulation could be captured at a high level, using one object, or with any/all of the 99 separate articles of the regulation captured as child objects.

Geography (H) (S)

As the name suggests, this (hierarchical) facet allows users to add a lens based on country/regional relevance of an asset. It can be used e.g. to show which countries/regions a regulation is applicable to. Often used in tandem with the Legal Entity facet, which shows the corporate identity rather than the geographic location. Note: This facet was formerly known as the Jurisdiction facet in earlier versions of Axon. It has been renamed to reflect the evolving uses for this lens.

Regulatory Theme (H) (S)

Similar in purpose to the Client, Business Area and Product facets, this allows easy classification of objects in the Regulation facet (only), e.g. multiple Privacy regulations can be classified for easy search.

Regulator Only applicable to the Regulation facet, it allows users to describe bodies publishing and enforcing regulations.

Segmentation Facets As you read through the list of facets, above, you will have seen that some have been marked with an (S). This is to indicate that these facets may be useful in summarising collections of assets held in multiple facets for different scenarios. This has come to be known by some clients as ‘segmenting’, so we’ll use that term here. These segmentation facets are summarised below with some illustrative applications. Some of these facets do not have an obvious owner within the business, and if often falls to the central governance team to create and maintain these. Where this happens it should be noted that those facets typically have no more than a few dozen objects, so this maintenance should not be onerous. We’ve observed some clients try to use some of these facets to create detailed lists (Client: List of Suppliers /Counterparties, Product: Individual


Retail Goods), but they soon find that isn’t a good use case - you’ll want to use higher level classifications in these facets. The capability facet can have many more objects, but the owners for such objects are easy to identify, and maintenance of this facet is typically federated. The central team then just need to make sure that the Capability > Typing allows sufficient flexibility to describe different activities (such as Business Outcome, as discussed above).

Facet Possible Uses

Capability Isolating all assets used in a regulatory response Demonstrating how key activities are achieved through a collection of assets

Legal Entity Privacy: 3rd party data processors Group Subsidiary companies : showing ownership of assets/ licences by different companies in the group.

Business Area Giving a simple view of where certain departments have relevance to objects.

Product Creating relationships with objects that are relevant to: Lending Products, Savings Products.

Client Differentiate where assets are relevant to different communities e.g. personal vs corporate banking, human vs animal health.

Regulatory Theme Classifying different regulations under common headings, e.g. GDPR, CCPA and PDPA are all privacy regulations.

Geography Can be used to show where regulations are only applicable to certain territories that the company operates in.

The ‘Ref’ Field Many facets in Axon have a field that is named Ref or Reference (which we’ll be standardising as ‘Ref.’ in a future release). We’re frequently asked what this should be used for. Axon represents assets which are maintained/recorded in many different ways in multiple sources in your data/business landscape. Some of these sources will have their own identifiers for those assets. Whilst these might not be known/visible to everyone in your community, they can be important to those that work with them. As such, whilst we cannot rely on them as Axon object names, they’re often important to capture, if and when they exist. We capture them in a specific field to facilitate search. As not every source has such identifiers, the capture of Ref values is not mandatory in Axon object creation. However, Axon always ensures that the field is populated by generating a value if users don’t add one themselves.


● A common example of where such Ref values are popular/important is Process modelling tools (and Visio diagrams), although there are other examples relevant to other facets.

● If no such identifier exists you do not need to populate the field. Be aware however that Axon will auto-populate the field if the user leaves it blank.

○ Axon uses a standard alpha-numeric construct for the Ref: FACET-NUMBER, such as SYS-1, PRC-24 etc etc.

○ The facet abbreviation element is configurable (in the Admin panel).

Best Practice for the Ref Field ● If you don’t have an obvious source for the field - leave it blank.

○ Some customers feel the need to populate it for the sake of it, although they find it challenging to generate values - that’s why we offer auto-population.

● Keep the Ref short; grid layouts assume it will be short, so will not render long names well.

○ Do not replicate the object name; it is too long and confuses users. ● We’ve seen some clients create Ref constructs that infer/describe usage. Typically

however, this has been because users haven’t appreciated how use of other facets can be used (esp. segmentation facets) to represent this information in a way that’s easier to scale, search and reuse.

Loading Assets - Object Dependencies When creating a plan for loading assets, be aware that there may be dependencies that you need to allow for when planning the order in which you upload files. In order to create a relationship between two objects, both must first exist in Axon. As the creation of some Axon assets have a mandatory dependency on other objects (see the Axon User Guide for specifics), some collections of objects must be created in a set order. These are shown as dark green objects in the picture below. Those that are coloured grey have no dependencies at object creation (other than People, for stakeholders).


Functional Basics: Search As you add new use cases to Axon, and build your content you’ll soon start to find that some of the assets that are part of the new story have already been added to Axon. This builds up a picture of dependencies that might be seen for the first time. Equally, it means that you’ll often need to isolate different stories using Axon’s Search features. Axon has 2 types of search - Quick Search and Unison Search. Before we introduce them, an important feature to be aware of - ‘Fuzzy search’.

Fuzzy Search for Keywords in Axon 6.2 Axon 6.2 has introduced expanded capabilities for keyword searches in both Quick Search and Unison Search, with the introduction of Fuzzy search. Previous versions have used literal search, e.g. if you enter a keyword search of ‘Name’ it looks for exactly that string. Fuzzy search helps users:

● Find things that might have been misspelled. ● Find results that are ordered differently from the search term, e.g. where the search

is for ‘Legal Record Entity’, but the desired object is ‘Legal Entity Record’. Fuzzy search is an option that is disabled by default. Note that:

1. Use of Fuzzy search can be controlled in Admin Panel > Application Settings. 2. If enabled, exact searches can still be made, by wrapping the search term in quotes,

e.g. “CMD-ID”.

Quick Search Located in the toolbar, quick search looks across all content (unlike Unison Search which searches one facet at a time). Results are returned across multiple facets. The dropdown menu (cog) allows you to choose the order that facet results are returned.

Unison Search Unison Search is a more powerful way to search. Whilst Unison Search will only search one facet at a time, you can build up conditions across multiple facets to get the view you want.

● An active Unison Search controls what will appear on the Insight Maps, initiated in the Unison Toolbar, at the top of the screen.


● Unison Searches can be saved for easy regular searches. ○ Saved Searches can be shared with other users and form the basis for

custom dashboards. How to save searches is explained later in this document.

○ Note the Clear button in the picture - this only appears when there is an active search that can be cancelled - when no search is active, this button offers you the chance to see a list of your saved searches.

Three Unison Search Examples 1. Filters can be added to searches to isolate different aspects - the search shown

below identifies Data Sets of Type = Report. ○ The default view for unison grids is the List view, so that you can see all

objects returned by the search - also note that each facet has a dashboard view - these dashboards update dynamically according to search results.

2. In Hierarchical facets there is a ‘Children’ Filter that can be used in combination with a keyword search to return different levels of hierarchy below the searched term. 3. Common searches, such as ensuring that the number of objects without stakeholders require conditions added to the search, as shown below, in a search for glossary objects without any stakeholders.

The next section describes how and why we connect objects together. From a search perspective the value of that activity is that when we search for things that interest us, we see not just what we expect to see, but the related activities that we might not have any knowledge of - this is the value of Axon - providing a way of understanding common dependencies and interrelationships, that give us a fuller understanding of the data landscape and the business activities that generate and consume this.


● One important thing to note is that we may start our searches in different places (facets), whether we are e.g. system or process experts. However, we’ll still be able to see relevant connection returned. That’s why, when you search in one facet, the counters on every facet change to tell you how many objects in each facet are connected to the things you searched on.

Functional Basics: Connections - Relating Objects Together Once you have listed a collection of assets over a few facets, you’ll want to explain their relevance / dependency upon each other:

● There are many reasons to connect two objects together.

● These reasons can be configured as relationship types (in Admin panel).

● These relationships give context to the objects involved and form part of their description. We demonstrate why when we return to relationships in Chapter 3.

These different relationship types can be viewed in the individual objects, such as the example here, that shows that a System can have multiple reasons for relationships to Legal Entity - one part of the group hosts the system, another is responsible for support, whilst a third actually owns the software licence.

Relationships & The Glossary At the core of this activity is the Glossary facet. This should capture a set of definitions at the Enterprise level, not simply restate a collection of local dictionaries (see later section on glossary, for a discussion of how to approach this). When you have a set of widely understood, widely accessible definitions, most content loaded into Axon can be linked to these. This allows anyone to search for a concept and see all activities related to this concept, wherever it occurs in the organisation. Axon’s Unison search allows you to choose single or multiple objects to get the view you need. Your assets will be used for a multitude of reasons and activities, be it e.g. day to day reporting, or ad-hoc activities. Not all of this is visible, and it’s very rare for everyone to be fully aware of others’ dependencies.

● That’s why change often has unintended consequences - a common complaint is that ‘we didn’t know you used that’, or ‘it was designed with this user/use case in mind, not you’

● ...sometimes followed by ‘you shouldn’t be using that, you should be getting it there’


● ...or worse still ‘we made a bunch of changes to that data, it probably doesn’t do what you think it does any more!’

DG should be a statement of what’s actually happening in the business, something we often refer to as the ‘messy reality’, whether you like that reality or not. It should not be a bland restatement of what existing documents/models say should be happening (after all, you probably already have a collection of documents that tell you that...). You’ll only get a true view of this by approaching the task of capturing this in an open manner, so that the community isn’t scared to tell you how things really happen (better you find out now before something unexpected goes wrong, or worse, e.g. a regulator asks...). The first step in addressing a problem is to admit that one exists. Whether things work the way that they should/you want them to, you can’t hope to change things until you are informed. If you go looking for a fight, everyone will be naturally defensive and reluctant to share. There will be many reasons (good and bad) why your reality has evolved the way it has - just accept that this is what you have to work with. Multiple relationships can be made between Axon objects, which gives the entire community visibility of how dependent the entire business might be on the same collection of assets:

● They often show users why the ‘simple’ change that they have requested is not as simple as they think.

● It allows impact assessments to be made to ensure business continuity when changes are implemented.

● It allows all dependent users to be identified and consulted (or at the very least forewarned).

Data Sets & Glossary An Axon Data Set is a very flexible object. As discussed in the facet overview (above), it can represent any of the following:

● A database table (called ‘physical’ data by some communities) ● A spreadsheet ● A single worksheet within a spreadsheet ● A report - internal or regulatory

As we’ll demonstrate, we believe that each of these do the same kind of thing, so we capture them in the same facet. Remember that Axon doesn’t care about how many rows of data there are, just that the data is used. So the differences between a database table (millions of rows) and a report (as little as one row of output) don’t affect this view. To capture the different forms a Data Set might take, we use the Type field, which also makes search easy later. This will be invaluable later when you start to record lineage, as you’ll find that all such types of asset are often found at different stages of the same lineage story. Some other things to know about data sets:


● When we get to the stage of recording db table contents, you’ll rarely need to ingest and describe everything - you only need what’s relevant to current governance aims:

○ Database tables tend to have 100s of columns, DG initiatives should not need to use/describe all these - you should be interested in the most important elements only - why complicate Axon with content that no one in the business knows or cares about?

■ A cataloging tool such as EDC can inform and hold other assets until such time as there is a clear need to bring them under closer governance.

● When creating a new Data Set, Axon requires that you align it with one glossary object

○ See the section above on general reasons for relating activity to the glossary ○ Unlike most facets, this glossary connection is mandatory. Data Set names

tend to vary enormously with the business area for which it was created, or, equally common, database tables often have technical names (e.g. T9812B), which gives users no clue as to the business purpose.

○ The link to the glossary makes that contextual connection which allows other users to understand the object. Think of the Data Set x Glossary relationship as using the glossary terms that best describes the primary purpose for which the Data Set was created.

■ We’re often asked to allow multiple glossary connections to a data set because it contains data from many subject areas - that’s not the purpose of this relationship.

■ If you need to describe this level of granularity, you can - at the attribute level. Attributes can be related to the Glossary concept they represent - see the next section on Attribute to Glossary relationships.

■ We’re also often told that the single attribute represented in a Data Set is very rich in meaning, because one attribute is seen as a combination of many concepts. Here, we need to separate the conceptual understanding of the component parts, from the attribute.

● Describe the attribute as it exists in the Data Set, and associate it with a glossary object that defines that end state.

● The fact that this end state is a combination of other concepts can be captured with horizontal relationships between glossary objects (glossary x glossary upload template) that are shown in the Glossary > Relationships tab, as per picture below.


Attributes & Glossary Similar to the discussion about data sets above, the naming conventions used for attributes are so diverse that the attribute name frequently can’t identify the asset, as the screenshot below illustrates. These all represent the same thing used by different parts of the business. None of these would recognise the other names you see, so if we want to talk to one group about their data, we need to use the name they recognise. Equally, the wider community needs to have these local names related to something they would recognise - that’s what the link to the glossary achieves.

Most of the attributes shown have already been linked to the glossary (as shown by the last column). Where this hasn’t happened, users can’t make the disambiguation easily/at all. If we now change the search shown from the glossary term to look for attributes with ‘CMD’ in their name we find one attribute (last row) hasn’t been related to what appears to be the obvious glossary term.


Whilst the name of the asset in this case might suggest that it’s probably another example of the CMD-ID glossary concept in use, we really need to be sure. The link to the glossary would not only confirm that, but the connection means it would be found when the CMD-ID glossary term form part of a Unison Search. Equally, if it turns out that this attribute is actually an example of another concept in use, it would be highly desirable to make this distinction with a link to that term, as the risk of someone making a bad assumption here is understandably quite high. Finally, and perhaps even more importantly, one of the key strengths of Axon is to make the link from the glossary to policies that might control the use of a definition - if a definition is subject to a privacy regulation we need to ensure a robust set of relationships to ensure that everyone using the data is aware of the rules they have to abide by:

1. Policy to Glossary 2. Glossary to Attribute

Many organisations use the count of attributes that are/not aligned to the glossary as one of the measurements of a successful DG program. The search is easy, is shown below, and can be saved to re-run periodically.

It’s unrealistic to expect all attributes to be connected to the glossary, but it’s a good goal to monitor and improve over time. It is common to find attributes that could/should have been connected when they were first loaded, and there are ways to update existing content, such as (in no particular order of preference):

● Workflow - raise a change request against the Data Set containing the attribute ● Bulk Upload - Update mode. ● Glossary - Data Discovery tool.

○ Set patterns and rules to find attributes that ought to be aligned with that glossary term.


● As you’ll see in Chapter 5, automation of such discovery is an increasing part of Axon, via the connection to Informatica Enterprise Data Catalog (EDC).

Functional Basics: Informing the Community As soon as you start connecting objects together, things will start changing. The initial reasons for connecting objects may not change, but you will probably need to review what impact the changes will have on connected objects:

● A policy associated to 8 glossary objects has been revised - how many of these objects are affected by this revision? Should we add more/remove any of the 8? Who do we need to talk to about this?

● A legacy system is being decommissioned by IT, and a replacement system is being planned - who will be affected by this? What processes, policies and projects depend on this system for data? Who do we need to consult?

● The sale of a subsidiary is being considered - which assets do they depend on, who owns them? Will both businesses be able to operate smoothly after separation?

The key theme here is that communities need to be informed to manage effective change. Axon supports sharing information/change consultation through a variety of constructs found all across Axon:

Unison Search A Unison Search can identify objects that have been associated with other objects. Such searches can also be configured to find things that have not been associated.

● Any user that saves a search can share it with other Axon users. ○ If email is configured the recipient will be told by email ○ Any user can find searches shared with them when logged in. Find these by

following Unison > My Searches > Manage Searches > Searches Shared With Me.

Stakeholders Tab All objects have a Stakeholders tab, to represent the people you entrust to curate that object and handle questions from the community of Axon users. It also shows the community of users who are stakeholders on objects that have been related to this object (the Stakeholder Community) - this identifies people who could be affected by changes - their input, or at the very least, advanced warning of planned changes, could be vital for making a more informed change.


Axon & RACI Whilst we’re here it is worth mentioning that we are often asked how Axon supports the RACI construct (Responsible, Accountable, Consulted, Informed). If this is important to you, then ‘R’ and ‘A’ are arguably taken care of using Direct Stakeholders. However, when it comes to ‘C’ and ‘I’, we diverge slightly - we see RACI as a static planning document, that is difficult to maintain. Axon therefore offers something more dynamic and informative. We see ‘C’ and ‘I’ as moving goals - the community that is dependent upon any given asset changes constantly, as business needs change, or new/unexpected users of the asset emerge, via the relationships created in Axon. We therefore view the extended network shown in Stakeholder Community grid as candidates for consultation/ to be informed of any changes.

Workflow Axon has a built in BPMN 2.0 workflow component, which facilitates the creation and execution of workflows to manage approvals, questions and suggestions from the community, as well as bringing together appropriate experts from around the business. The core of workflow is to channel activities between object stakeholders, although once a workflow is running, those stakeholders can bring any Axon user into the discussion. Multiple workflows can be created at both the facet and individual object levels to channel different types of request through different paths. Workflows are initiated by the object stakeholders as they respond to Change Requests (CR). Any logged-in Axon user can raise a CR, which is permanently linked to the objects they are raised against, and thus discoverable via Unison Search. The CR captures all activity, including documents, comments captured during the execution of the workflow. This provides evidence of the issues and decisions made. Axon 6.1 has introduced the ability to mandate automatic initiation of CR/workflow to force validation of changes made to an object. This feature is explained later.


Notifications Notifications: In the Unison toolbar you’ll see a bell icon with a count of messages you have received. These relate to stakeholder roles you’ve been assigned and any workflow actions. Be aware that although only stakeholders can explicitly be part of pre-configured workflows, any user can be asked to contribute to an active workflow (via the workflow Discussion feature), so anyone can get workflow messages. Such notifications can be pushed to users - see Activity Email, below.

My Account The toolbar > My Account link (click your user name to access) is a shortcut to your own People page (if you are logged in). Other users can access this from Unison. This shows:

○ Responsibilities: A list of the objects on which you have a stakeholder role ○ Following Tab: A list of the objects that you do not have a formal role on, but

want to be kept up to date on any changes (see Activity Stream & Workflow). ○ Activity Stream Tab: This has two sections of interest:

i. Notifications: If you instance is configured for email users can select to be notified of events concerning them daily/weekly/monthly. Contents of the email are described below.

ii. Activity Stream: This contains the details of any changes you objects that you either have a stakeholder role on or follow. These changes enter your activity stream after an object edit has been made.


Activity Email In the section above on My Account we showed you that email updates can be sent to any user (but only if email has been configured for your instance AND the user has elected to receive emails).

● The contents of this email summarise themes discussed in the points above: ○ Stakeholder roles awaiting acceptance. ○ Any workflow notifications. ○ The contents of your Activity Stream for the period identified by your

notification frequency (i.e. if you have a weekly frequency, you’ll be told about object changes in the last week only).

● Axon 6.1 introduced additional functionality for workflows only, with close to real time notifications. Any tasks assigned to the user within a 5 min window will be combined into a single notification email. This is in addition to the email digest being received currently by the user. This is disabled by Default and can be enabled in Admin Panel.

● Recommended: Use for your production instance only. ○ We advise caution if you’re thinking about configuring multiple instances for

email, as users can be easily confused on what they need to do. Note that should you go ahead with this, be sure to make users aware to check the email footer. The Activity Email footer states which instance has sent the message. The footer message can be configured in the Admin Panel.

● Recommended: Let your users control their own email preferences. ○ We are often asked if email can be switched on by default for all users. We

advise against this - introducing users to Axon should be done in a more managed way, and if users receive regular emails from Axon before their relevance has been introduced, you’ll encourage behaviour that is harmful in the long run - activity emails will be habitually ignored, or never seen because they are added to spam filters.


Functional Basics: Profiles, Stakeholders & Licenced Users Axon has a flexible licencing model, but users are often unsure how many of their allocated licences they have actually used at a period in time. We’ll show you how to below. To do this we need to outline how the People > Profile field works with Axon’s built-in permissioning system to give you the flexibility and control necessary for managing governance. We have to start by asking ourselves why and how someone might visit Axon - ultimately it depends upon whether they are looking for information, helping a decision making process, or managing content.

● Accessing information is free, whether or not the visitor has a user account. ● Even if the user only has basic user account access, they have unlimited ability to

raise and be part of built-in change requests and workflows, to manage change decisions / handle questions from the community of users. They can also hold stakeholder roles on objects (explained in the next section).

In order to manage these different requirements, Axon has two mechanisms - Profile and Permissions. Understanding these will explain why, in the graphic above:

1. Both the 2nd and 3rd columns (Viewer-only/Editor Users) represent Axon accounts with the WebUser profile.

2. However, only WebUsers that count as Editor Users cost a licence. Profile: When creating a user account in the People facet, an account type, called ‘Profile’ must be selected. There are 3 profile types available, as shown in the table below.

● Most users will have the WebUser profile, which allows us to carefully control what, if any, content they can change.

Permissions: Control how WebUsers gain the ability to manage certain objects when they are assigned responsibility for objects in Axon, i.e. if they are assigned stakeholder roles. The Axon Data Governance Playbook for Axon 6.2 42/150

● Stakeholder roles are maintained at the facet level. ● Each of these roles has its own set of configurable permissions which determine

what that user can do, whilst they hold that stakeholder role.

Axon Profiles The table below summarises expectations of each Axon account profile.

Name Licence Cost

Raise Change Requests & Participate in Workflow

Comments

WebUser (most users)

Depends on roles assigned on objects

Yes Default user type for most users. Cannot manage Axon content, unless assigned stakeholder roles permit this. Even then, it is the permissions associated with the role that determine this - only roles with New/Edit permissions incur licence costs.

Admin (Limited # of users)

Yes Yes Unlimited object creation/editing Limited access to Admin Panel Can help WebUsers with day to day problems.

SuperAdmin (Very limited, often max 1-4 users)

Yes Yes As Admin, but also control the look and feel of Axon, customisations etc.

Notes:

● Any user can hold stakeholder roles. ● All users can raise and participate in Change Requests and workflows without any

restrictions/licence limitations. Such users only cost a licence if other factors in the table have caused them to incur this (profile/role permissions).

● ‘Participate’ means that users can either be directly involved in workflow because they hold a role that is explicitly part of the workflow. Additionally, any other Axon user can be invited into an active workflow via the Discussion feature in the comments section (just add @FirstName, then select from the results)


Permissions (WebUsers) Permissions for each role are set by SuperAdmins in the Admin Panel.

There are three available permissions:

● View - the ability to see an object they have a stakeholder role upon, in the limited cases where it might be suppressed from general view. It has no licence cost - user remains a Viewer.

● Edit - the ability to edit this particular object only - if the user needs to edit other objects they need roles granted on those objects. Makes the user an Editor user.

● New - the ability to create new objects in that facet only. Makes the user an Editor user.

Does a new role cost a licence? Using the example shown in the picture above, if we need to add a stakeholder to a Process object:

● If the user is not a WebUser then they already cost a licence because of their profile, and this additional stakeholder role has no effect.

● If we are adding a Process Owner: ○ This role only has the View permission so does not cost a licence.

● If we are adding a Process Steward: ○ The role has two permissions that cause a licence cost to be incurred. ○ If the Axon user already has one or more roles with New/Edit permissions, no

additional licence cost is incurred. ○ If this is the user’s first Editor role, then they now start to cost a licence.


Monitoring Licence Usage If you need to check which permissions are assigned to a role, it is easy to check in the UI. Example: Glossary Steward: Any user can check the assigned permissions by clicking the microphone icon beside the role title in the stakeholders tab. Users with an Admin profile have access to detailed information in the Admin panel, below.

Admin > Dashboard has summary panel - it shows 226 users have incurred a licence cost.

The Licenced Users menu gives the details of the names and profiles each of these users has.

Functional Basics: Dropdown Descriptors Every Axon screen has a collection of fields that describe some aspect of the object you are viewing. Many of these appear in the object’s Summary tab. These can be text fields, but many are configurable sets of dropdown values e.g. Lifecycle, Type, Classification etc.


Out of the box the dropdowns are typically supplied with a lean set of defaults, such as those shown in the screenshot above (for Glossary Lifecycle). It can be beneficial to change our default values to match the terminology used by your organisation. These values are controlled by your central Axon team, to keep them manageable and meaningful.

● Less is more: Try to use as few unique values as possible - they have to be common to the whole organisation, not to support limited sets of Use Cases.

● Axon can be shipped completely empty of dropdown values, but that adds (often significant) preparation time to define and add the configuration before Axon can be used, so we recommend starting with our defaults.

● Should you choose the empty option, be aware that you’ll need to allow for the time required to create review and signoff these values before you can start using Axon. This can be affected by a number of factors in your organisation, outwith the control of Informatica or your chosen implementation partner.

Whilst we do recommend reviewing these values to ensure they’re consistent with the language used in your organisation, we’ve found that the values supplied are generally good enough to get started with. They can be amended (in the Admin Panel by a SuperAdmin user) as and when necessary.

● Note that some organisations will be content to let the DG team work these out for themselves.

● Others require more thorough assessments to be made. Where this happens, manage the process carefully, this can turn into an industry very quickly, with comparatively limited value in return (and a lot of pressure to complete the exercise and just get on with things).

○ Where you do need to justify decisions it is essential that a thorough explanation of the context, choices and associated reasoning is presented. Those making the decisions may not yet fully understand Axon, or any trade-offs you wish to make between rigour and simplicity of representation.

○ You could ‘just get on with it’ and let Admins use the Bulk Update feature to change the dropdown values later.

Although we think you’ll be able to make a good start with the default values, one area that might require early attention is the Stakeholder role names and permissions, which are discussed below.

Frequently Asked: Changing Axon’s Meta Model (Custom Fields) We’re frequently asked if it is possible to add new fields to a facet. Historically, when we’ve explored the reasons behind the request, we’ve found that that client isn’t fully utilising the power of relationships in Axon. We’ve talked about the basics of relationships here, and why they are more powerful than a simple descriptor field here.


More recently however, clients have occasionally presented cases where adding a custom field would benefit their DG initiative. As such, since Axon 6.0, SuperAdmins can configure ‘Custom Fields’ in almost all facets. Such fields are:

● Facet specific. ● Can be a variety of types. ● Are available for object creation in both APIs and in Axon’s downloadable templates.

Best Practice for Custom Fields We appreciate the excitement that clients may have at this addition to Axon. However, we recommend that the team that manages Axon configuration closely controls the proliferation of these fields. They need to ensure that Axon remains a tool for the whole organisation, where content needs to be easily understood by many different people from many different backgrounds and levels of experience.

5 Tests To Validate A Request With this in mind, when assessing a request for a new custom field consider the following principles, which are explored below:

1. Custom fields must make sense at the enterprise level. 2. Context is everything. 3. Use as few custom fields as possible. 4. Keep object creation simple. 5. Ensure that the need is not already addressed in the tool.

1. Custom fields must make sense at the enterprise level.

...in other words, do not add custom fields for individual initiatives. Whichever activity is taking up your time and attention right now, whether it is Privacy (GDPR, CCPA, PDPA), control (BCBS 239, Solvency II), or healthcare legislation.

● These are all equally valid reasons for knowing what gets used where, and why, however… they are just another reason for effective governance - they are not the sole reason the need exists.

● If your DG program using Axon is in the early stages, you run the risk of creating custom fields that make sense for the content that you have in Axon, but which will not scale to what you will add.

If you take a narrow, initiative focussed approach, this will quickly lead to decisions that fill Axon with bloated content. Axon’s value proposition is to provide a common understanding across all data, initiatives and business outcomes in the organisation. The focus must be on the common elements if Axon is to remain useful and relevant to the wider organisation. Especially in the early stages of an Axon implementation you might only be working on describing a couple of activities important to the organisation - adding a couple of custom fields for those initiatives may seem harmless. It might even keep project stakeholders


happy, and help adoption. However, think to the future, when you have described a more mature governance landscape:

● How many initiatives, policies, regulations, other use cases will that cover? ● How many custom fields per initiative? ● ...and how many custom fields will that add to any one object screen, especially the

Glossary / System / Policy / Process facets? ● If you get into this way of working, common understanding is lost, users have to work

harder to understand initiative level content, and engagement and usage will suffer. We already have anecdotal evidence from clients that tried this with other tools, or have discussed their needs in detail with us, and the answer seems clear:

● The number of fields that you’d add to the average screen would be unworkable, and cause more confusion and harm than good.

This is why we advocate the use of relationships. The solution scales easily, whereas endless custom fields may cause unnecessary maintenance work, and not easily lend themselves to easy searching. The best way to prepare your justification for managing such requests is to demonstrate the power you get from creating relationships.

2. Context is everything. A Custom Field may allow you to capture more information than standard Axon fields. However, they run the risk of keeping some content/ideas siloed, that may be relevant in other areas of the organisation. There may be a level of aggregation that is often used to identify collections of assets for a given use case. Axon has a number of facets that can be used for capturing that kind of view. These include the following which are described in detail above in the facets overview: Again, these may be better solutions. Connecting to these unifies concepts and builds a connected view not achieved via siloed fields.

● Organisational: Business Area, Capability ● Themes: Product, Client ● Borders: Legal Entity, Geography

These offer a more scalable way to capture and manage this information. One thing that may be best avoided is the use of a simple checkbox that simply says that something is in/out of scope of a given use case - the classic example of this is the commonly asked-for PII checkbox:

Context & PII Flags

We have always advocated a different way of handling PII, using relationships. Using relationships to policy, process etc gives a much better way of explaining why and how it is PII in the right context.

● Marking a term as relevant to privacy regulations with a simple Yes/No has very limited value - we need to know more...

● Relationships allow you to target the ‘why’ something is relevant...but we told you this already, here and here.


● The proliferation of privacy laws such as GDPR, CCPA, PDPA etc. has given ‘Personally Identifiable Information’ a lot of attention. However this proliferation means that many different legislative bodies in different countries are creating their own rules.

● As this proliferation continues, it might be reasonable to assume that the definition of PII will remain broadly consistent. However, the level of control applied to different classes of data may be less consistent by jurisdiction...

● So, where you organisation is subject to multiple privacy laws, there’s a risk that a simple PII flag doesn’t give the right level of information (e.g. which part of which policy/regulation affects it. Using our recommended approach handles this, although we can’t promise understanding and managing this complexity is easy.

What happens e.g. if the regulator changes just one article of GDPR? Naturally you’ll want to know if that changes anything for your organisation. You need to establish:

1. Which policies are affected by that article change? 2. Which processes did I create to manage adherence to those policies? 3. What are the data dependencies for those processes?

If you’ve created the right relationships, then you can easily and quickly use Unison search to answer these questions. Without the right level of context in your content, that could easily turn into a much bigger job, which starts with too many objects returned because the search find everything related to GDPR, not those items directly affected by the change.

3. Use as few custom fields as possible. Focus on things that are common across the organisation. Axon needs to scale across all data and business outcomes, so make sure that additions benefit the whole community, and keep the object screen as clean as you can. Following recommendation #1, above, will help you do this.

4. Keep object creation simple. Axon templates ask for as few mandatory fields as possible because getting things into Axon, and shared with the community is more important than exhaustive description. We think it's better to get the object created and visible to the community with a minimum of fuss, and add content as it becomes necessary/relevant, so we designed Axon to make as few fields mandatory as possible. With this in mind:

● When adding custom fields, they become available in the upload template and read/write APIs. Consider and control how many you add to each facet.

● Once you’ve made that determination, you then need to assess whether they need to be set to mandatory in object creation. They should only be mandatory if:

● Everyone completing the template recognises the question, and can answer it AND


● It is relevant to all the content that will be added to that facet (in the future) - if the field is only relevant some of the time, it must be set to optional.

This is especially important when content is added/refreshed via APIs - ensure that users maintaining API feeds have time to prepare for the changes.

5. Ensure that the need is not already addressed in the tool. As we mentioned above, we’ve seen a number of requests for custom fields that could already be achieved with existing Axon functionality. This is of course hard to do if you’re new to the tool. If you’re unsure, it’s always worth a question - please ask us or your implementation partner, consult the Axon Community page, or start a discussion there etc.

Custom Field Creation If you have assessed and accepted that a new Custom Field is appropriate, a SuperAdmin can do the following in the Admin Panel > Meta-Model Administration section:

1. Select the facet of interest. 2. Select Edit 3. Press Action > +

Notes:

● There are many types of fields available: text, checkboxes, dropdown etc.. ● Placeholder Text allows you to add guidance on the expectations for the field - keep

this brief.


Custom Field Maintenance - Editing/Deleting ● All editing/maintenance of Custom Fields is performed in this same menu. This

includes any dropdown values you create (so remember that these are held separately from Axons’ standard field configurations).

● If a Custom Field is deleted in the Admin panel, the field is permanently removed from the UI and bulk upload templates.

○ Once deleted they cannot be restored.

Axon Users & Custom Fields All Custom Fields are added to the object’s Summary Tab.

● Mandatory Fields are added to the main Definition section.

● Optional Fields are added to the Optional Fields section.

Custom Fields are added to bulk upload templates, and can also be populated via the API.

Custom Fields were introduced in an earlier version of Axon. One enhancement available from Axon 6.2 onwards is availability in Unison:

● Custom Fields do not show in Unison by default. Just like other fields, users can elect to add/remove them from the Unison Grid via the Grid Settings > Columns menu. They are also searchable.

● If the Custom Field is e.g. a Dropdown/Checkbox, it will have its own Filter (Custom Field 2, right)

● If the Custom Field is a text field it will be an option in the Text Search field (Custom Field 1, right)

○ Remember that, as with all non-standard text search options, you need to select it each time you wish to search upon it.


Frequently Asked: Deleting Content How to delete content in Axon is a commonly asked question. We’ll outline when and how to do this below. Before we do this however, we need to review the History Tab and understand the value that this gives us. Deleting content is something we need to approach carefully from a governance standpoint. We need to maintain an organisational memory of things that may have fallen from relevance/regular use. This is especially important when it comes to enquiries from a regulator. Such enquiries typically occur some time after the event under scrutiny, and you may need to understand the governance position at the time of the event. The History tab gives you access to this information.

The History Tab One of the standard tabs available in the object view of most facets is the History Tab. Here you can see the evolution of the object - changes and updates made to it over time.

You can see that object above has no history immediately available. This does not mean that there isn’t any. From Axon 6.1 EBF-1 onwards, Axon will show the last 6 months history of updates and changes by default. This time period can be configured to different values in the Admin panel.

History - Difference Report If you wish to see any other information not shown automatically, set the dates required in the From/To Date fields (see picture above), and press Compare. This will return a ‘Difference Report’ in a new tab, capturing all the changes to the objects in that time period.

Note that the Grid Settings Menu can be used to control the table output using e.g. Group By or Filters.


Grid Tools Menu (Black cog)

Grid Tools > Show Filters

Grid Tools > Group By

When Can/Should Content be Deleted? Now that we’ve introduced the History tab, let’s now focus on when to delete content. As the content you make available in Axon increases, there will be times when you want to remove content:

1. Simple mistake - content just added was in error** - it does not form part of governance goals, scope was too broad etc.

2. The content has ceased to be relevant to the organisation.

** Note that if the file was simply incomplete, deletion is not your only option. Most object uploads have an Update Existing upload option in the uploader main menu. You can use this to add missing content (make sure you download the object ID from Unison if you want to change an object’s name in the correcting upload).

If you fall into the first category, you might want to jump ahead to the section that tells you how to permanently delete content - recently added content is easy to delete because it won’t have lots of relationships associated with it. However, if once-useful content has fallen out of common use, let’s first look at when it makes sense to remove content from Axon. Content could be viewed as having 4 phases of life from a governance standpoint:


1. Active: Object is in regular use - it is searched upon, regularly connected to, provides context for business activity etc.

2. Retired: Object is formally retired/replaced due to changing business needs. a. The object is still available and easily searched upon but an updated

Lifecycle state informs users of the change in maturity. You may also want to clarify why the object is now obsolete in the description.

b. The object owners may raise change requests with community to update assets related to it, which starts the process of showing the new way of working. Similarly, owners of objects formerly related to it may naturally begin to re-point their assets at the new ways of working.

c. In any organisation of any size, it naturally takes time for everyone to become aware of these changes. The retired object may still be the first point of reference for those that don’t yet know about changes.

i. This means that the object still has power and draws community members to Axon.

ii. This continuing power should be harnessed - to inform and redirect the community - ensure that you update the retired object to inform and redirect to any new, relevant content.

3. Decoupled: Over time the object falls out of use, and its relevance fades. Its relationships and connections are gradually removed as the community adapts to new ways of working.

a. The object’s History tab keeps a record of everything that is removed. b. This can be particularly important for objects that may be subject to later

enquiry/investigation, e.g. from a regulator. Such enquiries may not be raised for some time - another reason to retain the object in Axon for a time.

4. Deleted: Eventually, there will be no need to retain the object, and it may safely be removed from Axon.

a. When is the right time for deletion? There’s no right answer here, but we’d suggest a minimum of 18 months as a default assumption.

Bad Reasons to Delete Content 1. Deleting Too Soon.

○ We’ve covered this above - it takes time for members of the community to learn about changes, so don’t delete content the moment something is not part of day to day activity. How long to retain content is context specific, but it’s more likely to be several months or even years.

2. Disagreement on Content Accuracy / Quality. ○ You can only put your best view of a subject area into Axon, and sometimes

what makes sense to you is interpreted differently by others.


○ We’ve observed cases where some part of the community asks content creators to delete/hide content because they either disagreed with it, or more commonly because the described reality did not paint a good picture of that community, or the organisation as a whole.

■ We say: Embrace the reality! Even if that reality causes some difficult conversations. A good governance climate should allow people to describe things as they see them. After all, it is commonly said that the first step in solving a problem is admitting it exists.

Win/Win Different people often have different understandings of the same situation. If you are challenged on Axon content that you’re responsible for, there are different possible outcomes. Crucially, any such interaction is a win for the organisation, because it promotes clarity and shared understanding. Such outcomes can include:

● Different communities/people actually do agree on the reality, but interpretation of the content describing it caused a misunderstanding.

○ ...which may lead to content managers clarifying that content. This is a win!

● The community member(s) challenging the content just misunderstood what they read, or didn’t know things had moved on. The interaction educates them. This is a win!

How to Remove Content from Axon Since Axon 5.4 we’ve provided functionality that permanently deletes content, subject to the caveats laid out above. The steps are:

1. Preparation a. Any Admin/Object Owner arranges for any remaining relationships between

this and other objects to be removed: i. Newly created objects erroneously added to Axon won’t have (m)any,

so this should be quick and easy. ii. Objects which have been in an Obsolete Lifecycle state for some time

should naturally have been decoupled over time, but a few final relationships may yet persist.

b. Examples of information that must be removed include: i. Parent objects.


ii. Impact tab - all relationships. iii. (Glossary only) Alias names. iv. Stakeholders can be removed by Admin user at this stage.

c. We recognise that not every aspect of such content may be removed during the decoupling phase mentioned above. Removing these relationships is currently a manual activity - we will introduce functionality to better automate this in a future release.

i. Note that this will extend only as far as that which is within the control of that objects’ stakeholders to manage.

ii. In other words, relationships that are made to the object being deleted from another object are outwith such scope - the stakeholders of such objects will need to be engaged (perhaps via Change Request/Workflow), so that they are informed and can take appropriate action to ensure they maintain control over their own assets.

2. Set Axon Status = Deleted a. The object’s editor should set Axon Status = Deleted, and only then remove

all stakeholders. b. Remember that Admin users can also use the Unison > Bulk Update feature

to set Axon Status on multiple objects. 3. SuperAdmin Deletes the Object(s)

a. Once an object has the correct Axon Status, and all relationships have been broken, a SuperAdmin user can then finally perform the delete:

i. Using Unison > Bulk Delete (see below) ii. Each object’s Actions menu has the Delete option.

Note that when an object has Axon Status = Deleted relationships cannot be created to the object from the Impact tab in other objects - the UI will not offer them whilst in this state.


Chapter 3 - Starting Your Governance Journey Whether you are trialling Axon with a PoC/Pilot, or are embarking on a larger journey after purchasing a licence, clients often have the same questions, and needs. We hope that Chapter 2 answered some of these questions, at a functions and features level. In this chapter, we need to change the narrative, and start to talk about how to set up a governance program that will work for your organisation. We’ll make reference to some of the features above, perhaps introduce others. However the important change we need to make is to downplay the tool we use, and think about the business decisions we need to make. Naturally, a full production rollout will have some additional steps you’ll need to think about, and we’ll discuss those in the next chapter. However, for now let’s assume the following typical situation:

● Axon is installed (or scheduled for installation very soon), but has no/little content. ● No integrations to other products are currently available.

○ This might look like a negative on your project plan, but embrace the time you have to use Axon standalone - you’ll learn a lot about how things fit together (especially using relationships), and how to use the facets we outlined earlier.

○ It’ll help you understand and plan better integrations when the time comes. ● You have a small team tasked with the initial rollout, who probably don’t know that

much about Axon. ○ You probably have a plan for a wider rollout once some preparatory work has

populated Axon with good examples of content. ○ Get your team booked onto an Informatica University course, so that they can

touch the tool and get used to it. ● You want to get started!!

○ You probably have Informatica Professional Services, or a chosen partner available to help you with this.

The key thing to think about is to review your DG challenges - why did you decide to use Axon? Use this to start populating Axon with carefully chosen content that addresses these challenges - do not start adding content simply because it is available or ‘might’ be useful.

● Break these up into a few mini-projects (we’ll call them ‘Use Cases’) that will populate different facets in Axon and allow connections to be made.

● Apply the 5 Implementation Principles when working through each Use Case - these will be explained on the next page.

● Remember that this is just the start of a journey - there’s a lot to learn, and whatever you do add to Axon should be aimed at the average employee, not a group of specialists - don’t assume the audience has any specialist knowledge of jargon or technical constructs. Make it easy for people to engage, some simplification of content can make this easier to achieve.


As you work through this, remember that communication is key - keep sponsors updated, and bring stakeholders in gradually - make sure they are comfortable with what you are doing and how you are representing the assets they own/care about. State and restate:

● The Goals of your DG program ○ What governance means (remember that it has evolved over time). ○ And where you are in the plan.

● What they are being shown, and how it relates to source information. ● Excite the community!

○ Show them the challenges you face and how you are addressing them. ○ Help them understand the tooling you use - make it look intuitive. ○ Share early win stories. ○ Be prepared to iterate your approach on feedback received.

The 5 Principles of an Axon Implementation These principles are frequently shared with new clients to help set the scene. We present them here in order to explain how we realise these principles via the extended discussion in this chapter.

1. Engagement & Adoption above all else Knowledge without community goes stale instantly

● The goal is not the best metadata but the most used

● High usage allows you to have a shot at adoption

● Connect into business facets for engagement and value

● Heavy governance breaks adoption ● Promote reflection, do not recycle

In other words: It is easy to get people to look at your governance tool once. Getting them to return regularly is the challenge. Make content engaging and easy to read, don’t make engagement complicated with lots of rules (some structure is useful though).


2. Think Big, Start small Have vision & principles.

● Starting small allows you to carefully curate the engagement.

● You won’t have the answers upfront: start small and continuously learn and improve.

● When sufficient learning has been acquired, the networked communities will bring scale fast.

In other words: Don’t try to think about

everything you’ll have to document over time. Work in the here and now, learn from that. Scale comes naturally as you gain experience and confidence.

3. Be guided by practical usage Focus on what is used, being complete and exhaustive often hinders usage;

● No knowledge for the sake of knowledge. ● Capture knowledge in a manner that is easily

created and consumed, being too precise and insisting on consistency often hinders usage.

In other words: Understand what the community engages with, and work to create more content like that. It keeps the momentum going.

4. Breadth over depth Outline first, add depth later if required.

● Context drives relevance, context allows relevant communities to participate.

● Less detail reduces the burden of maintenance.

● Unlock 80% of the value with 20% of the effort.


In other words: Remember that we want to present Use Cases in a way that allows the most people to take something from the example, and be able to understand if their activity has any connection to it. To do this, we do not to replicate every detail, as understood by those working in that area daily.

5. Do not model

● Models are hard work and only accessible to modellers.

● 99% of people do not understand models. ● Modelling at an enterprise scale has never

worked. ● Models can be referenced.

This can be a surprising message for those familiar with models to accept. Models have their place and deliver value to some communities. However, they will never help adoption and engagement with the wider community. Time and time again we have found that models require a rigidity of thinking that inhibits wider discussion and collaboration.

Find Your Way As you follow the steps outlined in this chapter, you’ll start to work out more details about how Axon can help your DG program. Many clients do choose to capture these in some form of Operating Procedures document (the exact name varies), which may give useful guidance to the wider community - in keeping with the principles laid out above however, base these on guidelines not rigid adherence.

● Tread cautiously but move fast - with initial loads and reviews. We have observed that the first few weeks can be a learning process for all involved. The pressure to achieve too much can be counter-productive - it introduces unnecessary stress, and may stop valuable reflection and iteration of content, which will lead to later issues. A small investment in time up front can pay massive dividends later.

● Once you’ve set the boundaries, stick to them. Scope creep is a risk for any project. One specific risk to DG is that assets and their connections are recorded just because they were available, not because they have been specifically identified as relevant to DG aims. Do not add content to Axon unless you know it is relevant.

● Less isn’t just more. Less means that it’s easier to follow the initial data loads, understand their connections, and follow a story. This can become harder to achieve when larger and more complex assets/connections are added.


● Avoid making too many changes to Axon such as large numbers of config changes/custom fields, as you are unlikely to have enough understanding of the long term effects of these with limited experiences/small amounts of content.

Start In the Right Place No company is perfect, so the areas causing discussion, inefficiencies, confusion or simply blocking progress or collaboration are a great place to start. We call these “Pain Points”. They are a good starting place because bringing people together and successfully making progress inevitably finds important message on the causes and solutions, that ought to be shared. This makes them excellent opportunities to deliver early success stories that create a buzz about the governance initiative. In the unlikely event of no pain presenting itself, chances are that you have a regulatory issue to address. Even here, the starting point varies - we have observed companies in the same industry start to address the same problem from very different places. Ultimately, they end up in the same place, bringing the right assets under close governance.

● For example, banks tackling the requirements of the BCBS 239 regulation are trying to show robust regulatory reporting. Some start with their documented processes, and then find and relate this to the data flows that deliver these.

● Others, however, started with lineage and later added the process (and policy) view. All of the above is necessary to fully address the issue, so why the difference in approach? Typically these clients felt they were stronger/more knowledgeable/better documented in some ares vs. others. They started with what they knew better, so that they could use that momentum to build up confidence before they tackled less documented/ understood areas.

○ Clarifying what you know may give context to what you don’t.

Start Small, Make Mistakes, Learn and Improve The picture below can often be useful in helping you decide where to start. It is impossible to bring thousands of objects under governance quickly, so don’t try to. The most critical assets are typically the best understood, although even perceptions of these can vary enormously.


Time and time again, DG projects have found that the documented/expected view is not completely accurate. This is a win. Documentation is notoriously hard to keep up to date, especially when that document is not always available to/accessible by those that could contribute to its evolution. Next, and perhaps controversially, don’t be scared to start again! The learning process that clients go through in the first few weeks is such that we have seen some clients come to the conclusion that they have developed a better understanding of their assets and structures and want to restart with a clean sheet (and a handy set of bulk upload files). This is not lost time. This is not a failure. If it happens, embrace it. This can be a very effective way of rebooting your DG initiative and developing your Operating Model along more workable lines that better guarantee success. Clearly you do not want to get too far into your DG initiative before making such a call. We therefore recommend that in the first 4-6 weeks you:

1. Agree a few Use Cases that get your user group working with objects in Axon 2. Don’t go deep - the 5 Implementation Principles apply to individual Use Cases too. 3. Share your work with stakeholders, and iterate based on their feedback 4. This work tends to happen in a period where product integrations are being planned,

but are not yet available. a. This is good for understanding how objects fit together in Axon. b. Builds trust in the integrations when they are delivered, and may even better

shape how they are delivered - remember to revisit these plans. c. It probably also means your content is stored in Axon bulk upload templates -

keep them in case you do decide to rework things. 5. Don’t start work in a pre-production instance expecting to move the bits you like to

Production - Axon doesn’t work this way, as we talk about below, and in Chapter 4.


By testing your knowledge and assumptions with light, quick Use Case projects, you’ll build up trust and confidence in your DG team and your stakeholders.

Starting With Axon: The Informatica Network https://network.informatica.com/welcome Informatica Network is a unified community that provides a healthy ecosystem for our customers to connect with their peers, Informatica experts, and the broader community to accelerate their learning, deployment and adoption of Informatica products using any of the interaction channels. In short, you should be able to find lots of material to support your governance efforts here. You will need a logon for Axon content, but it’s free and easy to join. Go to the Axon Community Page to find content for Axon practitioners created by Informatica, partners and clients. It has a lot of content that might help you at this stage of your project. Typical content includes:

● Discussion - Q&A ● All release notes for each new version of Axon. ● How to Videos. ● Access to Knowledge Base articles - common challenges and solutions. ● Blogs. ● Technical support documentation. ● The latest version of this playbook.

Starting Out - Typical Activities to Consider Different customers have different reasons for starting a governance journey. This in turn defines the ‘Use Cases’ that you will launch with - use cases are the business activities that you wish to represent in Axon. Ideally you should start with a few small-scale (remember to Think Big, Start Small) tests of Axon , perhaps 3 or 4. Also, don’t analyse each Use Case in exhaustive depth, go for breadth over depth. Each will have its own set of challenges and questions you need to address. These will help you to effectively:

1. Break the core elements down into content for different Axon facets. 2. Learn how to create relationships between objects in different facets. 3. Understand that some ideas that appear attractive will not scale for every Use Case.

Even if you have one clear initial deliverable, related to a privacy regulation, or describing the creation of a (regulatory, management) report, you’ll still get experience of this. There are no wrong answers here, but whichever direction you choose, remember the Implementation Principles at the start of this chapter. Which Use Cases should you go for? That’s a really hard question for us to answer for you, and why we have laid out the 10 most common elements of a new DG program below. You’ll


https://network.informatica.com/welcome

https://network.informatica.com/community/informatica-network/products/data_quality/axon_data_governance/overview

https://network.informatica.com/community/informatica-network/products/data_quality/axon_data_governance/overview

use some of them now, others later. The only ones to call out here as common/critical to every program are to Make a Plan, and understand what an Enterprise Glossary is. Aside from that, try to move reasonably quickly initially, don’t overthink things and do not be afraid to change and improve content/approach. The initial weeks are typically be a learning process for everyone. Consider where you create the initial content. We’ve seen a lot of activity focus initially on a pre-production instance, with an assumption that content is hidden away until ‘ready’ or ‘perfect’, whatever those terms mean. We don’t believe perfection is attainable, and Axon does not support staging content, as we’ve detailed in the next chapter. We believe governance is a Production activity, so don’t hide things away from your community. Or at least, don’t hide it away for too long. The rest of this chapter will discuss common elements of initial activity. Think of these as ingredients at your disposal - you are the chef, so you decide on the menu. Some of these activities are best done early to give direction to the project, others will be factors of the plan you create. If you have Informatica Professional Services, or another implementation partner, make sure you use them to help you work out the approach.

Make a Plan Data Collection Stakeholders & Permissions

Enterprise Glossary Creating Lineage Axon vs Modelling

Creating Context Relationships Workflow

...and Common Mistakes Before we go into the details of what we think you should do, it’s worth pausing for a second to challenge your expectations, so that you can focus on why some of these activities require attention. The most common mistakes we’ve observed at this point are listed below, and we’ll try to explain how to avoid them through the discussion afterwards.

1. Trying to do too much too quickly. 2. Make firm decisions about the structuring of content in Axon, which cause issues

later because they just don’t scale. A typical cause of this is unfamiliarity with governance (or perhaps with modern governance) and/or the Axon tool - you probably don’t have enough content in Axon at this stage to make an informed decision on what the right structure is. Examples of this are:

a. Over-customisation of dropdown values. b. Overuse of Custom Fields. c. Correct use and structure of an enterprise glossary, which is still evolving.

3. There is also the question of how soon you tell the wider community about Axon, rather than just the people that are asked to collaborate on the initial content load.

a. There’s no right answer here, but we have observed some clients work on creating content for many months in relative secrecy - not only does that defeat the open nature of governance, more importantly you have no


guarantee that the content you develop will be consumed/interpreted as you intended. It’s therefore best to learn what works/doesn’t as early as possible through community feedback and iteration before you go too far!

4. The final issue we’ve seen is an over-reliance on representing technical information in Axon. Axon naturally supports ingestion of information from technical sources, but these are different ideas - remember that Axon is intended to be a bridge between many communities - restating the same information available in other systems won’t help anyone. Axon content needs to have a level of simplification, or abstraction, in order to be meaningful across the whole organisation.

Activity 1: Make a Plan - Use Cases No matter how easy you make it for the community to engage in the program you build, it requires an investment of time and money. Someone will want to know that you have delivered some return (ROI). It’s very difficult to measure the effects of good governance, because it tends to stop bad things happening - fines are avoided, as are all sorts of costly mistakes. Inefficiencies are reduced, over a longer period, too. It is difficult to quantify the cost of things not happening, but what you can do is revisit the reasons that drove you to start the program, and create plans to mitigate/solve them:

● What were the Pain Points, and how well have we solved them? ● Do we feel the company is in a better place - more connected, aware of

interdependencies etc. Remember the Implementation Principles - Breadth over Depth. We need to describe things with enough shape and form to be recognised by the community, but we do not need to spend time exhaustively documenting every aspect of them - by focussing on the broad details that the average Axon user would understand you stand a better chance of people both understanding the content, and seeing how it relates to their activity/assets.

Activity 2: Start Collecting Data Before Axon Install Clients often want to get started preparing data before they have access to their Axon instance. Data collection should always be part of a planned set of Use Cases/Mini Projects, as we discussed above - add content because it will add value, not because it might be useful. One thing you’ll find on the Axon Community Page is a Data Collection Starter Pack. The Data Collection pack contains some of the most commonly used Bulk Upload templates to help you get started. When using the Data Collection Starter Pack, you may wish to refer to the overview of facets, above to help you think about how to structure your assets, and what kind of assets typically fit into each facet.


Activity 3: Initial Configuration & Customisation

3.1 Configuration - General Approach SuperAdmin users have the ability to change a lot in Axon. You’ll learn about this as you work through the playbook. Axon ships with a basic configuration that covers a lot of ground:

● Basic values for Dropdown menus in facet objects. ● Glossary Rollup Settings (set to Disabled). ● Object Stakeholder Names & Permissions (See below). ● Customising the Meta Model - Custom Fields.

SuperAdmin users can change these values/settings as the need arises. However, we’d recommend that you don’t change too much, too soon in the early stages.

● Why? The key reason is your unlikely to have enough data to make the right call. Customers typically start off with only a limited set of Use Cases (which is a good call), which will not be fully reflective of your steady state needs.

● Focus on creating the content using the default settings for as long as you can. The 5 Principles of Implementation outlined at the start of this chapter mean that you’ll try lots of things, make mistakes and iterate until you’re happy.

● This advice is especially important for the glossary facet - please read the extensive commentary that follows in this chapter to understand why.

3.2 Stakeholder Framework Axon has a very flexible governance model, which allows you to assign control over specific objects to the right people. Chapter 2 has a detailed explanation of how account profiles and WebUser permissions can be tailored to facilitate this. One area that might need early attention is the Stakeholder framework. Clear ownership/responsibility structures are essential to effective DG - if no one is actively managing your key assets, you’ll lose control of what’s happening very quickly. In other words, people (who have Axon user accounts) need to be appointed to manage communications from the community and to assess when things need to change. This is why most facets have a stakeholders tab - to declare to the whole community who the appointed people are. The wider community of users often get their first look at Axon after a central team has performed initial data loads, and new users often find they’ve been assigned stakeholder roles in objects. It’s good practice to ensure that these role names are as meaningful as possible.


If you choose to vary the names of the roles (some clients believe everyone is a Steward, so avoid using one of our default naming constructs), or add additional role names, we have a few recommendations that work well:

1. As ever, don’t do too much too soon. ○ Keep it simple until you have a full view of requirements - many clients are

happy with the simple structure shipped with Axon. 2. Job titles do not translate well to Axon roles

○ You probably have too many different job titles participating in governance within your organisation to match stakeholder roles to them. Less is more.

○ When you create Axon roles you are asked to type them (see picture below): Ownership, Stewardship, Knowledge and Authority. If you do need to add more roles, we suggest starting with a maximum of one role per type, but whatever you choose to do, create as few roles per facet as you can - you can always add more later.

○ Workflows, as we’ll see soon, are designed based on assigning tasks to roles. Fewer roles makes managing workflows much easier.

3. Roles apply to individual facets only. ○ We recommend keeping the name of the facet as part of the role name -

we’ve seen some clients assign generic role names such as ‘Data Steward’ to multiple facets. This caused confusion because new users didn’t understand which facet their roles applied to.


3.2.2 Role Permissions Axon ships with a set of pre-configured roles and permissions for each facet. A typical facet will have the following:

Role Permissions Typical Duties

<facet> Owner View Ultimate responsibility for the asset but not involved in day to day maintenance except, perhaps, workflow approvals

<facet> Steward View / New / Edit Manages content day to day, handles enquiries and most workflow activity

You’ll need to give some consideration to how many people might be assigned each type of role, to assess how many of your licences will be taken up.

3.2.3 Everyone Is An Admin? In the early days of implementing Axon it’s common to see only a small community of users working with the tool, understand capabilities, shaping procedures and ideas. This often means that the number of active users is less than the licence allocation purchased. This in turn means that you may be able to temporarily allow all the members of this small community to have the Admin profile. It allows them to create and edit in any facet, and perhaps view the features of the Admin panel etc. It is a good way to accelerate understanding, just remember to position it carefully. It’s clearly not a sustainable solution, and you may soon need the licences back to allocate to their proper owners.

● Whilst it has many advantages, just remember that you won’t get a feel for the way that the permissions engine controls WebUser access to create/edit objects, which is likely to be an important part of the wider governance model.

● We advise against making everyone a SuperAdmin. Your IT policy probably won’t let you do this anyway, but it is vital that changes to the config are closely controlled.

If you do make everyone an Admin for a while, also bear in mind that this affects what they can see - we talked earlier about the ways in which duplicate/erroneously loaded content


can be suppressed from view in Axon (using Axon Status = Deleted). Admins can see all this content by default, so may need to use searches to hide it from view.

● This is especially important when conducting Show and Tell meetings to update stakeholders on progress adding content. It may be beneficial to create a WebUser account and run the demo as that user.

Activity 4: Creating an Enterprise Glossary It is impossible to manage any DG initiative without a set of agreed definitions that can be used to relate and connect everything that will be recorded - after all you are likely to be bringing together assets and colleagues that do not normally talk to each other, or understand each others’ activities in any great detail - it is inevitable that there will be differences in understanding, terminology etc, and that these will cause temporary confusion, or worse. This has to be addressed. However, this doesn’t mean that everyone has to start following new/unfamiliar naming conventions. A key advantage of Axon is that we allow users to describe their day to day activities in the same language they use every day - however, to help others understand that area, we relate the activity/assets to a central set of definitions that provide a translation/disambiguation - this facilitates comparison and enterprise wide understanding. That’s where the Axon Glossary facet comes in. As such, despite the earlier statement that you can choose which of the activities in this chapter to work through, we are certain that you’ll choose to create a glossary as one of your first steps. Of course, it doesn’t have to be a full glossary, that might take time. And an enterprise glossary is worth getting right. Over time you’ll probably have to bring in multiple sets of definitions that have been maintained by individual areas, but don’t worry about that right now. You’ll probably start with just the one that best fits the initial Use Case(s) you decide to populate Axon with. There are a few key messages that you need to understand before you start. Creating a usable, enterprise glossary is vital to the long term success of your governance program. There is therefore extensive discussion of this topic, which we encourage all readers to read and re-read. It is almost certainly a key difference in approach to your governance activities up until now, and you will need to be comfortable with the principles before you start populating the facet.

● If you have any uncertainty, please reach out to your implementation partner, or Informatica Global Customer Support for advice.

Whatever you create, it has to be a list of usable definitions that can be understood by the average employee/Axon visitor.


What does Usable mean? Simply put, anyone in your organisation should be able to get value from a glossary. If

they can’t, they’ll visit a couple of times, and then revert to whatever they used to do - we need repeat visits that become a habit, we adoption of this new way of working.

A usable glossary typically has the following qualities, which we’ll expand on below:

1. Is NOT a data model as data models are only intuitive to data modellers. 2. Uses hierarchical levels that feel intuitive to the average business user.

3. Describes data concept sin a system agnostic manner (the diversity of system implementations we capture in system & datasets & attribute facets)

4. Has easily readable definitions, light on jargon. 5. Over time the relevance to the business for each of the glossary terms will be

captured in Axon through links to other facets e.g. Attributes, Policies, Processes etc.

Once you have usable definitions, it will be easy for others to assess whether things that they load are relevant to these definitions, and encourage them to make relationships to these definitions - this gives us a wider understanding of who uses what.

4.1 Common Misunderstandings of a Glossary Before we start explaining what makes a good enterprise glossary, it might be worth talking about what does not. We’ve seen these misunderstandings occasionally - either because the governance team started off with one of these in mind, or their community interpreted them this way. As such, even if you don’t interpret the glossary along these lines, these are misconceptions you might need to recognise and address when engaging with the wider community.

1. An Axon Glossary should describe usage. ○ It is for conceptual definitions only. You should not expect to understand

specific usage from the glossary facet, that will come from the connections you make to other facets e.g. Process, Policy etc.

○ The Glossary should only describe the nature of the data concepts, any organisational or usage views are best captured through linking to those organisation and usage facets e.g. Process, Business Area, Policy etc.

2. The Glossary is a Data Dictionary. ○ The glossary is not the place to record all the contents of every database

table and the fields/columns contained therein. ○ All those tables will have multiple examples of the same idea in use (e.g.

Cust_ID). We should define the idea in the glossary, and map any usage of that idea via relationships (Attribute x Glossary, Policy x Glossary etc.).


3. A Glossary can only contain the official set of definitions. ○ We’ve seen some clients restrict what can be added to the glossary, and only

use a limited collection of definitions (sometimes called the ‘KDEs’), which constitute the n most important concepts in the firm.

○ As we’ll show below, an Axon glossary has to be more flexible than that. These limited set of definitions do not serve everyone’s needs.

○ If any concept needs to be understood by anyone in the business, it needs to be in the Glossary.

i. ‘In the business’ is emphasised because a lot of technical information is never exposed to the business, so is unlikely to give value.

4. Individual department glossaries can be ingested and managed separately.

○ Axon hosts an enterprise glossary, aiming to drive alignment across the firm. It needs to serve the entire firm, not to support local areas holding their own information in isolation - persisting tribalism defeats wider governance.

○ Assimilating multiple departmental glossaries will inevitably uncover duplication, both literal (same name) and semantic (same idea, different names) which has to be addressed. This process of unifying department glossaries typically is a gradual process: align on top levels, shared section and deal with the items that are conflicting over time.

5. The glossary must follow a rigid structure as defined by a modelling construct. ○ Often a surprising/controversial guideline for some members of your

community. How an enterprise glossary is organised has to follow its own path, and cannot be constrained by modelling conventions. Indeed, remember the 5th Principle of Implementation - do not model!

○ In any case, the real reason for Axon glossary structure is simply to make it easier to find objects. Start with something that is intuitive to most business users. It will almost certainly change as you evolve.

6. I need a separate GDPR Glossary (or other Use Case)

○ You cannot organise your glossary against any one Use Case because your data concepts will be applicable in multiple situations e.g. personal data elements like Name and Address are relevant to GDPR, but also to many other use cases.

○ Organise and define your glossary as to the nature of the data - usage, relevance, compliance pressures etc. will be captured through linking the glossary to other facets e.g. Process, Business Area, Policy, Project, etc..

○ However… if a piece of legislation creates new concepts that you feel have to be defined before their application can be understood, that might well be a valid reason to add some terms to your glossary. Where they are placed in the evolving hierarchy is case-specific.


4.2 What is a Glossary? Now that we’ve stated what’s not a glossary, let’s deal with what it is...

● A reliable, accurate and actively managed list of terms and concepts in use in an organisation - the name varies, and might be called a Glossary / Taxonomy / Ontology etc.

● A glossary is typically hierarchically structured to provide an intuitive way for users to find or add new terms.

● It should help users understand the definition and indicate application of individual concepts, so that everyone knows when and where its usage and purpose would be relevant.

○ Without compromising the definition, it should be as brief as possible. ○ Clarifying what something is NOT can be a powerful element of the definition,

especially where common misconceptions are known/expected.

The picture below shows a Glossary concept - a unique customer identifier, known (officially) as CMD-ID. The idea is described once in the glossary, but we can see from the other search results, that it is relevant to many assets.

When we move over to the Attributes facet, we see that there are different local names for the data points that represent this CMD-ID concept. Such differences in naming are an unfortunate reality for every organisation. It is not always clear that an attribute/field in one table is the same as something in another table, just because they have different names. Axon addresses this by letting local users express things in the terms they recognise, but letting the link to glossary give other users a translation/disambiguation. This removes the risk that users can’t understand the attribute because of unfamiliar names and look past them to understand what they represent. All the examples of attributes in this example have business friendly names/labels - imagine what they’d look like if they had physl_nm_strctrs, and how easy it would be to know what they did... Note the last column, Glossary. These attributes, whatever their local name, have been related to the central definition that allows everyone to understand their purpose.


4.3 What is an Enterprise Glossary? There may be multiple glossaries in use in an organisation – the lack of easily accessible central definitions can often inspire some local areas to document their own, which then quickly take on a life of their own. They do deliver value for the community that has access to them, but users are typically only aware of the one most relevant to their role/department, and it only caters for things that are important to that department. That’s the old world. Axon promotes the use of a single enterprise glossary, which consolidates all knowledge:

● In one place. ● Removing the inevitable (and often considerable) overlaps/duplicates that occur

when multiple glossaries are managed in isolation of each other. ● Using a structure that makes sense at an enterprise level, not simply a replication of

the existing glossaries. We rarely find that sets of definitions created by different areas follow the same design, so combining them requires a design of its own.

This doesn’t mean that individual areas should be excluded from the creation and evolution of definitions. Many different areas/departments have to use the same concepts and definitions as others every day. Using Axon they can and should work together on the same concepts to ensure clarity and shared understanding, so that changes in definition are sympathetic to all uses. This will promote more organised change.

4.4 Characteristics of an Axon Enterprise Glossary Whatever it is known as in your organisation, an enterprise glossary should ideally have the following characteristics:

● Clear and Unambiguous: A collection of well described entries that help users understand the meaning and application.

○ A glossary is no place for heavy use of jargon/technical language. This has its place - for those that understand it - but will always be a barrier to engagement for the majority of people that don’t.

○ (You may find that Axon has additional, separate fields for capturing more complex aspects of a concept).

● Usable: Easy to get value from, intuitive to search, read and use.


● Hierarchical: a common sense structure/order makes it easier for users to find terms, and to add new terms in an intuitive way.

○ It also adds context to the description of the object. ● Unique: Duplicate terms cause confusion - which is the right one to choose?

○ You may find situations where the same term is used in different areas to mean totally different things. Such instances need to be exposed and contrasted so users clearly understand when the can/cannot use each term.

○ Even where the duplication seeks to show the same definition applies in another context, this can be confusing. Connecting all uses to the same definition gives this context of its applicability in different scenarios.

● Flexible: the glossary has to cover a large range of themes, concepts and activities ○ As you’ll hear us say time and time again, user adoption is more important

than anything. ○ As such we do not support any particular modelling ideology for glossary

construction, so be prepared to compromise on rigid adherence to a given model when constructing your Axon Enterprise Glossary.

4.5 Characteristics of a good Definition Finally, just before we discuss some common challenges, consider what each individual definition should look like:

● Brief and to the point. Wordy definitions may raise more questions than they answer, assuming that users can even be bothered to read them - Large tranches of text are a barrier to engagement and adoption.

● Unambiguous. Definitions need precision: state what is covered, and what is not. ● Clear about the use and the purpose. ● Written to define the concept rather than just the word. ● Should reference other concepts where necessary to provide context. ● Use an absolute minimum of jargon/technical terms, abbreviations and acronyms. ● Should not use the word/term being described in the description. ● Practical - offer examples to illustrate and give context.

It has also been said that one characteristic of a good glossary steward/owner is to be open to challenge and feedback - if you get feedback from the community, be prepared to adapt - they’re just trying to tell you that whatever sounded clear to you doesn’t quite work for them. Once again, pragmatism over purity has been found to lead to greater user adoption.

4.6 Creating an Enterprise Glossary 101 - Do’s & Don'ts Based on the comments above, try to follow these guidelines as you build out a Glossary.

4.6.1 Let the Glossary Find Its Own Structure A good glossary will be hierarchical. The parent/child construct allows divisions and subdivisions of content into sensible groupings (we avoid calling these ‘logical’ groupings to The Axon Data Governance Playbook for Axon 6.2 74/150

avoid confusion with technical constructs). The primary reason for these groupings is ease of search. Ideally the structure only groups concepts in relation to their nature - any organisational or usage view is represented by connections made to other facets. We also mentioned above that, as your enterprise glossary evolves, you’ll add content that may mean changing the structure - things like new Use Cases and assimilating additional glossaries (e.g. that have been maintained by different departments/areas) will cause you to reassess how things are structured. This means that you shouldn’t worry too much about the Glossary ‘Typing’ for now...

4.6.2 What is Glossary Typing? You may have noticed that Axon ships with some default glossary typing to help illustrate the divisions and subdivisions that help design this ‘sensible’ structure. We are often asked how they should be used. Hierarchy vs. Typing: Type is a mandatory field in every facet it is used. Despite this, in the glossary facet, we would recommend at this stage, to do everything you can to avoid drawn out conversations about the right typing whilst you try to get started.

● Remember to focus on engagement and adoption - the business only needs the definition.

● If you’re just starting out then typing is the least of your issues right now, so upload everything as a Term and just let the hierarchy evolve.

● In a mature glossary, we’d suggest the following:

Type Description

Domain Separate subject area. Typically does not have a parent.

Entity Subdivision of a Domain - there are often several per domain An entity is typically an immediate child of a domain Likely to have multiple terms as child objects.

Term Definition of a specific concept/thing that is important to the organisation.

Notes

● Domains and Entities might need/have full definitions themselves, but equally they might be simple dividers/placeholders to separate content.

● Domains and Entities might be more obvious candidates for associating to Data Sets because they cover a slightly wider focus than individual Terms.

● Attributes are typically more likely to be associated to Terms. You can bulk update Typing later: ...if it gives value - it may make some searches easier in a mature glossary, as shown below.


The picture to the right shows that the subject area of ‘Party Data’ (which describes aspects of relationships with customers) has been defined as a Domain. There are further subdivisions of this area, as can be found in the Relationships > Hierarchy tab, or via Unison Search, below, using the Include Immediate Children filter.

On the left the Party Identifiers Entity, has been expanded to show the collection of child Terms within that subdivision. Changing the Unison Search filter to Include All Children in the previous search would find all such subsections beneath the Party Data Domain. This example shows a simple 3 level nesting of Parent/Child relationships, each with its own typing. Axon nesting can go (many levels) deeper than this (if there is a good enough reason AND you have a mature glossary - don’t do this early on). Note that you won’t want to have to create

multiple Types for different levels - as ever Less is More (and anyway, Unison has a separate Level search filter for finding heavily nested terms). To summarise:

1. Only use Typings if they are meaningful - you may never choose to use this typing at all.


2. Some of your community will think this is an important topic, but they typically come from a modelling background. However important models are for some, they are not an effective way to explain things to the whole community, as we said in the 5 Implementation Principles at the start of the chapter.

4.6.3 Don’t add technical content to a business glossary Some customers have sets of definitions that mix highly technical content with the wider set of more business focussed definitions. Information about technical joins and technical relationships is rarely a suitable candidate for such a business facing Axon glossary.

● They may often be found nested in structured glossaries, with more relevant business terms and concepts sitting at a higher level.

● Whilst invaluable to technical users supporting the business community these terms rarely mean anything to business users. Including them can add a lot of unnecessary content to Axon. This can often be a barrier to adoption - such content scares people off!

● Where this occurs, consider ingesting only the higher level objects that have more general application.

4.6.4 Deduplicate - Literal Duplicates A literal duplicate occurs where the same concept name used for totally different things.

● Where you find these, do what you can to help users understand the right way to go. Ensuring a good description is a good start, but persisting literal duplicates that reference different concepts is not supportable in the longer term.

● Even if you can’t make all the required changes now, make a plan to address them and follow up as soon as you can, because vagueness defeats engagement and adoption.

○ Add a suffix to each name, for now, to help clarify? Whilst we don’t recommend this as a lasting solution, Axon will allow you to upload content with duplicate names, as long as they have different parents.

○ Maybe now is the time to adopt clearer names and break from existing practices for the greater good? Whatever the pain of getting this agreement now, it pays back in the mid/long term.

● Note that where you cannot change the naming to disambiguate, Axon gives users contextual clues that may assist:

○ The picture below gives some examples. ○ Note that when using bulk upload files to create content/relationships you may

need to tell Axon the parent to avoid the upload failing. i. Even if you cannot disambiguate the original name, the Name / Parent

constructs must be unique.


In Unison grid, the parent is shown

When creating relationships in the Impact tab, the search box returns the results with parents in parenthesis

4.6.5 Deduplicate - Clarify Conceptual Duplicates A conceptual duplicate is where the same idea/thing has become known by different names in different parts of the business. It is highly desirable to describe the same concept under one term that everyone accepts... but it’s difficult to make this happen in a short period of time

● Creating two separate definitions that appease different communities is not a good solution - where users are presented with two possibilities, relationships will be made inconsistently between each, and user confusion will not help Axon adoption.

○ You also lose one of the key benefits of aligning everything to one term - getting enterprise visibility of all activities that are supported/relevant to this concept.

○ Where all contributors relate their assets to the same central Axon glossary objects, you’ll quickly build up a holistic view of how the same concepts are applied in different parts of your organisation.

○ Many clients have accepted that multiple entries will inevitably occur and have developed Axon workflows to help users address this, and work to unite the descriptions, when discovered.

● Use of the Alias feature in Axon allows you to create and maintain one definition, under the ‘official’ name, but to record alternative names that can be searched upon.

○ Current functionality in both Unison Search and Quick Search allows users to search for the term they recognise, but for the ‘official’ name of the term to be returned.


Quick Search for ‘pd’ finds the ‘Probability of Default’ term, because ‘pd’ is recorded as an Alias name.

Unison Search can find Alias names if search is configured as per screenshot

4.6.6 Deduplicate - Repetition of Same Concept The next issue we’ve seen clients try to address is where a glossary has been created by rigorously following some form of modelling convention. We’ve observed that the duplicates found therein are simply repeated statement of exactly the same concept, due to modelling rules, and often seek to show the application of the concept in different situations.

● You’ll know by now that we do not recommend this approach.

4.6.7 How to Name Your Concepts As we said earlier, the primary goal of a glossary’s hierarchy is nothing other than ease of search - business users want to find something and understand it. Give them this and you increase your chances of engagement and adoption. One barrier to easy searching that we see from time to time is unnecessary naming constructs that defeat ease of search. Concept names/references should not be relied upon to give examples of intended usage. Examples of this are where collections of concepts all have common prefixes such as:

● Customer Collection Activity - Default Notice ● Customer Collection Activity - Date of Default Notice ● Customer Collection Activity - Amount of Default ● Etc…

Entered into Axon this way makes actually makes Axon more difficult to use. You might think that it’s easy to find everything relevant to this area of the glossary, but long names are difficult to read, in Unison, in objects and especially on map labels and overlays.


Each of the concept names below describe exactly what each is, and the (glossary) subject matter area context is provided through the parent/child relationships. This type of search* (note the search is on the parent name with the Include All Children filter added) would be far more difficult using the naming construct above, because of the number of results that would be returned from the keyword search. *(also note that the screenshot has been crafted to show both the search and the results in one picture)

4.6.8 Supporting Multilingual Organisations We’ve seen many organisations use the Glossary > Alias feature to help colleagues find definitions written in other languages.

● Some clients try to promote governance ensuring activities are recorded in one common language.

● However, even if the main description is in one language, language variations can be added as Aliases to help users find key terms.

○ Term: Contract ○ Aliases: Vertrag, Contrat, Contrato, Contrarre, Kontrakt

4.7 Glossary Unification Ingesting multiple glossaries invariably has a huge overlap of literal and conceptual duplicates. This has to be addressed (again, same reasons as laid out above), and the sooner you can do this, the easier it will be for everyone.

● Naturally some group, committee or individual will have to manage (and referee) this process. There will invariably be inter-departmental politics and disagreements about which name should be adopted as the organisation standard.

● Where alternative names for concepts are retired, these should be added as Alias names, to ensure visibility and adoption of the new term - people familiar with the retired names will still search for them (it takes time to change habits) - if you don’t help them find the new term you risk damaging the credibility of Axon content and subsequent adoption.

● In practice it’s more likely that unification will happen in stages - you’ll use whichever glossary that makes sense for the initial data load, and then deal with how best to ingest subsequent glossaries later, as new initiatives require other glossaries to be ingested.


○ When consuming additional glossaries, remember what we said earlier - be flexible about the structure of the emerging Axon glossary - the first glossary loaded should not be allowed to define the end structure.

4.8 Managing Glossary Definition & Evolution A common requirement for Axon is to track and identify the maturity of glossary definitions. Axon manages these different stages through the use of the Lifecycle field, which appears on the Summary tab of almost every facet and object. Definitions often evolve as follows (with suggested Lifecycle values from Axon defaults, clients often have their own versions). Note that whilst the Lifecycle states shown below must currently be set manually, we are working to automate this as part of an Axon workflow.

Step Description Suggested Lifecycle

1 The need to describe a new concept is established A local expert (often a Glossary Steward/SME) is tasked with initial definition

Proposed

2 Draft is peer reviewed and checked with community Proposed

3 Revised draft is submitted for formal approval. How this happens varies but typically follows one of two paths:

1. Approval through some formal body (use the Axon Committee facet - see below)

2. Evidence of the peer review above may be enough to publish a workable definition

Awaiting Approval

4 After formal acceptance of the definition, the term is recognised as fully approved.

Approved

5 Any further revision of the term as needs evolve may require that Lifecycle is changed to reassure the community that evolving needs are being assessed

Under Review / Awaiting Approval

Some users have been tempted to link every glossary object to the relevant committee object to show they should be involved in approving definitions. We do not recommend this approach, as the maintenance of the object connections involved would be onerous and give little value.

4.8.1 Use of Workflow for Definition Approval Both the initial creation of a definition and any subsequent amendments can be supported by an Axon workflow to ensure that all such requests follow the same approved process. Each


instance of approval can be evidenced via a Change Request, which is permanently linked to the term, and will be found when the objects is searched in Unison.

● Where you use changing Lifecycle values to denote different states of maturity it is recommended to explicitly mention this in the workflow step description to remind your stakeholders, thus ensuring compliance.

● Where a committee/body is involved in the approval process, you may need to create a workflow step to allow for such approval.

○ Remember that workflows allow you to assign tasks to roles in the same facet ■ As mentioned above, adding a Committee stakeholder to every

glossary object is not a practical solution. ■ Workflows don’t (currently) support multi facet swimlanes.

○ We find that the most practical approach is to create a step that allows the appropriate user (often the Glossary Steward/SME) to take the definition Awaiting Approval to the approving body.

■ The Steward/SME can then update the change request with the decision, and as part of another step, change the Lifecycle accordingly

○ Another approach may be to use Unison > Bulk Update to change the Lifecycle values in one bulk action

■ This action is only available to Admin/SuperAdmin users

Example 1: Simplified approval workflow with Owner approver

Example 2: Simplified approval workflow, with Committee approval. Step instructions state the Lifecycle value.


4.9 Axon Glossary and Data Models We’ve probably made it pretty clear already that we don’t think models help enterprise understanding. The purpose of this section is not to repeat this message but to give you some messages that might be useful in explaining this. Remember that we do appreciate that models have many advantages and bring rigour necessary to local activities. However, good governance forces us to express what’s actually happening, and that often requires that we take a more flexible approach.

Don't model

User Adoption is the objective

Create a usable glossary - It will evolve as it gets used

4.9.1 Axon Glossary & Physical Models ● The Glossary captures data concepts in a system agnostic manner. ● How those data concepts are being implemented in real systems, reports etc. is

captured in the Axon Data Set and Attribute facets ○ These objects can in turn be linked to Glossary terms to show that they are

manifestations of the concept in use somewhere in the organisation.

4.9.2 Axon Glossary & Logical Data Model (LDM) ● The Axon glossary serves as an inventory of data concepts. ● Axon glossary items can be linked to other glossary items to capture meaningful

semantic relationships. ● Typically different data domains are contributed by different business communities

with different parts of the glossary being at different levels of maturity. ● In a logical model the consistency of representation and structure are paramount.

The model stops being a model without it. The Axon glossary can reference logical data models.

● Unlike a model, there is no right or wrong for the Axon glossary. Clarity and adoption are paramount, not the purity of the model.

Activity 5: Creating Policy, Process & Project Objects The information in this section applies to the creation of objects in the Policy, Process and Projects facets - the same considerations should be used to decide how to load this content. The description of facets in Chapter 2 outlines suggested uses for these facets.


These facets are important in Axon because they often give the context to why data is flowing around your organisation - they capture the key business imperatives. The key design considerations for these facets are:

● Decide on the right level of granularity a. Creating one object to describe e.g. a process allows users to see it and

relate their assets to it. Vs.

b. Creating a Parent object with child objects that describe the lower level detail - this allows relationships to be made at a more granular level, which can often be useful.

● Remember that Axon is not a process modelling tool, so don’t try to recreate complex processes in the same detail a modelling tool can do. Axon only needs to capture the contextual links and metadata flows.

● Only you can decide what’s right in your organisation, but you’ll need to relate every asset to the same object. All these facets are hierarchical, and that allows you to break things down into more detailed elements that may allow relationships at a more useful level - Policies: split into major clauses, Processes: Detail all the steps on e.g. a Visio diagram that have metadata requirements that need to be described.

● Manage the detail a. When visiting any object in such a grouping you’ll find a Components/

Relationship tab which details the other relevant objects. These maps have overlays that show dependencies where they occur, which may be more useful than against just one object.

b. In Unison Search, do a Keyword search for the top level object, and add in a Filters > Children search condition to return all relevant objects. This isolates just this collection of objects and everything they have been related to in Unison.

Granularity Example 1 - splitting a policy into major elements. The Hierarchy grid allows users to see the detail. Project objects also have this view.


Granularity Example 2 - describing process steps shows a components map.

Activity 6: Relating Assets Together We introduced Axon relationships in Chapter 2 when we talked about functional basics. Creating relationships between Axon objects is the key to providing context and visibility for why objects are dependent/affected by others. Have you noticed that when you search for something in one facet, Unison Search returns returns relevant objects in other facets? This is because the community has made these links - as the community create their own stories and state their dependencies, we build up an organisational level view not available anywhere else.

6.1 Relationships Are More Meaningful Than Descriptor Fields This is one of the key design principles of Axon, so please ensure that you understand the content of this section. We believe that relationships are a much more flexible and scalable way to describe the context and relevance of two objects than the new custom fields feature in Axon 6.0. To better explain this idea, let’s explore a real example, and one of the most commonly asked questions by clients establishing their GDPR (or other privacy regulation) response. Clients have often asked us why we have not made a ‘PII’ (or Personally Identifiable Information) field available on glossary objects so that they could easily identify them.

1. The first reason is that ‘PII’ is a concept specific to one single use case, which won’t necessarily be relevant to every client.

2. Far more important, however, is that we believe that a simple descriptor won’t help you enough.

If you’re not familiar with the GDPR/Privacy Use Case, knowing which (PII) assets fall within the scope of this regulation is essential, and different classes of assets have different levels


of protection. Simply stating that an object is PII, as a Yes/No, has limited value - it doesn’t tell you why it’s affected or how it should be treated. You need more context. If you add this context through a connection (in this case via Policy x Glossary relationships):

● You know which part(s) of the regulation will affect each object.. ● ..so you have less work to do later if parts (“Articles” in GDPR terms) of the regulation

change. ○ You’ll already know which policies are affected by changes. ○ And the relationships tell you which other Axon assets are affected.

● Using only a simple PII field will give you a much larger set of assets that need reviewed each time something changes.

6.2 How To Create Relationships With very limited exceptions, relationships are created in the Impact Tab of an object:

● Some relationships are created by dependency - when creating an Attribute, Axon requires the Data Set it is a member of.

● Some relationships to glossary are made on in the Summary tab (System/Interface facets), but these will eventually move to the Impact tab.

The Axon permissions that allow relationships to be created between two objects are usually only granted on one side of the relationship. For example, a Process stakeholder can state a link/dependency upon a System, but System editors cannot make such a relationship to a Process - they should not be burdened with creating that story in Axon, it is the individual process’s stakeholder that needs to tell that story. The Axon Community page has a document that describes the available connections between facets. Axon ships with a basic set of relationship types. We encourage users to create other relationship types to suit their governance program. Note that we plan to make these searchable in Unison Search which will increase their utility. Creating relationships through the Axon interface/Bulk Upload is straightforward. Most are one-step, data sets and attributes require further steps, as described below.

6.2.1 Standard Relationships For most facets, linking is a simple one-step process. In Edit mode:

● Select the Impact tab ● Select the appropriate sub-tab - when in Edit mode, all available facets have their

own sub-tab, in which the relationship can be created. ● Choose the appropriate relationship type from the dropdown, that best explains why

you are connecting the object.


6.2.2 Relating Assets to Data Sets & Attributes Many activities around the business consume or depend on data. When describing these activities in Axon it is normal to need to show where this data is sourced, so that the dependency is documented and understood, and so that e.g. lineage and quality can be assessed. Many facets therefore have the ability to create links to data. We are evolving how we achieve this in Axon 6.1, so this feature should be reviewed by users with that version, or higher. Linking to data requires a different approach from that described in the previous section. When a process stakeholder wants to declare a dependency on data used for their process, there may be different levels of knowledge of that data, and Axon can capture all of these:

1. I know the system we get the data from: relate to system 2. I know the subject area we use: relate to glossary object 3. I know exactly which data assets we use - specific Axon Data Sets / Attributes

The increasing impact of both internal and external regulations/policies on data usage demands that we help data users keep an awareness of all the rules that control how they use and store data. The primary mechanism in Axon for doing so is the Policy x Glossary relationship, which shows which classes of data are controlled by different policies, (many of which are interpretations of external regulations). This means that the link between data and glossary is essential for making relationships to data. All Versions of Axon Creating the relationship requires more than one step, and the results shown vary according to the different levels of knowledge referred to above. Because of this, many of the facets that link to data have a Data tab in object view that shows what is returned.

Action Data Tab Unison Search

Process x System All Data Sets and their Attributes in that system are reported.

All Data Sets and their Attributes in that system are reported.

Process x Glossary All data sets and attributes linked to that glossary object are reported.

All data sets and attributes linked to that glossary object are reported.

Process x System & Process x Glossary

Only the data sets and attributes that are linked to that glossary term in that system are reported

Only the data sets and attributes that are linked to that glossary term in that system are reported

Note that this relies on the Data Set and Attributes having glossary connections.

● Data Sets: System and Glossary are mandatory fields in the creation of the asset - obtain these values from Unison / the Data Set object


● Attributes: Making a relationship between attribute and glossary is an optional (but strongly recommended) activity. Attributes without this relationship cannot be linked to a process/policy/project.

a. The Attribute x Glossary relationship can be created using the Attribute bulk upload, or update existing templates and via the API. Attributes ingested from EDC may already have that association through preparatory activity in EDC.

b. See the later section on the Data Discovery Tool for a description of how Axon can assist managing attribute x glossary links.

Axon 6.1: Process x Data Set, Project x Data Set Feedback from customers told us that the apparent lack of a way to make a direct link to Data Sets/Attributes made many users to think that this could not be achieved. We therefore introduced the following to the Process and Project facets. All the pre-existing functionality described above remains valid. Additional direct relationships have been created in the Impact tabs for Process and Project that allow specific data sets and attributes to be related.

Action Data Tab Unison Search

Process x Data Set Not populated Objects not linked in Unison

Process x Attribute Not populated Objects not linked in Unison

Process x Data Set & Process x System & Process x (Data Set) Glossary

The Data Set and all its attributes are reported. Any Data Sets with same intersects are not reported.

The Data Set and all its attributes are reported. Any Data Sets with same intersects are not reported.

Process x Attribute & Process x System & Process x (Attribute) Glossary * Available in Axon 6.2.1

Only the specific attributes with a direct relationship are reported.

Only the specific attributes with a direct relationship are reported.

6.2.4 Relationships vs. Custom Fields In this section we have covered how we respond to questions about a specific ‘PII’ field, and we hope that we have demonstrated that you’ll get more longer term value from creating relationships. Clients often have a number of fields they would like to see described in Axon, but cannot see an obvious place for it.


Please talk to your implementation partner about this before you create custom fields, we’re happy to work with you on this. We’ve had a number of conversations that have stopped clients adding 50-100 custom fields - we were able to establish that all those needs were already addressed by existing functionality!

Activity 7: Data Quality Axon shows Data Quality (DQ) at two levels:

1. Standard DQ Rules, captured at the Glossary level - these are guidelines on expected measurement of attributes associated to that glossary term.

2. Local DQ Rules. Captured in the DQ facet, these are associated to individual attributes and measure different Types of DQ rule, such as Accuracy, Completeness etc. These create the Red/Amber/Green results seen in Unison and dashboards.

You can see both these rule types in Data Quality in Unison:

● Standard Rules have no associated attribute (Attribute Name column), nor scores ● Local Rules will have both an associated attribute and (if loaded) values in the Result

column. There is a wider discussion of DQ rules in a later chapter that deals with integration to the Informatica Data Quality (IDQ) tool, and automated rule creation.

7.1 Local DQ Rules Typically users are more interested in documenting Local DQ Rules when they start working with Axon - these help generate engaging content that informs and excites the community in the early days. By attaching DQ measurement scores to attributes, this information appears in map overlays and dashboards (see below) whenever those attributes are part of Unison Search results. Both pictures are for the same Unison Search.

Pic 1: Lineage map with DQ overlay


Pic 2: DQ facet dashboard. Unison shows that only 25 of 280 rules are relevant to the active search, dashboard shows results for only those 25.

Local Rules can represent quality information wherever it is measured - from conventional profiling and measurement systems to scripts run by analysts. There are two features of local DQ rules that are often misunderstood by users.

7.1.1 Dependency on Attribute in same Data Set: Add Item In edit mode, a Local rule has the option of adding more attributes from the same Axon data set to the rule (Add Item in the screenshot below). This feature is used to show that there is some dependency between the fields. A very common example is where e.g. a Start Date must be less than an End date. This feature should not be used to link unconnected attributes.

● Note that when using Axon’s search features to isolate attributes, Unison cannot split the scores between attributes, and will report the same score regardless of which attribute is searched for.

7.1.2 Dependency on Attribute in another Data Set: Measured Against The previous screenshot also shows the Measured Against feature. Similar to the above example, this is designed to demonstrate a dependency upon an attribute in another Data Set. The pop-up menu triggered is shown to the side. This feature is typically used for measuring Consistency type rules.


7.2 Standard DQ Rules Unless these are expressly of interest to initial Use Cases, description of Standard Rules tend to be something that users become interested in as their instance of Axon matures, and are key to some automation features. Standard rules are broadly similar to rules specified in Informatica Data Quality (IDQ) - they are descriptions of how applications of the glossary concept should be measured. The key difference is that Axon needs a sense of the rule in everyday language, not a set a technical statements. Standard rules can be associated to the IDQ rule that they represent. Standard rules are defined by the stakeholders of the Glossary object, and give recommendations to users on appropriate DQ measurements, for any attributes that are associated to that glossary object.

● Most users will tend to follow these recommendations in practice, but this allows individual data set stakeholders to make their own call about how they handle their own data. They may decide to subject their data to differing levels of measurement.

7.3 Glossary > Data Quality Tab The picture below shows a Glossary objects’ Data Quality tab. It shows two grids:

1. Standard DQ Rules - One has been described for Validity type rules. 2. Local DQ Rules (which has been filtered to show Validity rules only) - these are local

rules associated to attributes that have an attribute x glossary relationship with this glossary term.

3. Notice the first column in the local rule grid - the first three local rules have been aligned with the Standard rule, whereas the next three have not. This means they have been validated to be in line with recommendations.

4. Should another of these rules be deemed to be fully compliant with Standard Rule guidelines, stakeholders can make this attestation by pressing the + on the right hand


side, and following instructions to make the link. Completion of this action will result in the Standard Rule references replacing the yellow icon.

Activity 8: Workflow Workflows are prescribed steps that must be followed on a given order to achieve a particular goal. Many organisations use workflows to handle different requests and processes in the same dependable, repeatable and auditable way. Users can configure multiple workflows per facet. Some examples include:

● Definition approval. ● Request to amend definition. ● Query adverse Data Quality information. ● ..or simply handle questions from the community.

If it is important to ensure consistency, capture the thinking that went into decisions, use workflow to describe what needs to be done. Workflows are designed to assign tasks to the stakeholder roles available on each facet, e.g. the object’s Steward and Subject Matter Expert might work together in a series of steps before asking the object owner for approval to implement changes to an object. Other workflows may use different stakeholders, or the same ones in different ways. We talked in an earlier activity about the need to balance roles created with the workflow requirements when considering your stakeholder framework. Consult the user guide for guidance on constructing workflows. This section will cover the following:

1. Controlling any object in a facet - Default Workflows. 2. Workflows applicable to individual objects only - Custom Workflows. 3. How Workflows work with Change Requests. 4. Axon 6.1 - Subjecting objects to Mandatory approval.

8.1 Default Workflows vs Custom Workflows Some workflows need to be available for any object in a facet, others are so specific in purpose that they’ll only ever be run against one object. Axon allows both:

● Default Workflows: created in the Admin panel (by SuperAdmins), these are available to any object in that facet.

● Custom Workflows: created by users able to edit any one object, because a customer workflow is only visible to that object, and can only be run against that one object (all default workflows will still be available).

Default and Custom workflows differ only by who and where they are created - functionally, they are identical, both in the UI to design them, and execution.


8.2 Workflows & Change Requests Any logged in Axon user can visit an object and raise a Change Request (CR) - this option can be found in the Actions button. Up until Axon 6.1 all CRs had to be raised manually.

The Action button has a different label according to each user’s permission on the object.

When a CR is raised all of the objects’ stakeholders are notified it has been created. Any one of them can view the CR and decide which of the available workflows the CR should be run against. Note that:

1. The ‘Due By’ dates specified in the workflow start running when the workflow is started, not when the Change Request is raised.

2. Once a workflow has started running, any edits/changes to the underlying workflow will not be shown in the active Change Request. These changes will only apply to new requests.

8.3 Mandatory Workflow Approval Axon 6.1 introduced mandatory workflows, which can be applied to both newly created and edited objects. Ensure you have a good understanding of workflows and Change Requests before setting this up. How to do this is detailed in the next chapter.

Activity 9: Managing Stakeholders & Communications As you begin to start allocating roles there are a couple of useful features that are common early asks:

9.1 Introduction and Navigation Ensure that you have a compelling story ready on the need for governance, your expectations of the user’s likely interaction with Axon, and perhaps a simple guide/explanation of how it works. Many clients create an ‘Operation Manual’ that lays out basic instructions on basic navigation, tailoring the UI, and, if appropriate, how to create and manage content. If you create one, be sure to mention all the learning resources (especially the videos) available on the Axon Community Pages, and the User Guide available within Axon.


9.2 Bulk Acceptance of Roles When creating content and assigning stakeholder roles you may find that some key people end up with many notifications of roles to accept (which remain in the Notification Centre until accepted). With steady state production instances this is rarely a concern and the volume is easy to manage. However, as a first view of Axon this may seem quite daunting for the user in question. Axon allows users to bulk accept roles in their own account page, as shown in the picture below. Users need to select the roles in the grid before going to the Action menu.

9.3 Supporting New Users Remember when introducing new people and communities to governance to include all the messages that have guided you this far, as discussed earlier in Activity 1. Any guides that you have created (or Axon Community links) to steer users to some common expectations and activity will be useful - help navigating, searching and using maps. When starting to familiarise these people with Axon, remember that when a user looks at Axon on their own PC for the first time, they’ll see the same default facets that everyone else sees (however, SuperAdmins can control the default configuration, and change what Axon ships with). These won’t always be the right ones to engage that user. Make sure that you explain to new users that, using the Change Facets menu (the + sign to the right of the Roles facet), the facets visible in Unison can be tailored to each users’ needs/preferences - different users will have different needs and interests, so hiding less relevant content will help them engage with and understand Axon. Once the right facets are exposed, they can be dragged into different positions within the ribbon, and the layout saved.


The list of fields available in any Axon grid can also be controlled by the Choose Columns menu. All these settings are controlled by cookies, so user preferences will be remembered unless cookies are cleared.

9.3.1 Language Support We are adding support for multiple languages, which changes the names of the facets, labels and menus to one of the available languages. Note that this changes the active language for the user session only - it will default back to English the next time the user logs in, unless the default language for Axon is permanently changed. Please consult Informatica’s Knowledge Base/Axon Community pages for the latest advice on how to do this, as it may vary by Axon version. The guide for Axon 6.1 is here.

9.3.2 Walkthroughs We’ve added a couple of sections to the Help (?) menu in the top right hand corner of Axon. New users can look at walkthroughs to get a basic understanding of Axon via animated instructions. Axon 6.2 has a couple of walkthroughs for the following, and we’ll add more in future releases.:

1. Getting Started 2. How Unison Works

There’s also a link to the Axon Community, just remember that they’ll need there own Informatica Network account.

9.4 Basic Troubleshooting Whilst users rarely experience any of these issues, it might be useful for all Admins to be aware of the following scenarios in order to know the appropriate remedial action to take:


https://kb.informatica.com/howto/6/Pages/23/581767.aspx

Issue Action

UI tells a user that a Bulk Upload has failed. User can download explanatory report from the upload menu, or from their own People page.

Objects in a successful Bulk Upload fail to appear in Unison.

Check the status of the Map Data Updater Process in the Admin Dashboard (see below).

User unable to edit an object because it is ‘locked’.

1. The lock message will say who has locked it.

2. That user can unlock from the object, or Admin users can unlock in the Admin Panel > Operational Management menu

Other unexpected action. Admins can: 1. Check the Admin Dashboard 2. If clear (all lights green), try clearing

the cache and cookies, then repeat the action.

3. Consult your implementation partner or raise a ticket with GCS.

The Admin Dashboard has a number of Status lights for different parts of Axon.

Activity 10: Creating Lineage Another common requirement is to see how a collection of data points interact with each other, and what happens to them as they move between systems, tables, spreadsheets etc - are they copied, transformed, aggregated? A core feature of Axon is to deliver this understanding and clarity. In this section we’ll talk about the basics of lineage.

● A later section on integrations will show how this process can be made easier to both discover and ingest the flows.


Before we discuss how to bring this all together some comments on individual pieces of lineage.

Interfaces vs. Attribute Lineage (or Dotted Lines vs. Solid Lines)

Axon lineage maps contain two different line types.

● Dotted = Interface ○ Dotted lines indicate that an Interface has been created between two objects ○ It does tells us that two systems ‘talk’ to each other, and that information is

exchanged between two systems, but doesn’t tell us the detail. ● Solid = Lineage

○ Solid lines tell us that we have captured some details about each individual flow of data - each individual attribute that moves (we often call them ‘hops’) between two tables/spreadsheets etc. At each hop, the attribute could undergo treatments such as aggregation, transformation etc, so each hop has to be described individually.

Also note the arrows - lineage and interfaces are one-directional - Orion (lineage) and Adaptiv (Interface) are feeding information to CMD, and in turn CMD is supplying information to DWH and MCD AMS. If there was any flows in the opposite direction there would be arrow heads at both ends of the line. Any line denotes that one or more flows exist - there could be many. Additionally, as we’ll show below, solid lines may be sitting on top of a dotted line.

Interfaces vs. Lineage: when to use Interfaces can serve two purposes

● The primary use is to describe how data moves between two systems. ○ Interfaces can be related to specific Processes to show they support a

particular task. ○ They can also be associated to attribute x attribute transfers of data, to show

what is transferred. Here, additional information such as file format, technology of transfer can be added.

● They can also be used to scope out high level landscapes and focus investigations.


○ It can give you a feel for what moves at a high level, through the Interface x Glossary relationship.

○ We call this scaffolding - a central team maps out systems of interest and the known interfaces between them to give others a feel for the boundaries of the initial data collection exercise.

Client usage of interfaces varies

● Especially where the transfer of data is IT supported, and happens automatically, multiple interfaces may be created between the same two systems, each supporting one specific purpose/process.

● Alternatively you may choose to represent interfaces with fewer interfaces, as the interface may simply show that two systems can exchange data automatically.

● The typing of the Interface also allows you to represent e.g. manual transfers of data. Consider the picture below - the CMD system is a key source of data for many other systems - lots of solid lines tell us that lineage has been described, and can be explored (e.g. via the linking attributes overlay).

However, although we know what data is flowing around, we don’t necessarily know how this is facilitated. If we change the filters on the map above to exclude lineage and only show interfaces, we find the map above becomes the map below;

This demonstrates how we use attribute linking to show what data flows around the business, and interfaces to show how this happens. These last two maps show us that, in this case, we know a lot more about what data is flowing than how it gets there!


When describing data lineage, either when creating or in subsequent edits, users can assign each individual line of lineage to a given interface. The screenshot below shows a story of two attributes (Revenue and Cost) from different source tables (in the same System A) coming together in a third table (found in System B) to calculate Profit. The transfer of data is supported by the same interface.

● The picture shows the Attribute Bulk Upload file, with the interface selection fields highlighted.


Chapter 4 - Production Considerations Everything discussed in the previous chapter about initial population of Axon remains relevant to a new Production instance, as you’ll probably expand Axon content using a mixture of new Use Cases and automation. Remember the 5 Principles of an Axon Implementation:

1. Engagement & Adoption above all else. 2. Think big, start small. 3. Be guided by practical usage. 4. Breadth over depth. 5. Do not model.

However, the move to production has additional considerations. These will be discussed here. Integrations with other products is a large topic, and has a chapter of its own following this.

Structuring & Staging Environments You licence agreement allows you to provision as many instances as are required to satisfy your SDLC requirements, as long as they are used for the same purpose. Unless the SDLC requires more than two, start there. Suggested usage:

1. UAT / Sandbox Instance a. Testing major releases and bug fixes before committing new code to

Production. Often also used for testing content for production. b. Probably has Single Sign On Enabled c. Typically does NOT have email enabled - Some clients have also set up email

on multiple instances. i. See earlier comments on multiple instances sending emails.

d. Probably has integrations for testing purposes. 2. Production Instance

a. The instance exposed to the whole community. b. Typically has Single Sign On enabled. c. Typically has email enabled.

i. Axon can send users regularly scheduled emails about the activities they are involved in - each user controls their own settings.

d. Integrated with other systems, where applicable. Remember that, as we told you earlier, Axon doesn’t support staging content, i.e. manually testing content in one instance, and if we’re satisfied with it, moving just that part of the UAT content into Production.


In other words, feel free to test ideas in UAT, but do not spend a long time adding and managing it there, because you will have to recreate it in Production. Whether it is in the UAT or Production instance, we’ve seen clients spend too much time preparing content without informing/exposing it to the community. The typical reason for this is that the team is trying to achieve some measure of perfection. The problem is that, aside from the risk that the content is no longer up to date, that they are shielding content from a community that, given the chance, will both criticise and help improve it. Perfection is too high a standard, and user engagement is far more important. Let the community see it, engage with, and talk about it. These interactions educate everyone involved. If you want to test ideas in UAT, using up-to-date content, schedule a regular backup of Production back to UAT. Backups will take all content, configuration and workflows with it.

Roles & Permissions (again) In the previous chapter we observed that, in the early stages of an Axon implementation, clients often take advantage of the spare capacity in their licence allocation to grant all the initial project team the Admin profile. This can help make creating and correcting initial loads easier and quicker, and let the initial team get experience across multiple facets. As you roll out your governance program and bring in more stakeholders, you’ll probably have to change this arrangement in order to reallocate licences to the right people for steady state governance. It may be that since this team are now expert Axon users, that they might retain the profile, to help new users with day to day problem solving (that’s what the Admin profile is really for). However, remember that the permissions engine assumes most Axon users are WebUsers, so that their ability to change content is limited by the stakeholder roles they have been assigned.

Admin/SuperAdmin Responsibilities in Production Most of these activities have already been discussed in detail elsewhere in the Playbook, but we’ve listed them here in one place as a reminder. In this list we do not discriminate between what can be functionally achieved by SuperAdmin/Admin users, as not everything listed here is a product feature. Even though many of the features may only be applied by SuperAdmins, it is useful for your Admin community to be aware of them:

1. General experts on governance aims and can explain and enthuse the community. ○ Can understand and apply the 5 Must Dos of Data Governance ○ Can apply the 5 Implementation Principles ○ Explain how to approach using Axon facets to represent Use Cases, in a way

that most users will understand. 2. General experts on product features, and how to use Axon.

○ Help less experienced users get started and explain how/why content is structured, help them overcome error messages etc.


○ Know the easiest way to achieve different tasks and make navigation round Axon easy for everyone - if you look like a Pro, it instills confidence in others.

3. They might also maintain (or sponsor) an ops manual/guide, written in the language of your organisation, for users on how and why to get achieve different task in Axon.

4. Identify users for training courses supplied by Informatica University. 5. Access to extra tools to help address issues quickly:

○ Edit/New access to all objects to fix small issues. ○ Unison > Bulk Update available. ○ Access to the Admin Panel

6. Know where to go for help: ○ Supply Axon logs from Admin panel when requested by Informatica Global

Customer Support. ○ Raise awareness of the Axon Community Page amongst users.

7. Maintain core Axon features: ○ Create Default workflows. ○ Manage the configuration e.g.

■ Dropdown Configuration. ■ Roles & Permissions, licence usage

○ Awareness/monitoring of Map Threshold Values. ■ This is a new feature, so we’ve explained this just below.

○ Manage Facets Show to users. ■ The Application Settings > Display Settings menu lets you control

which facets appear, and in which order, for new users (note that these settings are overridden by individual users’ local settings).

■ All facets will still show for all users if they select them. We have occasionally been asked to hide some facets completely to stop their use. However, this runs the risk that the community might design solutions for new challenges using what they can see, rather than what they could use.

○ Manage the Segmentation facets. As mentioned in Chapter 2, these might be best managed by the central team, both for control and because it may be difficult to find an obvious owner.

8. Manage use of elective Axon features. Note that whilst we’d expect decision on the use of these features to be made by the ‘business’ team controlling Axon, activating some of these features requires the assistance of your Linux administrator to restart Axon after you have made these changes. The UI will tell you when this is needed.

○ Customise the homepage welcome message using the Static Page Editor (requires knowledge of HTML).

○ Activate Dashboards on Axon’s Home Page. ○ Assess requests for Custom Fields.

■ ..and adding those deemed suitable. ○ Manage fuzzy search - switch on/off. ○ Prepare Axon for, and then activate, Default (mandatory) Change Requests. ○ Configure Glossary Rollup settings.


○ The duration of content shown in object History tabs is also configurable. The default is 6 months, this can be adjusted in the Admin Panel > System Settings > Environment menu.

Map Threshold Values Axon facilitates different communities coming together to describe things that are important to them, and connect these to objects owned by others, so that we build up a view of the complex interactions in the firm. This means that by the time you have established your governance program and added even a few Use Cases worth of content into Axon, there will be hundreds or thousands of objects in different facets. You’ll also have got used to the need to use Unison Search to isolate different areas of interest. Often, you’ll draw an Insight Map of the results to explore them further. Axon’s Insight maps are very powerful, but there is a limit to the value they can offer if the information is not consumable. Our intention with Insight Maps is that they are large enough to represent a given situation, but small enough to be easy to work with.

● One issue that can present itself (especially with new users), is calling an Insight map in Unison without first performing a search.

● Where your instance has a lot of content, this might result in a long wait for the map to render, only for the user to see that it is far too big to be useful.

● Such experiences don’t leave a good impression, nor do they drive engagement and adoption, so we were asked to help prevent this happening. Axon 6.1.1. Introduced the solution.

Axon now has a set of configuration controls to limit how big a map can be before a user is prompted to refine the search. There is a separate limit for each of three facets: System, Data Set and Attributes.

● When an Insight Map is called for, Axon compares the Unison count of objects that are in focus for these three facets (125 systems, 109 data sets and 465 attributes) against the limits.

○ If any one count exceeds the permitted limits the map rendering is cancelled, and the user is shown a message asking them to refine their search.

● The settings are controlled by SuperAdmin users in the Admin Panel ○ > Customize Configure > System Settings > Environment menu ○ The picture below shows the three Map _ Threshold settings.


○ The default values should not be viewed as a technical limitation in the product, and can be increased or decreased - the question to ask is; “what would be a reasonable number for a user to need to see?”, and then add a suitable margin for error.

Monitoring & Measuring DG programs are notoriously difficult to measure in objective terms - it’s difficult to count up the number of times effective DG stopped ineffective changes being made, or that caught other ‘gotchas’ before they caused undesirable outcomes. Other programs are justified on the ability to mitigate the risk of regulatory fines. Some simple examples of measurement that clients have included in measurement efforts revolve around simple counts - searches that monitor some aspect of the projects you are running, or the overall effect on the Axon instance and community of users. Once created, searches can be saved, even shared with other users, so that the results are easily rerun. A collection of counts can be recorded on a regular basis to monitor community engagement. Such counts include:

● Objects with one/more/specific role type stakeholders. ○ Or, perhaps more importantly, objects currently without any stakeholders.

● Roles - accepted/awaiting acceptance. ● Attributes with/out glossary relationships. ● Attributes or Data Sets subject to DQ measurement.

Custom dashboards can also be constructed and shared with the community to give them something to follow. How to do create these features is shown later in this chapter.

Advanced Features for Maturing Users Axon includes some features that are unlikely to be relevant for new users of the tool. However, as the DG initiative settles down into steady state operation, the relevance and value of these features often becomes apparent. This tends to start happening anywhere from 3-9 months into the project, as these features benefit from larger volumes of content.


1. The Data Discovery Tool The Data Discovery Tool (DDT) can be found in the Data tab of any glossary object. The goal of the DDT is to find Axon attributes that should be associated to that glossary term - examples of the glossary concept being used in data sets. It can be used to create pattern searches that look across all Axon attributes. The rules are stored at object level, and can be rerun at any time.

● DDT vs EDC: As you’ll see in Chapter 5, if you have integrated Axon with the Informatica Enterprise Data Catalog (EDC), the Axon glossary can be exported to EDC and used in conjunction with EDC domain discovery rules to ensure that EDC Fields are associated to the right glossary concepts. If you’ve done this, any attributes imported into Axon will retain that relationship. However, not all data assets are discoverable by EDC, so even if you have EDC, the DDT still has a place.

We’ve mentioned a few times in this document that, whilst optional, this relationship between Glossary and Attribute allows users to see real examples of conceptual glossary objects in action around the business. We do not mandate the relationship because that can cause practical difficulties in early data loads (and not every attribute has/needs an association). However, as your Axon instance becomes better populated and more relied upon, the need for this link between attribute and glossary often becomes clearer.

2. Mandatory Change Request / Approval Workflows Axon 6.1 introduced the ability to ensure that new/edited objects in selected facets are subjected to appropriate approvals automatically. Axon 6.1 allowed this for manually created/edited objects only, and Axon 6.2 has added bulk upload content to this. Out of the box, this feature is disabled, and we wouldn’t recommend activating it until you have had some practice raising and running CRs manually. The available functionality in Axon 6.2 is as follows:

Available in facets: Triggered when...

● Glossary ● Process ● System ● Data Sets

1. A new object is manually created by a user with the WebUser profile.

2. In Axon 6.2 object bulk uploaded also trigger the feature.

3. Edits are made to fields on the object’s Summary tab only.

The feature allows an extra level of control over the activities undertaken by users with the user account profile of WebUser. Edits made by users with an Admin profile will not trigger change requests.


Actions to Configure All setup and configuration must be completed by a SuperAdmin user:

1. First of all you need to satisfy yourself that subjecting activity to mandatory approval will be a positive addition to your program. If you are still in the initial stages of populating Axon, and are regularly adding large uploads of content, triggering a Change Request for every object might generate a lot of approval activities:

a. You’ll need to assess how this will be perceived - will it defeat engagement and adoption?

b. Consider activating the feature later, when you have reached some kind of steady state governance.

2. Workflows will only successfully trigger if the object has all required stakeholders

available. To help ensure this happens, Axon will inherit certain stakeholders from parent objects (logic described later). You therefore need to review if Top Level objects have stakeholders that lower level objects can inherit.

3. Before enabling this feature these steps must be followed for each facet: a. Ensure that you have created (and tested) workflows to support the feature: b. Note that workflow End Events (thicker circles) have had extra Fields added,

to configure the Status/Lifecycle states at completion of the workflow. i. Multiple end events are permissible in a workflow, each can have its

own, separate values. c. Each should be configured to show what Axon Status and Lifecycle values

are displayed on the objects when the workflow completes.

4. Once you have workflows ready, select the Default Change Requests menu. a. Select the workflow to be used for creating and editing objects - you can use

the same workflow for both if you wish. b. Enable Mandatory Approval, using the slider, shown below.

5. After this, any and all changes to Summary Tab fields will be subject to automatically

triggered Change Requests, as long as Axon can automatically inherit the appropriate stakeholders to execute the workflow, as we’ll explain below.


6. Other settings are available, which set the default states of the objects when the user is creating the object. These are the values that are shown on the object until completion of the workflow, when the values selected in the End Events, mentioned above, are triggered.

7. One important feature of mandatory approval is that all stakeholders required for the chosen workflows must be available on the object in order to successfully trigger the workflow (remember that if you try to initiate a standard workflow, Axon only lets you if these roles are already present on the object). In order to make this easier to achieve, Axon will inherit these roles from a parent object, as long as you ensure that one of the objects in the hierarchy above Axon has the specified roles present.

Executing Mandatory Approval ● The new object must be created manually by a user with the WebUser profile.

○ We acknowledge that Admin users may have a role in day to day activities, and we may expand functionality to include them in mandatory approval.

● When the WebUser has completed the necessary information, they initiate the approval workflow by pressing Save & Submit.

● As long as Axon has been able to inherit the required stakeholders, the workflow will be automatically triggered - users are informed of the success of this when the Action button option Save and Submit is selected.

● Workflow execution is similar to standard workflows. However, whilst the workflow is active the object will show that it is under mandatory review to stakeholders only.

● Upon completion of the workflow, the Change Request > Summary > Complete

button must be pressed to close the workflow before the final states specified in the End Event are displayed to the community.


3. Rollup Many Axon facets, e.g. Glossary, are hierarchical. This allows parent/child relationships to be created that help us build up a representation of assets in a logical order. As you populate these local hierarchies with information, users sometimes wish to see the summation of these relationships at the parent level, i.e. see all relationships against multiple child objects in one view. You probably know already that this is easily done in Unison (search for an object and its children, and see all the related objects in the search results). This can also be achieved in object view, as is explained below. This explanation is split into two sections - creating rollup manually, and configuring Axon to perform rollup automatically (currently available in the Glossary facet only).

Manual Rollup Axon has always had the ability to show another view of these relationships, from within an object, rather than in Unison: In an object the Actions button for the facets listed below will show the ability to create a Rollup view:

Rollup Enabled/ Disabled. Note the message beside ‘Glossary’

Actions Menu to activate / deactivate (note the different labels on the Actions button, reflecting different users with different permissions)


Viewing a Parent object’s Impact tab. Rolled-up relationships from children shown in orange font.

Caveat: The parent object will only show rollup of children if the parent object has one or more impact associations - this is a known issue, and will be addressed in a future release

Controlling Rollup - Manual vs Automatic Control Configuring automatic rollup for glossary objects was showcased in Axon 5.4 and was set to automatic configuration by default. From Axon 6.0 onwards, automatic configuration is optional, and is set to inactive for new installs. There are three steps to set it up:

1. The feature uses the Glossary Type field to control what is rolled up. a. Make a decision about the glossary typings that should be rolled up. b. Remember what we said about the typing field in Chapter 3 above - if it

doesn’t mean anything to you, don’t start using it for the sake of it. It just means that all glossary objects have the same type, and auto-rollup can still be configured.

2. In the Admin panel a SuperAdmin user must configure the typings to be auto rolled up - Customise & Configure > Configure Options > Glossary Rollup Settings

3. Once configured and saved, there are some server level changes that must be made - there is a link in the screen that directs you to the user guide for details.

Current functionality for Rollup allows the following

Axon Rollup Summary - from Axon 6.0 onwards

Facet Impact Tab Data Tab (Data Sets & Attributes)

Auto Configurable

Glossary Yes Yes Yes

Process Yes No No

Policy Yes No No

Regulation Yes No No

Other facets and rollup information will be added in future releases.


4. Scorecards Both the Data Set and Glossary facets have a feature on the Summary tab that shows a scorecard for the object. The scorecard is a quick summary of all the information held in the objects’ tabs.

5. Semantic Relationships (Glossary x Glossary) One glossary feature that tends to become of interest to users as the glossary matures is the fact that many concepts are themselves reliant upon other concepts to explain both their derivation, and how apparently similar terms might relate to each other. These can be described in Axon using Glossary x Glossary relationships. Once these have been created via bulk upload or manually, the Relationships tab of an object will show these semantic links. A common example of this is where multiple revenue measures exist in the same company, as there is frequently uncertainty as to what should be used when. Each measure is worthy needs defined separately, so that users can understand them in their own right, but the linking shows how they rely upon/contribute to other metrics/KPIs/concepts.

Where relationships have been created these are also show by default on the Relationships > Hierarchy page, but can be controlled using the Show Relationships checkbox above the grid.


6. Saving and Sharing Searches If you have spent any time on Axon already, you will have noticed that it is easy to create searches on single or multiple object, and create conditional searches, such as this one:

Note that at the bottom right of the search menu you can see the option to save a search. There are different reasons for doing this:

● Makes it easy to re-run searches regularly. ● Saved searches can be shared with other Axon users. ● Saved searches are at the core of customised dashboards.

Managing Saved Searches Save a Search: With the search you want to save active, save it using the menu shown. Take the time to give it a good description, so that you know what each search does.

Note that the Clear button shown in the picture only shows when there is an active Unison search to clear - when no search is active this shows a list of your saved searches.

To manage and share your saved searches clear any active search and select Manage Searches from the My Searches menu.

The picture below shows the Manage Searches menu.


In this menu you can:

1. In Edit mode: a. Update the name/description of a search. b. Delete a search you have created.

2. In View Mode: a. Searches you created and those shared by others are shown in different tabs. b. Run the search by pressing the icon in the last column. This will take you

back to Unison c. Share the search.

i. Highlight the search(es) to share by clicking on the name/description. ii. In the Edit > Dropdown > Share Search. iii. Start typing the first name and select from the list. iv. Add as many names as you wish. v. When you press Share each user receives a notification, if email has

been configured on the instance.

7. Dashboards

Pre-Configured Dashboards As powerful and flexible as Axon is, the maps and dashboards have always been the most popular part of the tool. As the adage says, a picture is worth a thousand words. Axon has always used dashboards to display information - they exist in Unison (standard view is List view, but Dashboard can be selected). These dashboards are dynamic - they update automatically according to the active Unison Search. Many facets also have a collection of dashboards available at the object level, selected using the icon just to the left of the Summary tab header (see below). Different dashboards can be selected using the dropdown at the top right of the page. Dashboards within an object have a static focus on that object.


Unison and Object dashboards are not user configurable.

Custom Dashboards Axon 6.1 introduced user configurable dashboards to Axon, and these have been further extended in Axon 6.2. The following discussion outlines the functionality as at 6.2. Some of the functionality described may not be available to Axon 6.1 users. We’ve explained custom dashboards here in the Production chapter because we think that’s when they’ll start to become relevant to most users. However, you may choose to create them earlier, if it helps drive engagement and adoption. As with everything in governance, don’t do too much too soon - it’s easy to overload new users with too much information. One dashboard with a few well chosen widgets will be more powerful than multiple dashboards. Key Concepts:

● Custom Dashboards are disabled by default ● If enabled by a SuperAdmin user, they become available to all users to build their

own dashboards. They are controlled by the Actions button that appears at the top right of the homepage (see below).

● Dashboards work by allowing users to create a collection of widgets based mostly on Saved Searches.

○ Saved Searches were covered in the previous section, above. ● If enabled, Dashboards are available on the Axon homepage. Each user can elect

○ To create a series of dashboards for different use cases, each holding a series of individual widgets.

○ To make one of these dashboards their default home page. ○ To share their dashboards with other users.

■ Note that you have to share the searches with other users as well, otherwise the dashboard will be blank.


Dashboard & Widget Creation

1. Before you can start creating dashboards, you’ll need to save some searches to be used as widgets.

2. Once you’ve done this, either create a new Dashboard using the Homepage > Actions button, or add a new widgets to an existing dashboard.

3. The picture below shows the different types of widgets that can be created. Note that first is a Text widget, all others were created from Saved Searches.

a. Widgets can be moved around the dashboard. b. Options to share dashboards a select default are available in the Actions

button.

There are a few things that you cannot do with dashboards, but we are working on this for future releases, e.g:


● Cannot edit a widget after it is created. Practice makes perfect, some widgets might take a few attempts to get right.

● The user experience for moving widgets around a dashboard will be improved. ● Limited control over colours used - where you create a widget based on e.g. DQ or

Project status, you won’t be able to give them the appropriate Red/Amber/Green colours. Note however, that it is possible to describe DQ using the expected Red/Amber/Green colours.

New Release News The best way to get information on new releases is via Informatica’s SupportFlash newsletter, which is emailed to you every month. Subscribe to this via the Informatica Network > Support Documents > SupportFlash Archive. You’ll also get clues from the The Axon Community page, as the release notes and other documentation are available there soon after release.


Chapter 5 - Making Integrations Work This chapter is all about the ever-increasing options you’ll have through automation and integrations with other products. Before making a plan to integrate Axon with another product, it’s crucial to understand why you are doing it, and what you’ll get for it. The tools that you’ll link to Axon are typically quite technical in nature, but we do not necessarily want/need to bring all that complexity into Axon. Axon currently has specific integrations with three Informatica products, which are explained in this chapter. There are no specific integrations with any other products, from Informatica or other companies. However, Axon has an extensive set of RESTful APIs, which (since Axon 6.0) support both read and write commands.

Integrations with Informatica Products Out of the box, Axon integrates with three Informatica products to support various data governance scenarios:

1. Enterprise Data Catalog (EDC) - provides a machine learning-based discovery engine to scan and catalog data assets across the enterprise—across cloud and on-premise, and big data anywhere. EDC integrates with Axon to automate processes for acquiring data assets through scanning and discovery, assess their criticality to the data governance program, and onboarding them into Axon so they can be brought under governance.

2. Data Quality (IDQ) - empowers your company to take a holistic approach to managing data quality across the enterprise. The software transforms your data quality processes to be a collaborative effort between business users and IT. IDQ integrates with Axon to automate the measurement of local data quality rules, which can be measured directly against the physical store corresponding to the Axon System/Data Set, through IDQ Rule-based Profiling and Scorecarding.

3. Secure@Source - discover and remediate sensitive and critical data risk across your organization. It leverages artificial intelligence (AI) and machine learning to deliver actionable data discovery and classification, risk scoring, behavioral analytics, and automated protection in a single solution. Secure@Source integrates with Axon to measure the state of data protection and risk for sensitive data types, such as Personally Identifiable Information, and report that back to Axon stakeholders for the Data, Systems that house that information, and for the Policies that determine the organization’s data protection policy framework.


Strategies for using these will be discussed in this chapter. These products facilitate important contributions to the governance story in your firm - no one product gives you a holistic view of governance activities, but pulling together aspects of all this activity does get that view. Whilst some business users might have easy access to these tools, this tends not to be extensive enough to facilitate enterprise governance, never mind that access does not mean they necessarily understand what they see - many in the analytics area would easily understand EDC content, but that still isn’t wide enough coverage for enterprise governance. Axon is the lens through which we give the whole community a view of all the activity undertaken, wherever it happens, in a way that should be understandable by all members of that community. We will primarily talk about the Axon facing elements of these products and integrations here - setting up the connections will not be covered, but there are technical release notes, KB and H2L articles on Informatica website, (also accessible via the Axon Community page) that can assist. Lastly be aware that your ability to leverage all the features described in this section will be determined by the maturity of your governance activities, and the products available to you.

1. Informatica Enterprise Data Catalog (EDC) A commonly asked question is why a client might need both Axon and EDC. The answer is relatively simple - cataloging in itself isn’t governance:

● Cataloging is largely a technical exercise to discover and describe physical data wherever it can be found. It provides insights such as classification, profiling and uncovering technical lineage etc.

○ Organisations use all kinds of data every day, not all of it physical. Axon also relies on conceptual data sets and lineage to fully explain business activities, and this type of content cannot be found in a technical catalog.

● Once we have this large inventory, we want to leverage added insight provided by the business - they can express the context for the data they consume - why and how they use it. To this however, you’ll need to move the relevant content to Axon and make those contextual relationships.

● Other views, such as Privacy concerns and Data Quality analysis add to this combined view to give a holistic governance view. Axon is the lens by which we give the whole community a view of all this activity, in a way that should be understandable by all members of that community.

Axon EDC

Axon should be used to describe key data elements (KDEs), as defined by either:

1. The organisation’s data governance practice, or

2. By data used in the business, as

EDC should be an inventory all available/scannable assets, wherever this is possible - cloud, big data, databases, file shares, BI tools etc.


described by the business community

Axon should not be used to inventorise every piece of data, simply because it has been discovered. Axon should be populated with more consideration, in line with what the business say they need to run key day to day activities. This of course means that Axon will have less content than EDC. Much of this content will be a subset EDC, hence the integration to make it easy to pass it across. However, in order to represent things in an intuitive way to business users, the way such assets are represented in Axon typically has less technical information. In fact, we often say that if Axon has ingested more than 10% of the content found in EDC someone is probably working too hard! This, of course, is a broad generalisation, and doesn’t hold for every use case. Axon should describe data that the business can access, it should not need to show pre-production tables.

EDC has a broad inventory of interfaces for connecting to, scanning and inventorising the data content of these resources. Once installed and configured, EDC should very quickly accumulate a lot of content, irrespective of the value/usage in any one community within the organisation. By searching EDC for key concepts we’ll learn where they exist in the landscape - that may be needed to inform Axon users where the content they need can be found. However, just because something is discovered, doesn’t mean it is used by/ relevant to business users, so does not automatically need to be represented in Axon. Cataloging will typically discover pre-production/staging tables, essential in the SDLC. These have no relevance to the business, who typically only need/use the production/final stage data.

The EDC Interface in Axon Has Evolved Before we go any further, it's worth mentioning that how and where you interact with EDC has moved on in our latest release. Users of Axon 6.1 and earlier will be used to accessing EDC content via the toolbar:

We’ve changed this design in Axon 6.2, and Fields are now shown as a facet, which of course means that the relationships Attributes and linked EDC Fields is now searchable. Axon 6.1 also introduced bulk uploads for System x Resource and Attribute x Field to make bulk linking easier and quicker to achieve.


The familiar UI triggered by the Enterprise Catalog link is now found in the Create Menu > Manage Catalog Links

Manage Catalog Links Interface The list of Resources and Fields shown in this UI is automatically refreshed from EDC each time a user accesses the Manage Catalog Links menu. This means that the most recent information EDC information is available in the UI. How often scans are run/rerun in EDC is controlled by its administrators. Available assets are held in two menus:

1. Resources (Axon Systems) ○ List of relational and file resources that have been discovered by EDC

2. Fields (Axon Attributes) ○ Fields are columns in discovered Tables ○ An EDC Table is a more conventional form of technical table, which conforms

to a subset of the uses described above for an Axon Data Set. As the picture below shows, if a Resource/Field has already been linked to an Axon object, this is shown in the table.

Note that:

● The Search filters can be used to find objects of interest - in the Resource menu the Keyword menu and Resource Type can be used in conjunction to find assets of interest, in just the same way as the main Unison Search tool.

○ Fuzzy Search, if enabled, will not affect searches in this menu.


Ingesting Content from EDC - Overview Recent versions of Axon have steadily increased the capabilities to automate and discover:

1. Manual Onboarding. 2. Intelligent Glossary Association. 3. Automated Onboarding.

We’ll give an overview of these three options. Please take the time to review and understand the pros and cons of each option before committing to a path:

● Manual onboarding is slower, but more precise. ● Intelligent Glossary Association is valid activity in its own right, but is also an

essential preparatory step for automated onboarding. ● Automated onboarding allows speed and volume, but is less precise.

○ As we’ll see, the physical implementation of an asset in EDC might not reflect how business users interact with those assets

○ As a result, curating auto-onboarded assets is key to success. ● Remember to be discriminatory in the content you select for inclusion in Axon. We

compared the two products earlier. EDC is the right place to store and report on all available metadata. Axon is only for the assets identified as key to business activity.

A. Manual Onboarding Resources Manual Onboarding is managed via the Manage Catalog Links UI introduced above. If we wish to e.g. select an EDC Resource displayed to ingest into Axon, do the following:

1. Select the item (avoid hyperlinks when you do this), and then 2. Either Select the Search dropdown or just right click on the highlighted row 3. Select Manage Linking.

This will trigger a menu that allows you to either:

1. Associate the Resource to an established Axon object 2. Clicking the Create button will trigger the Axon manual create screen, and you can fill

in the usual fields to create a new system. a. Upon successful creation of the new system object the EDC resource and the

Axon System will automatically be linked


Fields The functionality for Fields is very similar to Resources, although there are additional considerations:

● Many Fields (Attributes) in a Table (Data Set) have little relevance to the business: ○ They might be e.g. boolean flags used by the IT team to support logic, extra

(unnamed) fields to support possible future needs, or just aren’t ever populated.

○ Fields such as these are typically unsuitable for Axon, because they do not help business understanding.

○ Hyperlinks into EDC can help you understand these fields to make a call on their suitability

The Fields Menu has the following columns:

Name Name of the Field (and potential Axon attribute)

Type Type of source field (csv column, JSON field, XML Field etc)

Parent Name The Table it was found in (potential Axon Data Set). Note the advisory message in the screenshot.

Resource Name Resource Name (potential Axon System)

Status Three options: Reported: Found, not associated Associated: Already associated to an Axon asset Ignored: Items auto-onboarded that are rejected during curation. They will not be offered again for curation when the next daily scan runs.


Glossary This was split between Linked and Inferred Glossary in earlier versions, but is now merged into one column. If the row shows a % value, it has been auto discovered, and is awaiting curation. If ticked, it has been curated.

Multiple Fields can be associated to the same Axon data set in the same step. To select multiple Fields either construct a search that returns only what you need or simply click on each row from the grid (again, avoid clicking hyperlinks when you do this), by holding down the Control key as you select each row, and select Manage Links.

As with Resources, users can choose to associate them to an existing Axon Data Set, or create a new object to hold them

● Remember that you’ll be asked to enter an Axon glossary term (that best describes the business activity the Data Set supports)

You can then finalise the names you wish to appear in the Axon Data Set - EDC suggestions can be overwritten, e.g. if more business friendly names can be used.


B. Intelligent Glossary Association We talked extensively in previous chapters about the value and need for an enterprise glossary that covers the whole organisation. The place to create and manage that glossary is in Axon. However, one of the applications of a maturing glossary is the ability to utilise it within EDC to make associations to the physical assets discovered and thereby create the understanding of what those tables and fields support. All that’s needed from Axon is a good working glossary, that probably follows the best practice outlined in Chapter 3. After that, the setup for intelligent glossary association is all done by EDC admins. How and what they do is quite technical in nature, and we have “H2L” articles to understand this. The association leverages Machine Learning and Artificial Intelligence:

1. Using Data Domains, Similarity Discovery & Data Domain propagation 2. Business Term Association, via fuzzy matching of name similarity.

Axon Glossary > EDC Domain Linking the Axon UI Axon 6.2 allows for Glossary objects to be associated to Domain Discovery Rules from the Axon UI, which was previously only possible from within EDC. In View mode, the results are shown in different tabs for Data Sets and Attributes.

Note that when linking in this way:

● Composite Domains cannot be selected.


● Axon will only offer a list of Domain Discovery Rules that are not already associated to other Glossary objects.

C. Automatic Onboarding As we said earlier, manual onboarding might not be appropriate for everyone’s needs. We observed earlier that Axon typically ends up describing about 5-10% of the discovered assets in EDC. If that’s true for your firm, then if you have a million assets (Resources and Fields) in EDC, you still have about 100,000 assets for Axon. That’s clearly too much for manual ingestion. If you’ve read Chapter 3, you know we don’t recommend that start ingesting such large volumes (Think Big, Start Small), but as your confidence and experience with Axon grows, so will the expectation to move faster. That’s when you might want to explore using Automated Onboarding feature. Automatic Onboarding has the ability to bring scale to Axon onboarding on physical assets. This activity will be reliant upon a good Axon glossary, so is probably not something for new users to jump into. As we describe the feature below, remember that nothing has changed in terms of how you should approach Axon - we still only want to onboard assets that have business relevance. However, as EDC only knows the physical form, you’ll often onboard content in this form, and then make some manual adjustments whilst Curating (you’ll still be saving a lot of time).

Key Considerations

● Automatic Onboarding requires a reasonably mature glossary, and that Intelligent Glossary Association has been implemented before the feature can be used effectively.

○ Will only ingest Data Sets and Fields that have a glossary association. ● Use with caution: Test and learn. ● Onboarding has to be enabled in Axon Admin Panel.


● Effective curation by the community is important for success. ○ Onboarding will affect all EDC content. ○ Currently we cannot point it at one Resource. ○ That means that it may bring pre-production tables and other content with

little/no business relevance into Axon. ● Name matching rules can introduce an element of error, as represented by the

confidence score. ○ Start with high confidence, reduce gradually

● Auto-onboarding runs daily at 0200 hours, this cannot currently be reconfigured. What is Imported Into Axon?

● Any Table and Fields that have been associated to Axon Glossary terms, manually or via automated techniques described above.

● If a table is associated to a glossary term, but none of the Fields are, the imported Data Sets will have no Attributes.

● If multiple Fields in the same Table are associated to the same glossary term association, only one Axon attribute will be created. This most commonly occurs where available fields are e.g. Address Line 1, Address Line 2 etc, and are likely to be related to ‘Address’ - here, one Axon field for Address may be acceptable.

Curation When an Axon user finds auto-onboarded content in a Data Set:

1. You may need to unhide the following columns in the Attributes Grid: a. Confidence Score b. Review Status c. Linked Field

2. You can then choose line by line whether to accept/reject the line.

2. Informatica Data Quality (IDQ)

An Informatica consultant was helping a financial services client understand the lineage that delivered a key regulatory report. Using Axon, it exposed and described all the data flows from around the client’s systems. It was a nice concise piece of work that would

really help people in the company understand how things worked.

There was just one problem. Around half of the people that attended the lineage show and tell meeting weren’t impressed - they didn’t disagree with the lineage, they simply didn’t trust the actual results that were to be submitted to the regulator. The other half of the

attendees didn’t understand/accept their concerns.

It was clear that the lineage of such a key business activity would be subject to quality analysis. Indeed the company had a rigorous approach to profiling and measuring. As


such, the obvious action was to source and map the Data Quality story onto the lineage. One week later, everyone got back together to see the results.

The result: everyone was right! How can that be?

Some of the lineage had satisfactory DQ scores, but other elements didn’t. Axon’s lineage map clearly showed what was good/bad. This let all the stakeholders understand

everyone else’s perspective. Upon investigation it emerged that the DQ team were fully aware of the adverse scores, and naturally had tasked it all for remediation. They were

able to show a long list of active remediations.

The elements forming part of the regulatory report were not all highly prioritised on this list. Axon was able to show how serious a risk the company was exposed to (understandably,

regulators don’t appreciate being given bad data), and the remediation tasks were immediately elevated in the list of remediation priorities. It wasn’t long before everyone

understood and trusted the end to end lineage and DQ.

So why had the company not fixed all this sooner?

● The company was actually very good at profiling & measurement...but...as it turned out, that was part of the problem - when you analyse everything you lose sight of what’s actually important.

○ In other words, until introduced to Axon, the DQ team were busy addressing issues without any assistance to assess their remediation portfolio with a lens that could inform business priorities.

● Axon should be used to let the business express what’s important to them, not to inventorise every asset the company produces

○ Ask yourself (or your key stakeholders...): what do we care about in the organisation, what are my Key Data Elements?

○ Once you have these in Axon, you can then bring your data quality tools into the picture.

So with that in mind, let’s look at how Axon and IDQ can work together to measure and share the right Data Quality information.

The Axon View of Measurement & Data Quality Axon can show different aspects of Data Quality, at two levels - the difference between Standard and Local rules was introduced in Activity 7 in Chapter 3. A quick reminder:

1. Local Data Quality Rules. a. Actual measurement of DQ types (also known as dimensions), e.g. Accuracy,

Completeness, Validity etc. These are typically reported with scores and using Red/Amber/Green colouring to indicate acceptability of these scores vs expectations (targets and thresholds).

b. Each of these rules is linked to one specific attribute, in an Axon Data Set.


2. Standard Data Quality Rules - expressed at the Axon Glossary level. a. The Glossary expresses key concepts and definitions for the organisation. b. The definers/owners business owners of these terms can indicate the desired

types/levels of measurement that real (physical) examples of these concepts should be measured against.

The Data Quality Measurement Process If we consider the previous section in terms of how organisations typically develop their measurement, we can see how Axon compliments this:

Informatica Data Quality Informatica Axon

A business user typically specifies a rule that needs measured in plain, non-technical language. This could e.g. be specified in IDQ’s Analyst web interface (rules specification), or in a spreadsheet

This is similar to Axon’s Glossary > Standard Data Quality Rule. We cannot make links between Standard Rules and IDQ rules yet, but we’re working on this. Standard rules are not linked to specific measurement, simply provide guidance/instruction on what would constitute appropriate measurement. In our experience, most users will accept this guidance. However we’ve allowed flexibility in the tool for individual data owners to set their own standards - the score doesn’t change, but each owner can assess how acceptable the score is through varying score thresholds

The DQ team will then turn these descriptions into an executable set of rules that are capable of reporting the score of rows that pass these rules

These rules can be mapped against fields in any given table to generate a measurement. Rules report % adherence, and can be ingested by Axon. Axon can also read metrics from Profiles, but does not ingest general profiling data such as frequency analysis, etc.

Whether it is a rule mapping or a metric from a Profile, these can be represented in Axon as Local DQ rules (Axon does not link to generic IDQ rules). These Local DQ Rules are linked to Attributes in Axon Data Sets. Each rule can have its own Threshold (IDQ: Acceptable) and Target (IDQ: Good) Any other Axon objects (e.g. Process,


Policy etc) that state a dependency on such attributes are automatically linked to the DQ score information from the associated Local DQ Rules.

Defects can be handled by workflows within IDQ, and assigned to e.g. Data Stewards to investigate the causes of unsatisfactory results.

Axon reports the latest scores, and the ingestion of automated measurement can be automated. Any member of the Axon user community can interact with the stakeholder community about DQ, or any other aspect of governance, via Axon’s Change Request/Workflow feature

Aspects of Axon Data Quality Rules Building upon the content discussed above, some specific comments follow. It should however be noted that, because of the precision required in Axon, any reference to an IDQ rule should be thought of as to a specific mapping, not to a generic rule that have many applications and measurements.

Linking an Axon Local DQ Rule to IDQ As the screenshot below shows, the Axon DQ rule can be edited to associate it with IDQ. Select the Technical Rule Reference field to trigger a menu that shows what Axon can read from IDQ:

● Scorecards - individual rules within the scorecard can be linked to the Axon Local DQ Rule, not the scorecard as a whole

● Profiles - as mentioned above, Axon can ingest metrics from a profile that e.g. give completeness information (see IDQ literature for guidance on creating metrics)

Once the rule/metric is selected, users can then select a frequency

● Axon permits Daily ingestion of scores ● However, we do not recommend this, and most customers set this to weekly/monthly.

Axon is not a substitute for regular reporting tools, given the overall scope of data we’ve recommended ingesting into Axon

● Note that special configuration is required to ensure that Axon can work with your instance of IDQ. See technical documentation for details re the ‘DQ Agent’


DQ Automation The following section describes features that can only be realised by customers who have Axon, EDC and Informatica Data Quality integrated with each other. Once Axon is linked to the physical world in EDC, you can then link Axon to IDQ rules/mapplets. Again, all of this setup is highly technical, so we won’t cover it here. There is a H2L article on the Knowledge Base that shows the steps to set this up.

What you get: Mass automation of DQ rule Common rules that can be mass applied to technical assets in EDC, e.g. completeness rule. Doesn’t create new rules, just mass executes existing rules. If new table found with no DQ, it can apply mapping to it. This for mature in EDC and DQ and Axon Needs Dedicated team for DG, you can then follow the steps. Have to have done wotj in EDC, have to have IDQ with the rule, have to know what they are doing in Axon.

3. Data Security - Secure@Source Informatica Secure at Source, is Informatica’s solution for real time discovery and monitoring of personal and sensitive data. Sensitive data is often the focus of governance initiatives, and clients often need to get a view of how this impacts upon assets described in Axon. Secure@Source therefore integrates directly with Axon, and the Enterprise Data Catalog (EDC).


Data Privacy & Protection Increasing regulation is just another reason for ensuring your organisation has effective controls to ensure customer data is held and controlled appropriately. You need to:

1. Define and governance policies ○ ...which requires collaboration

2. Locate, classify and understand private and sensitive information ○ Visibility across all platforms and types

3. Map identities ○ Index, inventory and look up date subjects/identities

4. Analyse and track data risk ○ Continuous risk analysis of sensitive data

5. Plan, remediate and monitor risk ○ Protection planning with orchestrated and protection

6. Communicate, audit response ○ visualisations , reports and tables to communicate privacy status and action

As you’d expect, there’s a lot of activity managed in Secure@Source, which is created and managed by data privacy experts and your IT department. The link to Axon helps to show the wider community what is happening, and assure them that things they care about are under effective control.

What is a Policy?

Secure @ Source Axon

A collection of technical rule statements, which are executed by Secure@Source to identify Resources (Axon systems) and Fields (Axon attributes) that fall within the

A collection of statements, written in plain business language that outlines an organisations’ principles/approach/course of action towards a subject.


parameters of those rules: Such statements are created to define 1.Classification Policies A collection of Data Domains relevant to the same issue with an associated Risk Cost & Sensitivity assessment. These are then scheduled to run regularly and reported in Secure@Source 2. Security Policies These are set up to monitor operational controls such as:

● Access breaches ● Ensuring data is not transferred to

locations outwith permitted legal border

The most common context for creating policies in Axon is when an organisation defines its response to a regulation. The regulation is interpreted by experts (often from the legal team), and the key elements distilled into a collection of individual policy statements. These, in turn, are frequently supplemented with clear processes that ensure and enforce adherence to the goals set out by these policies.

Secure@Source/Axon Integration Steps

Step 1 (S@S) Step 2 (S@S) Step 3 (S@S, Axon)

After install, get Data Stores configured and connected. IT set up domain discovery rules in collaboration with the business;

● Start small, test and tune - iterate before scaling.

● Set up scanning schedules.

Once Secure@Source is reporting on scans, ensure setting are correct:

● Risk cost and conformance - volume of records in a data store.

Connect Axon System object to Data Store

- Is the system secure, what’s the protection status?

Axon Policy object to Classification Policy or Security Policy

Note that earlier versions of Secure@Source relied upon the Enterprise Data catalog (EDC), but in recent releases that’s no longer the case (technical documentation will explain this). This means that Axon can work with Secure@Source alone, or together with EDC. Please consult technical documentation for more details on connecting and integrating these tools.


One other thing to consider before reviewing this section. Just like EDC, whenever Secure@Source discovers something, that’s not a cue to go ahead and describe it in Axon. Discovered assets have to be relevant to governance activities to merit linking to Axon content.

Secure@Source Data Store vs. Axon System Facet Where a discovery rule has found a Data Store, that may be represented in Axon, if it’s important to the governance goals of the organisation. The discovered Data Store may have been represented by different names in each tool, and this is normal - Secure@Source needs the ‘real’ name of the physical asset, whereas Axon may have a more business friendly name, or a commonly used acronym (e.g. ‘CMD’ instead of ‘Client_Master_Database’).

Creating The Link - System Facet To make the link in Axon, you must have the rights to edit the object in question. In edit mode, using the Manage Catalog Links menu find the Data Store and make the connection.

Secure@Source - The Policy Facet An Axon policy object can also be connected to either type of Secure@Source policy, by any user with Edit rights on the Axon object.


Which will bring up a menu that allows you to choose from available Security / Classification policies - these are configured and named in Secure@Source.

Viewing Security Information (in System/Policy Facets) We talked above about the fact that how connections are made between Axon and Secure@Source depends on whether you also have EDC. Whichever mix of products you have, from an Axon perspective the content displayed is the same. However, in the sections below we refer to hyperlinks that appear in Axon, directing users to the detailed information held in Secure@Source.

● If EDC is connected to Axon, hyperlinks direct to EDC ● Otherwise, Axon hyperlinks direct to Secure@Source

For both facets, the main output of the link is a dashboard, found in the tab beside summary, as shown in the picture below. Note that it isn’t the default dashboard, so select it from the dropdown indicated: System Facet Note that the information displayed is for the Secure@Source Data Store as a whole. It does not discriminate between content that has/has not been described in Axon.

Policy Facet Dashboard The information displayed varies according to whether you’ve linked to a Classification Policy, or a Security Policy. Note that:

● The information displayed in Axon is sourced real-time. ● How frequently the underlying data is rescanned depends on settings within

Secure@Source.


The first picture shows a Classification Policy dashboard:

The detail of all violations is held in Secure@Source and can only be accessed by those authorised to do so. However, users with the right access can be taken to Secure@Source from the link in the Axon object.

EDC vs Secure@Source Some of the discussion above may have raised questions about the similarities between EDC and Secure@Source. The way in which these tools discover data is broadly similar. A


key difference is that typically Secure@Source Discovery Rules will typically discover fewer assets than EDC Data Domains - not everything that EDC might discover needs the same scrutiny applied to sensitive data.

EDC Secure@Source

● Data Domain rules discovers and describes everything it can connect to

● Needs bigger licence than Secure@Source

● System level objects returned are called ‘Resources’

● System level objects returned are called ‘Data Stores’

● Secure@Source only displays data stores that contain sensitive data

● Functionality based on exploring Data Security questions, such as Risk data, focus initiatives, security monitoring, perimeter security

B. Integrations to Other Products via API The APIs in Axon 6.0 are a substantial increase in capability from previous versions. Not only are RESTful APIs now available for both read and write, they are now available for almost every facet. Technical release notes explain how to set up APIs, and can be found on the Axon Community Pages / Informatica Knowledge Base articles. Naturally, when adding content via API, all the same principles we’ve talked about throughout the playbook apply - only bring in content that is directly relevant to your governance efforts. Start small, think big, and only then scale. In Axon v6.0, write APIs facilitate ingestion of the same field available in that facet’s bulk upload template (and therefore must obey the same rules on Mandatory fields). When reading information from Axon, the API can access any field that is visible in Unison.


Chapter 6 - Common Use Cases The intention of the Appendices section is to provide some specific advice for common use cases. It builds upon all the discussion in the main playbook, and gives some suggestions on how to construct content for some common governance scenarios.

Use Case: Privacy Regulations e.g. GDPR / CCPA In this section we’ll largely tell the story of GDPR, introduced in 2018. However, many countries (and US states) are actively working on their own privacy legislation, and the approach you’ll take to all is likely to be very similar. The General Data Protection Regulation came into effect on 25th May 2018, and affects any organisation across the world that stores or processes the personal data of any European citizen. Given the fines involved, this has taken up a lot of time and thought in many organisations. The regulation, published and enforced by the EU, compels organisations to carefully manage data relating to private citizens - control what they can capture, subject it to strict security controls (including which countries it is passed to as it flows around the organisation), and retain it for no longer than is necessary. In order to do this, companies will have to work out what data is subject to the regulation, understand how it is used and stored, then create appropriate business rules to ensure that they are compliant with the terms of the regulation. If we break this down into Axon terms we could think of it as follows. Please also refer to an earlier section on why Relationships can be more powerful than descriptors:

● An external Regulation causes a company to think about its own response. This response will be documented in the Policy facet.

○ Most clients choose to capture regulation and policies in granular form, so that Regulation x Policy relationships are more informative as to which articles of the regulation drive which policies, processes - this will become more important later should the regulation evolve - you’ll be able to more easily identify which specific elements of a policy/process are affected by a change in any given Article.

○ Typical required policies include those for transfer of data, security policies. ● Users will need to find personal data subject to the regulation, often referred to as

Personally Identifiable Information, or PII. The best way to approach this is by linking the Glossary terms to the individual policy/process elements that affect them.

○ See Relating Assets Together for why we don’t have a PII field in Axon. ● You can then show, using different Policy x Glossary relationships:


○ Data elements classified as PII ○ Data elements classified as Special Category ○ Data elements classified as Relating to Criminal Convictions

● Processes using personal data will also have to be seen to adhere to these policies. The process facet is at the core of showing how data is used.

○ Process x Glossary relationships help build the picture - this is the relationship that shows which data elements and personal data categories are being used in which processes

○ You can then show, using different Process X Policy relationships: ■ Purpose of Processing requirements - these must be established by

each organisation. ■ Legal Basis for Processing, as specified by the regulation e.g.

Consent, Contract etc. ○ By creating a meaningful list of Business Area you can then relate these to

individual process steps to show the departmental responsibility/interaction. ● Assuming all Attributes have appropriate Attribute x Glossary relationships, you

can then search on the conceptual glossary terms to find real examples of attributes and their lineage.

○ Systems & Data Sets can have ownership/access related to different Legal Entities - useful for showing where 3rd parties are used as Data Processors or Data Controllers.

Retention Policies GDPR requires that personal data is not stored for longer than it needs to be to carry out its particular purpose - this is in line with minimisation tactics. Once you have created the relationships described above, you may find that different glossary concepts have differing retention requirements in different scenarios. Also, don’t forget that these objects may also be affected by other policies and processes that are nothing to do with GDPR. It can be very difficult to work out what the maximum required retention period is. How to handle this? We have observed that the organisational structure of some companies has allowed them to use Axon in an interesting way we had not anticipated. After a period of populating Axon and creating the right story for GDPR and other imperatives, a central committee reviewed the content, and worked out the net effect on individual objects. The committee then went through a process of creating and assigning additional Policy x Glossary relationships that stated the retention period.

Article 30: Report on Processing Activities One key requirement that is commensurate with GDPR is the need to satisfy Article 30. The content of Axon is best leveraged for this in tandem with a BI tool to extract the required information. We’re improving Axon capabilities all the time - please contact us to get advice on the latest way to address RoPA reporting.


Use Case: Regulatory Reporting (e.g. BCBS239, Solvency II) (BCBS239 / Solvency II) Many organisations have to satisfy regulators that they are operating appropriately. Financial services firms may fall under the requirements of BCBS239, Insurance companies have Solvency II. There are many examples in other industries. Whichever regulation and industry you are in the reasons for detailing your responses are often the same; clarification of applicable definitions, identification of stakeholders, building trust in submitting reports, evidencing appropriate process and controls exist. The typical requirement is to ensure that users trust the data is fit for purpose, and the processes that create the report are robust. Some regulations even hold individual members of staff legally accountable for providing accurate data. This activity typically happens on a regular basis. Axon describes the meta data used, i.e. it captures the details of how a report should be created, if we needed to run it right now. It won’t tell you the actual output of any given report, just the policy and processes that created the report, the lineage, calculations etc that are used in its creation, and identifies key people and roles all along this path. Some key themes that you may wish to consider are as follows:

● Start with the final report. Create it as an Axon Data Set, of Type = Report. ● Describe each data point contained in the report as an attribute. ● Tell the lineage story of how each attribute arrives in the report, working back as far

as you need to. ○ Each ‘hop’ from one Data Set to another is an opportunity for the data to be

changed, aggregated, sub-divided etc. Tell that story. Calculation logic is often a key part of the story you need to tell - remember that the Sourcing Logic field in the attribute x attribute upload template can be used to give this detail.

○ Where possible, ensure attributes are linked to glossary objects to help show where transformations cause the data to fall in/out of relevance with approved definitions.

○ Data Quality is likely to be considered a mandatory requirement to build trust. ● Why are you doing this reporting?

○ An external regulation demands it - capture this in the Regulation facet ■ Perhaps add in the Regulator and applicable Geography information.

○ The Policy facet allows you to describe your organisation’s internal response to the regulation.

○ The Process facet allows you to detail any documented steps that are followed to create the report.

○ Policies and Processes can be related to the final report(s) to bind everything together.


● Optional: Where multiple Data Sets form part of the regulatory submission, the Capability facet can be used to pull all reports together to show the full deliverable.

Such reporting can generate large volumes of assets to construct. As ever, when you try this for the first time:

● Start Small: Start with smaller, simpler reports. ● Iterate and Learn: See what works/doesn’t, and work around issue. ● Then Scale: use learnings from this initial activity to assess how integrations with e.g.

EDC and IDQ can be used to make this easier to capture and manage.

Regulatory Reporting - Facet Summary

Typically Used Lineage (System/ Data Set/ Attribute/ Interface) Glossary Policy Process Data Quality People - Accountable Stakeholders

Recommended Regulation, Regulator, Geography

Optional Capability

Key Relationships

Typically Used Attribute x Attribute Attribute x Glossary Attribute x Data Quality Rule

Recommended Lineage x Interface: Interface allows you to describe

Use Case: Data Acquisition An emerging use case common to many clients is that of Data Acquisition. If you have a commercial agreement with a partner/supplier to receive a regular flow of prescribed data for e.g. analytics to help manage/improve your relationship. Access to the data is heavily controlled by a contract, which limits the use of that data within your organisation. A suggested approach would be to document in Axon as follows:

● Lineage: Map out entry and consumption points in Systems/Data Sets. ● Policy Facet: describe the internal restrictions created by the contract. ● Process Facet: evidence the use of the data with a map of the processing.

Optional:

● Additional Data: the supplied data is typically fixed by contract. There may be scope within this for occasional requests for extra data. You may need to have an audit trail


of how these exceptional requests were handled, any checks and approvals made and obtained, together with a record of what was actually sent to the client.

○ This could be handled by Change Request (CR). Running a CR against an approval workflow can provide the evidence and approvals. If the required workflow is unique to the partner, this could be created against the Data Set, Process or Policy as a Custom workflow (only visible to that object, rather than generally available to all objects in that facet).

● Flagging systems as external - clients frequently ask how to handle declaring systems external to the organisation. Axon already allows you to describe such systems. However, be aware that these systems cannot be governed if they do not fall within your own boundaries.

○ It may be better to instead capture the entry point into the organisation, as this is within your sphere of control. Such objects can be governed.

Data Acquisition - Facet Summary

Typically Used Lineage (System/ Data Set/ Attribute/ Interface) Glossary Policy Process Data Quality

Recommended Legal Entity

Optional

Using Data Sets: Schemas & Physical vs Conceptual Views As we’ve alluded to throughout this playbook, when thinking about or describing the actual data used in everyday business activity, there’s usually quite a divide in the expectations of the more technical community vs the (less technical) business community, who also tend to be the owners/stewards for these key activities. More technical users are comfortable with artefacts such as schemas, entity relationship diagrams etc., and want/need to know more about the detail - column profiles, typing, length etc. Business users, however, just want to trust the data they use, and don’t need/want/have the capacity to understand them. As such, when these two communities interact, trying to use a technical artefact creates a barrier to engagement, and therefore affects the DG programs’ chances of successful adoption. So how do we make progress as a governance community? We sacrifice (some) purity for (greater) understanding. One of the features of Axon that helps us achieve this, is the use of Data Sets to create either partial representations of large physical tables, or representing non-physical collections of data as types of Data Set. These are conceptual data sets. Whichever of these you use, they isolate and describe the specific data used in a specific Use Cases.


Not only does this make it easy to tell the story of each Use Case, but each typically has its own community of people that curate or depend on that version of the data, and again this is crucial to expose. Data consumed by one individual Use Case can take on a life of its own, separate from the original source. As soon as data is extracted from the original physical source, it can be subject to filtering, transformations, aggregations etc, and reused for other use cases. Subjectively, whether these extra uses are appropriate/correct is, at this stage, irrelevant. It happens, governance is all about understanding the reality, and so we have to describe it.

Example 1: Many Uses For One Large Table Multiple process owners/stewards source data from the same data source. That source is one main physical table, with hundreds of columns. Individual use cases use only a fraction of the available columns, but dozens/scores of Use Cases source data from the table. Each Use Case not only extracts only what they need, but typically also starts altering the data, via filters, transformations, joins etc. Isolating and explaining the final state data can be best explained through a conceptual data set, with its own community of curators and connections to other facets that explain that use.

Example 2: Representing Different Views Of Data Another ask from clients is advice on how to represent a view such as the picture below in Axon. Typically the question is phrased along the lines of “How do I show…”:

● That a physical table exists in multiple systems? ● That a table/data set has multiple parents?

In Axon, we don’t represent data as shown in the graphic, because business users don’t see it this way. We see the tables above existing as separate objects in each system, with their own community of stakeholders and users, and reasons for existing that are explained via connections to facets such as policy, Process etc.


The Axon Answer In both the above examples, it’s common to find that although the data is ultimately the same, it can often have different names in each location. In other words, it is manifested with different field names/labels that use the language of the community accessing the data, and each conceptual data set can have attributes that represent this. We can retain the understanding of the concept being used via the attribute x glossary link, and still talk the language the business users recognise - which is the key to ensuring they engage with the information. We can also recognise the source of the data via lineage, giving both technical/non-technical full visibility of what’s going on. There are other scenarios where the same metadata appears to exist in multiple locations.

● Same metadata headers, but only a subset of data available, i.e. it is a customised view of the data (e.g. a central table in a bank holds information on all accounts held, but some systems are supplied with a filtered view that supplies only personal customer data, others show only corporate account data).

● Simple duplication. There may be a genuine reason for exactly the same data being available in multiple places, but it might just be a factor of the data landscape’s evolution over time.

○ Remember that we believe modern governance to mean that you are not there to judge, just to talk about what’s actually happening. So, initially, just accept whatever you find. This friendlier approach is important for engagement and adoption - be seen as an ally, not someone to be scared of.

○ Of course, if the community don’t like what they see, it should of course use that as a catalyst to change. However, this needs to be done carefully, both in terms of understanding the impact of the changes before you start, but also in a way that is sympathetic to continued openness - blame cultures kill engagement, which limits the chances of finding other undesirable/inefficient realities.

Example 3: Reports - Combining Physical and Conceptual Data The next scenario we need to consider is representing collections of data that some communities do not regard as tables. Remember that in Chapter 2 we defined an Axon Data Set as ‘any identifiable collection of data’. A report fits that definition. So does a read only screen in a BI universe, or an input screen with its own labels to facilitate easy input. Reports can be the result of a query, exist only as a read-only screen, or just be a piece of paper. It can still be referenced by a name people recognise, and contains different headers/fields/columns that supply information that delivers value to the business. And because these fields often have identifiable sources in the physical landscape, we have to represent them in the same facet (using a different Data Set typing), so the lineage maps can show that story.

● We have observed that some clients are occasionally reluctant to add reports to the Data Sets and Attributes facet, because it mixes up physical and conceptual data.


● Their solution is to describe such conceptual constructs using the glossary facet. This is the wrong approach. Never mind that the glossary facet should not be used to describe real data/usage, it defeats the ability of maps to explain the full story of a report.

There are a couple of ways to show the link to physical data in Axon. Lineage is typically the most popular:

Demonstrating Links to Physical Data: Via Attributes Tab

The link can be shown in Data Sets > Attributes, in the DB Field Name column.

Demonstrating Links to Physical Data: Via Lineage Consider the map below. This picture shows that all attributes on screen are linked by lineage. To the business this explains the interdependencies and flow.

Again, what’s important here is that all inputs and outputs use the names that the local owners and users of that individual asset recognise. The map actually shows a combination of physical and conceptual data. Whilst more technically oriented members of the governance community might care about the physicality of the data, the business typically won’t, and it certainly won’t be the first question they ask. They just want to know if it is fit for purpose, has an acceptable quality etc. If physicaility becomes part of the conversation, there will be enough clues in the lineage to understand the source. Unsion

Searches on Typing, use of map filters can answer those questions. So can looking at the


Sourcing Logic field in the Data Sets > Relationships tab, where the story of each attributes x attribute hop is told.

Conceptual Data Sets and Integrations Conceptual Data Sets are a key part of explaining activity in a way that the business understand the organisation. If you are using any of the integration features described in Chapter 5, you’ll need to assess what that means for content you add to Axon in this way. A feature such as onboarding will naturally only recognise the physical name of the asset, and may require amendment to be accepted by the business. Additionally, where you need to create multiple versions of the asset, you may need to use bulk uploads to create the conceptual data sets, or use the Clone Data Set option in the Data Set’s Actions Menu. However you create the Data Set, you can still create the link to the physical assets held in EDC, via the System x Resource and Attribute x Field bulk uploads.

Use Case: Reference Data Showing use of/dependency upon Reference Data is another example of using Axon Data Sets. Axon does not provide full reference data management capabilities, so, just like Cataloging, you probably won’t want to exhaustively inventorise all reference data in Axon. However, some of your reference sources will be important to governance because they enforce consistency of data in various use cases. Where this is part of an important Use Case, you may wish to add those reference sources to Axon. The links that other Dat Set curators make to that source will show where multiple Axon attributes/data sets rely on the same common source. This in turn brings the curators of those reference sources into the governance community, so that they can be recognised and consulted when appropriate. Reference Tables are represented in Axon as Data Sets of Type = Value List. The example below shows ISO Country Codes.

The attributes tab capture the fields of interest (as ever, this might be a subset of the available fields in the reference table, and the stakeholders tab would capture subject matter experts and other relevant people. Where other data sets rely on this information, a simple connection using attribute x attribute relationships will demonstrate these dependencies.


Optionally, the Values tab is where we can add some information about the reference data; frequency of updates etc. Some examples of valid data can be added (Sample Set in the screenshot), or a full and exhaustive list, if required.

Such values can be entered manually, or by bulk upload. Note that the uploader and template sit in this screen, not in the main uploads place. This is because the template generated is specific to this Data Set only (uses the field names from the Data Set. Also note that when uploading data all columns must have an equal number of rows populated. If your data has an unequal number of values for different columns of rows, please add some consistent dummy data points (we’ll address this in a future release).


Use Case: Building Lineage This section will demonstrate the different features of Axon that can be used to create data lineage in Axon.

Basic Lineage In Axon, the main use of the term lineage is to show how pieces of data flow around an organisation, where and how they are consumed, and what form they have taken during this journey. As data flows around an organisation, it may be altered from its original form to suit different Use Cases. It is usually imperative to understand what state the data exists in at any point in this flow, so we can assess whether the end state data is fit for purpose. Using Axon terminology, data lineage is the story of Axon attributes. Attributes are members of Data Sets, and any instance of an attribute being passed to and used in another data set, is a piece of lineage - we call each jump from one data set to another a ‘hop’. The full lineage story for data could easily involve multiple hops - from a governance standpoint, each hop needs to be fully understood, so that we know if the data is consistent with the source definition, or whether it is evolving and changing as it moves through systems and data sets.

Attribute X Attribute & Relationships Tab

The interactions between individual attributes are shown in the Data Set > Relationships tab. The data hops shown above appear in the Inbound Relationship grid because this lineage comes from other data sets. If we looked at the equivalent Relationships tab in one of the source data sets, the lineage above would show in the Outbound Relationships tab. The Outbound Tab is read only because we only allow the receiving Data Set’s stakeholders to control the story they tell about their assets. Sourcing Logic Field: Note the inclusion of the Sourcing Logic field, where a text description of the hop logic can be added. This field has to be manually exposed (via Grid Settings Menu > Columns), as it is not shown by default.

Lineage Maps - Objects vs Unison Maps Once added, the Relationships tab will show the story of all hops in a map and in a grid view. Note that the map below shows the Linking Attributes overlay. We sometimes refer to maps


inside an object as Local maps, and those drawn in Unison as Insight Maps, because they have different scopes. Local map scope is very focussed, and will only show things relevant to that object. Insight Maps have much greater freedom, although users can use the controls in the UI to look at whatever they want to. A local map

Compare this map, against the one below. There may be other attributes in any of these Data Sets above, but as they have no lineage relationship they will not be shown in this local map. An Insight Map.

If we now look at an Insight Map drawn from a Unison search. All three Data Sets are in scope of the search, which means that all their contents will be seen, e.g. if the attributes overlay is selected. If we then click on any row in the overlay, we see any lineage relationships they have. In the example shown, the input to the Profit attribute are highlighted against other attributes, showing that they are part of the calculation.


The Interface Facet At this stage in the lineage discussion we need to talk about the Interface facet. The Interface has two separate uses. Although supporting attribute lineage is probably the one that you’ll use most, using Interface for an activity we call scaffolding is one that some users find useful in the early stages of rolling out Axon. We’ll talk about its role in attribute lineage first, because it is complementary to what we’ve talked about above.

The Interface Facet: Showing How Lineage Hops Happen

The picture above is a repeat of one used in the previous example. Note the third field, Interface, is empty. Although we can understand from the other information what data flows between this data set and others, this only tells us what has moved (and any changes to the data in that hop - aggregations, transformations etc). It does not tell us how the data moves. This is where the Interface facet comes in. As useful as the attribute x attribute information is, it doesn’t tell us things like:

● Is the transfer made automatically, or manually? ● Who is responsible for the transfer? ● Is there a certain file format we have to use?

Interfaces can be added to tell this part of the story, exposing those responsible to the community, so that they can be recognised and asked questions, when necessary. If an Interface is automated it may be maintained by specialists who are alerted to failures by monitoring. Such transfers are more robust that e.g. manual transfers made on an adhoc basis by email, which can help identify processes at greater risk of failing. Interfaces are created at the System x System level, and are one-directional. When first created, they show the basic details of transfer. Any attribute x attribute hop can have interface information added. Once this is added, the information can be seen in various places - the Inbound Relationships grid has more information:


Interface information appears on Maps as dotted lines. Any Attribute lineage between the same systems appears on the map as a solid line. Where both system and attribute lineage exist, the dotted line is obscured by the solid lineage line. Users can check for system interface lineage supporting a data flow in many ways - one is by use of filters in the map palette:

The Interface Facet: Scaffolding Scaffolding is a technique that can be useful to users at the very start of their Axon journey/a new Use Case. Sometimes Use Cases are bound by the systems in scope of the project, and the team have limited information about the specifics of data used therein. Using interfaces can draw out a landscape that gives the team something to focus on, the goal being to ‘fill in the blanks’.

Glossary of Terms Used

Name Description

Actions Button When a user visits any object in Axon, there is a blue button in the top right hand side of the screen. This is the Actions button, although it may be labelled Actions or Edit depending on the individual users permissions for that object.

Artefact Any single object in your organisation that you might choose to record as an object in any Axon facet.

Asset Any single object you choose to record as an object in any Axon facet.

Attribute Attribute is a term that has wide and varied meaning in the


business world. In this document and in Axon we use Attribute to describe a data point found in a database/table/report, it’s the column/field name. Axon attributes must reside within a data set, which in turn resides in a named system.

Conceptual Data Model See data models.

Data Dictionary Again, a term that has wide and varied use in the business world. Some clients use this for: 1. Describing commonly used data points found in tables. In Axon, that would be Attributes in a Data Set. 2. Some form of list/taxonomy of approved definitions or business term. In Axon that would be the Glossary.

Data Models Axon is model agnostic. However many important community contributors will understand aspects of the organisation through the lens of some form of modelling construct, at different levels of detail:

● High Level: Conceptual models are the highest level and are generally not detailed.

● Medium: Logical Models do begin to start showing lower levels of detail.

● Low Level: Physical models are highly detailed representations.

Facet Axon feature. A facet is a specific list of assets that a client chooses to record in Axon. Facets split these into different types of asset, e.g. Process, System, Policy.

Hop One single part of a wider lineage story, when an attribute in one Axon data set is linked to another attribute in a different table. Also known as attribute x attribute lineage. Multiple hops tell the story of data flow through the organisation.

Item Any one entry/object that has been added to an Axon facet.

Logical Data Model See data models.

Object Any one entry/item that has been added to an Axon facet.

Physical Data Model See data models.

Unison / Unison Search The main Axon user interface, which shows your assets divided into Facets e.g. System, Glossary, Process etc. The key aspect of this is the ability to search for objects and isolate objects in other facets that they are related to.
