BLUF – A GIS-style layered approach gives control to correlating data sets. Building layers with questions and considerations aids in making certain the picture we see is accurate. Permissions and transparency are crucial aspects in determining who else has visibility, and helps shift culture within an organisation. Layer the knowns, and unknowns are identified, possibly reduced.
Working with large varying datasets is difficult, resulting in lost connections because we are unsure how to correlate. This is a self-imposed limit, albeit understandable. By taking a similar approach to how we connect geography, what we know becomes more manageable. What we don’t know becomes more readily visible. In talking about how we determine risk or provision Operational Resilience, we need to built up our understanding of what is known, preferably with degrees of transparency as default. Of course doing so leads to other conversations – resourcing, ownership, time, platforms for use – but those are all for other posts. This post is intended to spark possibility in how we use the data to layer our knowns, shrinking the unknown.
A basic tenet of mapping anything is where you start (actually, it’s the premise for a great deal more, but I digress, different posts). Mapping something as large as an organization’s enterprise/ clients/ customers/ suppliers etc. requires a solid foundation that can be applied across many data sets. Technically, in data science, mapping is a smaller operation of matching source to destination fields, aiding the migration, integration, and management of data and associated tasks. If we consider it data science’s six degrees of Kevin Bacon, where does everything end up? We will be taking a more esoteric definition of mapping by using concepts prevalent in Geographic Information Systems (GIS) defined by data science. In our case our lowest common denominator is still people. Won’t rehash it, but we can talk further if desired.
Where from there?
Looking past aspects of people that would populate their scorecard, we must find balance. Every data set adds a layer, populating entity scorecards allowing us to show correlations… Or not. In geographic maps, layers offer the roads/ waterways/ landmarks/ utility infrastructures which may or may not be visible. In part it’s up to the user to determine how much they need to see. Sometimes it’s up to the owner to determine who needs to see. This gets into how permissions affect a map’s representation. Multiple data sets have to be there to make connections relevant; but not everyone should know. In plotting our course, layer development brings us a few interesting questions to answer:
- Do we want the connections to still operate in the background regardless the visibility of the layer? Meaning despite not seeing why a connection exists, you still see a connection. Personally, I think it best to have the connection still present regardless, as going without it creates potential for skewed representation. For instance, in the financial sector – if we were to overlay Suspicious Activity Reporting over cyber alerts and customer/ client data (something belonging in AML space) we could see connections between entities raising potential flags based on evidence found in the investigation. Now, do we want everyone to see the investigation? Certainly not. Do we want discard the potential flags raised by the evidence? Also, no. Though we don’t want everyone to know why, we still need to keep the connections present, even if that layer is not visible. Makes a difference in notifying other businesses within your organisation to have care in their considerations.
- What types of permissions would you maintain? For an expansively nuanced data set, go beyond traditional admin, editor, read/ write, read-only and none. Do we need some people to see a connection is present and whom to ask, or is that a visibility issue? Do we need some to be able to update data while limiting their ability to larger sections within the layer? Would there be a permission that only allowed to add data updates whilst keeping the record intact? Are there sections not needing to be retained once we edit? Will we keep a version history? What permissions do we need for people who will rely on our data for different business purposes than we are responsible for? What do we need for people who normally would never use our data, were it not for a connection previously not considered? Do we want the layers to be automatically built from datasets and not be editable in the map? I could go on, but you get the notion.
- How transparent will we be, and where are limits set? Starting with people is a firm foundation, with limits to some of the layers that could be overlaid. I would want to know where they (and their team) fit in process and controls, even though I may not need to know at the moment. I don’t need to know HR data, and shouldn’t. Eschewing traditional classifications, I would suggest three levels here, for simplicity.
- Transparent – you can see everything. As much as it frightens people, this is arguably the best place for most of our data to be. Building a culture of trust requires trust.
- Translucent – data here shouldn’t be seen by everyone, but still puts us closer to trust. This level greys out the information and gives a link to a point of contact who can help determine if it’s ok to share the information. Especially if the layer is not seen by many, but may have additional need or be found as others are navigating, this is a good means to open permissions wider without feeling completely exposed. *Note: with this point of contact it’s best to have inquiries go to a group mailbox with understood primaries for correspondence and cross coverage for absence. May take a bit to get used to the interest generated.
- Opaque – for no one else aside from the people working with the data. The scorecard for these will be blank, albeit the fields still exist for those who operate using the layer. This is for data that truly shouldn’t belong to anyone else and by no means is that a slight against the data there.
Various layers can be built well if we keep these and similar considerations in mind. Keep in mind these layers of data and order when adding to the overall map. Putting in roads before we have a general topography will tell us where the roads intersect, but will struggle in telling us where they go.
2 thoughts on “Layering Knowns”
Pingback: Cyber Archipelago – Maelstrom Advantage
Pingback: On Internal Mapping (1) – Maelstrom Advantage
Comments are closed.