On Internal Mapping (1)

Photo by Miguel u00c1. Padriu00f1u00e1n on Pexels.com

Context – If a picture is worth a thousand words, what does it look like when we consolidate a thousand logs? In many organisations, there are many disparate data sets acting as pieces of the organisation’s puzzle. An excellent analogy to the approach – you may have an idea of the whole picture (it’s on the jigsaw box) but you don’t really appreciate it until you start looking at the pieces. In this, each dataset is an additional piece, by taking each piece, mining the relevant parts and how they relate to the whole picture, the organisation gains incremental understanding of not only the value held by the dataset, but where it fits in the greater picture.

Entities, relationships, and layers – In order to understand the value of link analysis as a map it’s crucial to understand two concepts; the entities and relationships, and what a map – say from Apple or Google maps – is comprised of.

Entities are things – Physical or virtual, an entity is a noun. Person, place, hardware, software – these are all things we can define. Ideally we want to break it down to the lowest common denominator – the smallest unit available – and use the data we have to give each entity the best definition we can.

Entities in link analysis have scorecards – In creating the definition for an entity, we want to create a universal card tracking the same data we can map to fields where we understand the value. Think of it like a baseball card, where data on the player, position, averages, etc are all contained in a single format of uniform data. All the cards have the same types of data, located in the same places, to serve the same ends – the comparison between different players; in our case it would be entities. Based on the data we have we create a baseball card for employees, but we can also create a card for offices, computers, manufacturing equipment. All these entities have properties stored in a dataset. As we find/ incorporate more datasets, we add to each entity’s baseball card. As a living/ dynamic map, it grows over time.

Between entities are relationships – Entities do not exist in a vacuum, but with other entities. Just as nouns are entities, relationships would be the verbs (were we to create a proper primary school sentence). Starting easy – the relationships between people in the hierarchy would be defined by the relationships between superiors and subordinates. Similarly, a relationship would be established between a person and their devices, if assigned. Those devices would have a relationship to the software used and the hardware hosting it. As we look into the data, what is determined relevant either will be used in the card or to establish the relationship.

Layers of data – Looking at a map, we see the overall picture, though when we consider the data involved there are many datasets – each comprising a different layer that may be added or subtracted from the picture. Data such as topography, roadways, waterways, landmarks, businesses are each separate datasets, able to be filtered out if the user isn’t interested. The data is still there and part of the composite whole, but not visually represented. As we add data, be it to the entities or relationships we can practice the same layering. Some data may not be relevant to everyone, some may be private. By creating individual layers we can choose between degrees of the layer’s visibility – Transparent (open to everyone), Translucent (open to selected people or organisations, with a greyed representation there is data and a point of contact to reach for access), or Opaque (only visible to those with access, not represented otherwise).

Data access and control – The different visibility settings create a different question: who controls the data? Whilst it will come to a leadership decision, I would strongly recommend the data owners have control of their data’s visibility – as they are responsible for the creation, update, and maintenance of the data. Ideally, we would want the data stored in a scrape-able repository for automatic ingestion either at specified times or when the data is updated. I would also suggest the data owners keep the visibility at no higher than translucent, as part of the value is in recognising there is more to trace out as we look further into the picture the data created.

Open ontology with room to grow further – We have talked about ontologies here. What’s important to know in our creation of the internal mapping ontology is the openness required to build out what would/ would not be included. As the build is organic over time, what we uncover may shift our understanding of possible.

Intrigued? You’ve heard the what and why, stay tuned for the how.


2 thoughts on “On Internal Mapping (1)

  1. Pingback: On Internal Mapping (2) – Maelstrom Advantage

  2. Pingback: On Ripple Impact and Operational Resilience – Maelstrom Advantage

Comments are closed.