โซ
๐Ÿ‘‹ ๐Ÿ”ฆ ๐Ÿ”ฌ ๐Ÿงฌ โš™๏ธ ๐Ÿ”ฎ ๐Ÿ“‡ ๐Ÿ“›

Table of Contents

Verify

Triple System Analysis

PDF
I describe a solution that helps people collaboratively model, understand, operate and improve systems using local-first graph analysis that prioritizes human cognition over machine.
๐Ÿ™ Dedicated to Linda, Janssen, and Todd

โš ๏ธโš ๏ธโš ๏ธ Please note that this work is incomplete, full of errors, and changes daily. I will remove this notice when I am done. โš ๏ธโš ๏ธโš ๏ธ

Introduction

Where are we? Where would we like to go? How do we get there? These questions seem simple enough, but they are difficult to answer as the world streams by like a giant movie on the screen of our perception. We are aware that the systems we create interact negatively with the biosphere, but our cognition is limited. We use reporting and AI/ML to understand our telemetry, gauge system function, and predict our course; however, this does not address our goals and choices from a human perspective. Besides the overwhelming amount of data, our cognition of streams is hijacked by advertising and culture. The โ€œbillboard on the side of the road that screams reassurance that whatever you are doing is okayโ€ works. Smoking is okay in the present, until the outcome of our choices catches up with us. (Collins 2015) (Taylor, Alan 2007) How do we determine our telemetry and goals as humans within extremely complex, nested systems? How do we establish the meaning of the hijacked movie we are in?

A screenplay can be understood by humans. Actors read the screenplay to see if it is something they are interested in. It is a re-usable document that helps humans cognitively understand the movie enough to participate. It captures just enough knowledge to express the ideas as a movie. Creation of a movie depends on casting, the imagination and technique of the director, as well as technical resources available. A screenplay does this by working within established meaning and conventions. It is possible to insert scenes and modify characters easily. As stakeholders in the systems that we rely on, what is our equivalent screenplay?

AI/ML and business intelligence tools running against the finished movie, metaphor or literal, can identify the actors and items in various scenes. They can categorize the props to recreate the scene with other actors superimposed. They can map the flow of the movie against theater and consumer behavior data to predict the amount of popcorn that viewers decide to skip out and buy during the scene. Much of the knowledge, though, is not recoverable from the surface movie with AI/ML. It is quite likely that the pauses, awkward moments, and humor will be lost on our models. We lose the original intent and the beauty of the way that the director, actors, and crew created the movie from the screenplay. This gets at the human of interest and effort underneath the stream. How do we emerge from the streams of daily demands and unconscious forces that hold us down cognitively? How do we became directly engaged as humans, choosing our activity with agency towards agreed-on goals in a collaborative way? My solution is Triple System Analysis.

Triples

I discovered triples as I struggled to communicate about complicated systems with increasingly specialized engineers. I found that while I couldnโ€™t find anybody who could answer questions about the overall system, it was relatively easy to establish small facts. Different people knew different facts. As I tried to visualize the facts in an automated way, I realized that the bioinformatics field had many tools that could help. This was also when I realized that my success with using data flow as a model was related. Triples form facts with a particular convention.

ObjectPredicateSubjectmonitor has_resolution 2048 X 1080

A triple can be illustrated by โ€œmonitor has_resolution 2048X1080โ€. The โ€œFather of Pragmatismโ€, Charles Peirce, came up with triples in the nineteenth century. (Bergman 2018) Triples are composed as a subject, predicate, and object. Triples decompose complicated systems into small facts that can be easily established and collaborated on iteratively. They can be assembled to visualize a broader perspective, yet still be agile enough for tactical response. More importantly, from my perspective, is that those small facts can be understood cognitively, and then treated as an atom in broader knowledge.

Stream perspectives, while important, are usually not conducive to authoring a screen play. An event stream has a timestamp and associated data that corresponds to that time. The individual event might have a single one-off plain text log entry, or it might have structured data in the form of JSON or key-value pairs. Knowledge of a system based on streams relies on external expertise, a model in the intelligence tool that forms the streams around it for cognition. This is a form of black box modeling. Realistically, we have a massive demand for stream analysis. We have a corresponding pool of people that are focusing on stream analysis for their jobs. The goal seems to be to model a human mind to get cognition of flows like human speech and ideas in real time, or autonomous vehicles, or what lever to trigger at what time to make the most wealth. I donโ€™t see people strive, as Donella Meadows urges, to help humans understand systems they rely on without compute. (Meadows, Donella 1977) This brings us back to the three questions. Where are we? Where would we like to go? How do we get there? I am fine with validating my answers with terabytes of streams and various models; however, I want to answer those questions cognitively, at a prudent and possible level as a human, as a stakeholder in the biosphere. Please donโ€™t worry. For those of you looking for a technical presentation of how to visualize systems with triples, I promise I will deliver code and graphs of fury. ๐Ÿฅ‹

Triple System Analysis

Iโ€™ve used the metaphor of the screenplay to help imagine a different way of looking at knowledge from a human cognition perspective, but how are triples related? Triples can be assembled as a graph. The entire World Wide Web is a giant graph made of triples. Intention is important. If I make the correlation โ€œMy cat is a calicoโ€ and create a link to a website about calico cats, I am creating a triple intentionally. This is where identity plays into SEO. If Iโ€™m curious what the original author thinks intentionally, this is an entirely different problem than if Iโ€™m trying to find out what the best website on the internet is for calico cats. A search engine establishes rank based on the broader graph of all links for calico cats and what links to where in a weighted graph of connections. My method focuses on stakeholders establishing their telemetry via agile maps, a screenplay that can be quickly assembled to facilitate resilience during crises. After I explain triple system analysis (3SA), I will lay out requirements for resilience, which is the goal of the solution I describe.

Letโ€™s start with these four sentences: Tigers eat cats. Cats eat rats. Cats eat mice. Mice eat cheese. These are triple, and can be represented with this graph:

eatstigerstigerscatscatstigers->catsratsratscats->ratsmicemicecats->micecheesecheesemice->cheese

Emoji are easier to recognize:

๐Ÿ…๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿˆ
๐Ÿˆ๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ€
๐Ÿˆ๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ
๐Ÿ๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿง€

๐Ÿ”น delimits the predicate, either a primary relation or other predicates listed in design.

Here is the graph with emoji:

eats๐Ÿ…๐Ÿ…๐Ÿˆ๐Ÿˆ๐Ÿ…->๐Ÿˆ๐Ÿ€๐Ÿ€๐Ÿˆ->๐Ÿ€๐Ÿ๐Ÿ๐Ÿˆ->๐Ÿ๐Ÿง€๐Ÿง€๐Ÿ->๐Ÿง€

Notice the flow direction. Cheese flows through mice to tigers. The relation direction doesnโ€™t correspond to flow direction, necessarily. We are doing what Barry Smith would describe as scruffy, perhaps with a superlative or two. (Smith 2001) The graph can prompt questions, like โ€œWhat does the rat eat?โ€ or โ€œIf the cheese is poisoned, what animals might be affected?โ€. The fact that we donโ€™t have anything for the rat to eat on the graph doesnโ€™t invalidate the graph. We can add what the rat eats as we learn. Likewise, the fact that a mouse eats peanut butter off of our traps doesnโ€™t invalidate the fact that the mouse eats cheese. We can also do some inference, in that the tiger might well be eating cheese. If the cheese was poisoned, we could follow the graph to see what animals would be affected. The important thing to notice is that these small facts, a triple, can be added at any time to the model. We could add ๐Ÿ… ๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ– later on, if we discovered that tigers ate pigs.

What Compute Needs

Letโ€™s analyze a larger system with triples to demonstrate how they work. Consider what modern compute needs at a high level.

๐Ÿ’ป๏ธ โฌ…๏ธ ๐Ÿ—๏ธ โ–ซ ๐Ÿ’ป๏ธ โฌ…๏ธ ๐Ÿญ๏ธ โ–ซ ๐Ÿ’ป๏ธ โฌ…๏ธ ๐Ÿšข
๐Ÿ’ป๏ธ โฌ…๏ธ ๐ŸงŠ โ–ซ ๐Ÿ’ป๏ธ โฌ…๏ธ ๐Ÿง โ–ซ ๐Ÿ’ป๏ธ โฌ…๏ธ โšก๏ธ

Compute needs to be constructed and manufactured using globally distributed parts. Compute needs to be cooled, and needs humans and electricity to operate. These are fairly straightforward facts. Triples can be written in many forms, most of which are optimized for machines. We are optimizing our analysis for human cognition, so using emoji has benefits. It is easy to picture the relations in this graph:

Compute Needs๐Ÿ’ป๏ธ๐Ÿ’ป๏ธ๐Ÿ—๏ธ๐Ÿ—๏ธ๐Ÿ’ป๏ธ->๐Ÿ—๏ธ๐Ÿญ๏ธ๐Ÿญ๏ธ๐Ÿ’ป๏ธ->๐Ÿญ๏ธ๐Ÿšข๐Ÿšข๐Ÿ’ป๏ธ->๐Ÿšข๐ŸงŠ๐ŸงŠ๐Ÿ’ป๏ธ->๐ŸงŠ๐Ÿง๐Ÿง๐Ÿ’ป๏ธ->๐Ÿงโšก๏ธโšก๏ธ๐Ÿ’ป๏ธ->โšก๏ธ

We donโ€™t have to toss established knowledge to build out perspective. For instance, say we want to distinguish local transport from global. We could add ๐Ÿ’ป๏ธ โฌ…๏ธ ๐Ÿšš to show that compute uses local transport. The fact that some compute requires local transport does not negate the fact that some compute requires global transport. Perhaps we want to add that not all global shipping is necessarily based on oil. We want to allow for efforts like the Porrima or even good old fashion sailboats. (MS Porrima 2022) No problem, just add ๐Ÿ’ป๏ธ โฌ…๏ธ โ›ต๏ธ and ๐Ÿšขโฌ…๏ธโšก๏ธ. If we want to account for the fact that cooling compute in datacenters requires water and electricity, that construction, transport, and manufacturing require oil and electricity, and allow for photovoltaic arrays, we can add these eleven triples:

๐ŸงŠโฌ…๏ธ๐Ÿ’ง โ–ซ ๐ŸงŠโฌ…๏ธโšก๏ธ โ–ซ ๐Ÿššโฌ…๏ธโšก๏ธ
๐Ÿ—๏ธโฌ…๏ธโšก๏ธ โ–ซ ๐Ÿญ๏ธโฌ…๏ธโšก๏ธ โ–ซ ๐Ÿ—๏ธโฌ…๏ธ๐Ÿ›ข๏ธ
๐Ÿššโฌ…๏ธ๐Ÿ›ข โ–ซ ๐Ÿญ๏ธโฌ…๏ธ๐Ÿ›ข๏ธ โ–ซ ๐Ÿšขโฌ…๏ธ๐Ÿ›ข๏ธ
โšก๏ธโฌ…๏ธโ˜€๏ธ โ–ซ โšก๏ธโฌ…๏ธ๐Ÿ›ข๏ธ

Here is the resulting graph:

Compute Needs๐Ÿญ๏ธ๐Ÿญ๏ธ๐Ÿ—๏ธ๐Ÿ—๏ธ๐Ÿญ๏ธ->๐Ÿ—๏ธโšก๏ธโšก๏ธ๐Ÿญ๏ธ->โšก๏ธ๐Ÿ›ข๏ธ๐Ÿ›ข๏ธ๐Ÿญ๏ธ->๐Ÿ›ข๏ธ๐Ÿ—๏ธ->โšก๏ธ๐Ÿ—๏ธ->๐Ÿ›ข๏ธ๐Ÿšš๐Ÿšš๐Ÿšš->๐Ÿ—๏ธ๐Ÿšš->โšก๏ธ๐Ÿšš->๐Ÿ›ข๏ธ๐Ÿšข๐Ÿšข๐Ÿšข->๐Ÿ—๏ธ๐Ÿšข->โšก๏ธ๐Ÿšข->๐Ÿ›ข๏ธ๐Ÿ’ป๏ธ๐Ÿ’ป๏ธ๐Ÿ’ป๏ธ->๐Ÿญ๏ธ๐Ÿ’ป๏ธ->๐Ÿ—๏ธ๐Ÿ’ป๏ธ->๐Ÿšš๐Ÿ’ป๏ธ->๐Ÿšข๐ŸงŠ๐ŸงŠ๐Ÿ’ป๏ธ->๐ŸงŠ๐Ÿ’ป๏ธ->โšก๏ธ๐Ÿง๐Ÿง๐Ÿ’ป๏ธ->๐Ÿงโ›ต๏ธโ›ต๏ธ๐Ÿ’ป๏ธ->โ›ต๏ธ๐Ÿ’ง๐Ÿ’ง๐ŸงŠ->๐Ÿ’ง๐ŸงŠ->โšก๏ธโšก๏ธ->๐Ÿ›ข๏ธโ˜€๏ธโ˜€๏ธโšก๏ธ->โ˜€๏ธ

Letโ€™s imagine that while we are building out our model of what compute needs, that another group is building out a model of what humans need. This is an important aspect of 3SA. The graphs can be combined. Formal ontologies exist so that the meaning of the triples is agreed on. (ISO/IEC 21838-2 2020) The problem is that this is in conflict with human cognition. It doesnโ€™t have to be a big problem, as long as we are aware of it going in. Iโ€™ll show you what I mean.

What Humans Need

Consider what humans need. Here is a list of triples followed by an explanation (โ†˜๏ธ):

๐Ÿง โฌ…๏ธ ๐ŸŒก๏ธ โ–ซ ๐Ÿง โฌ…๏ธ ๐Ÿšฐ โ–ซ ๐Ÿง โฌ…๏ธ ๐Ÿฅ
๐Ÿง โฌ…๏ธ ๐Ÿฒ โ–ซ ๐ŸŒก๏ธ โฌ…๏ธ ๐Ÿ  โ–ซ ๐Ÿ  โฌ…๏ธ ๐Ÿ—๏ธ

โ†˜๏ธ ย  Humans need a certain temperature to live, potable water, medical care, and prepared food. Shelter is needed for humans to maintain tolerable temperatures, and this shelter needs to be constructed.

๐Ÿฒ โฌ…๏ธ ๐Ÿ„ โ–ซ โšก๏ธ โฌ…๏ธ ๐Ÿ›ข๏ธ โ–ซ ๐Ÿšš โฌ…๏ธ ๐Ÿ—๏ธ
๐Ÿฒ โฌ…๏ธ ๐ŸŒฑ โ–ซ ๐Ÿšš โฌ…๏ธ โšก๏ธ โ–ซ ๐Ÿ—๏ธ โฌ…๏ธ โšก๏ธ

โ†˜๏ธ ย  Prepared food for humans comes from animal and plant sources. Construction and transport need electricity, which is provided by oil. Transport needs to be constructed.

โšก๏ธ โฌ…๏ธโ˜€๏ธ โ–ซ ๐Ÿ„ โฌ…๏ธ ๐ŸŒฑ โ–ซ ๐Ÿ—๏ธ โฌ…๏ธ ๐Ÿง
๐ŸŒฑ โฌ…๏ธ ๐Ÿ’ฉ โ–ซ ๐ŸŒฑ โฌ…๏ธ ๐ŸŒŠ โ–ซ ๐Ÿ’ฉ โฌ…๏ธ ๐Ÿ›ข๏ธ

โ†˜๏ธ ย  Electricity can also come from the sun. Animals eat plants, and processed food comes from plants. Construction needs humans. Plants need fertilizer and water. Fertilizer comes from oil.

๐Ÿ’ฉ โฌ…๏ธ ๐Ÿ„ โ–ซ ๐Ÿ’ฉ โฌ…๏ธ ๐Ÿง โ–ซ ๐Ÿฒ โฌ…๏ธ ๐Ÿšฐ
๐Ÿ’Š โฌ…๏ธ โšก๏ธ โ–ซ ๐Ÿšฐ โฌ…๏ธ ๐ŸŒŠ โ–ซ ๐Ÿšฐ โฌ…๏ธ ๐Ÿ—๏ธ

โ†˜๏ธ ย  Fertilizer can also come from animals or humans. Drugs need electricity. Potable water is sourced from rivers, lakes, springs, and groundwater. Processed food needs potable water, which needs constructed infrastructure to operate.

๐Ÿฅ โฌ…๏ธ ๐Ÿ’Š โ–ซ ๐Ÿฅ โฌ…๏ธ ๐Ÿง โ–ซ ๐Ÿ’Š โฌ…๏ธ ๐Ÿ›ข๏ธ
๐Ÿ’Š โฌ…๏ธ ๐Ÿšš โ–ซ ๐Ÿฅ โฌ…๏ธ ๐Ÿ›ข๏ธ โ–ซ ๐Ÿ  โฌ…๏ธ ๐Ÿ›ข๏ธ

โ†˜๏ธ ย  Medical care needs drugs, people, and oil. Drugs need oil and transport. Shelter needs oil for heating as well as components.

๐Ÿšฐ โฌ…๏ธ ๐Ÿ›ข๏ธ โ–ซ ๐Ÿ’Š โฌ…๏ธ ๐ŸŒฑ โ–ซ ๐Ÿ—๏ธ โฌ…๏ธ ๐Ÿ›ข๏ธ
๐Ÿง โฌ…๏ธ ๐ŸŒฑ โ–ซ ๐ŸŒฑ โฌ…๏ธ ๐ŸŒก๏ธ โ–ซ ๐Ÿšฐ โฌ…๏ธ โšก๏ธ

โ†˜๏ธ ย  Construction and potable water infrastructure needs oil. Potable water distribution needs electricity. Humans can eat plants directly, unprocessed. Drugs are made from plants. Plants need particular temperature ranges to germinate and thrive.

๐Ÿฒ โฌ…๏ธ โšก๏ธ โ–ซ ๐Ÿฒ โฌ…๏ธ ๐Ÿ›ข๏ธ โ–ซ ๐Ÿฒ โฌ…๏ธ ๐Ÿšš
๐ŸŒฑ โฌ…๏ธ โ˜€๏ธ โ–ซ ๐Ÿšš โฌ…๏ธ ๐Ÿ›ข๏ธ โ–ซ ๐Ÿ—๏ธ โฌ…๏ธ ๐Ÿšš

โ†˜๏ธ ย  Processed food needs electricity oil, and transport. Plants need sun. Transport need oil, and construction needs transport.

๐Ÿฅ โฌ…๏ธ ๐Ÿ—๏ธ โ–ซ ๐Ÿฅ โฌ…๏ธ ๐Ÿšš โ–ซ ๐Ÿฅ โฌ…๏ธ ๐Ÿšฐ
๐Ÿ  โฌ…๏ธ ๐Ÿšš โ–ซ ๐Ÿง โฌ…๏ธ ๐Ÿง โ–ซ ๐Ÿ—๏ธ โฌ…๏ธ ๐Ÿ—๏ธ

โ†˜๏ธ ย  Medical facilities need to be constructed, and also need potable water and transport. Shelter needs transport. Humans need humans to reproduce, and construction equipment is created with construction equipment.

We might argue a bit about whether a hospital is needed, but in our current civilization, this is reasonable. Likewise, in some societies transport is not needed to build a shelter. The advantage of this form of analysis is that the individual triples are relatively easy to agree on. Do we need oil for construction? Are drugs made with oil? This can be verified by experts to the satisfaction of those who are evaluating the system. If there is conflicting information, mark it as such and/or donโ€™t include. The triples can be assembled as a graph for visualization as the model is built out, which facilitates collaboration. Here is what the graph looks likes:

Human Needs๐Ÿง๐Ÿง๐Ÿง->๐Ÿง๐ŸŒก๏ธ๐ŸŒก๏ธ๐Ÿง->๐ŸŒก๏ธ๐Ÿšฐ๐Ÿšฐ๐Ÿง->๐Ÿšฐ๐Ÿฅ๐Ÿฅ๐Ÿง->๐Ÿฅ๐Ÿฒ๐Ÿฒ๐Ÿง->๐Ÿฒ๐ŸŒฑ๐ŸŒฑ๐Ÿง->๐ŸŒฑ๐Ÿ ๐Ÿ ๐ŸŒก๏ธ->๐Ÿ ๐Ÿ—๏ธ๐Ÿ—๏ธ๐Ÿšฐ->๐Ÿ—๏ธโšก๏ธโšก๏ธ๐Ÿšฐ->โšก๏ธ๐Ÿ›ข๏ธ๐Ÿ›ข๏ธ๐Ÿšฐ->๐Ÿ›ข๏ธ๐ŸŒŠ๐ŸŒŠ๐Ÿšฐ->๐ŸŒŠ๐Ÿฅ->๐Ÿง๐Ÿฅ->๐Ÿšฐ๐Ÿฅ->๐Ÿ—๏ธ๐Ÿšš๐Ÿšš๐Ÿฅ->๐Ÿšš๐Ÿฅ->๐Ÿ›ข๏ธ๐Ÿ’Š๐Ÿ’Š๐Ÿฅ->๐Ÿ’Š๐Ÿฒ->๐Ÿšฐ๐Ÿฒ->๐Ÿšš๐Ÿ„๐Ÿ„๐Ÿฒ->๐Ÿ„๐Ÿฒ->๐ŸŒฑ๐Ÿฒ->โšก๏ธ๐Ÿฒ->๐Ÿ›ข๏ธ๐Ÿ ->๐Ÿ—๏ธ๐Ÿ ->๐Ÿšš๐Ÿ ->๐Ÿ›ข๏ธ๐Ÿ—๏ธ->๐Ÿง๐Ÿ—๏ธ->๐Ÿ—๏ธ๐Ÿ—๏ธ->๐Ÿšš๐Ÿ—๏ธ->โšก๏ธ๐Ÿ—๏ธ->๐Ÿ›ข๏ธ๐Ÿšš->๐Ÿง๐Ÿšš->๐Ÿ—๏ธ๐Ÿšš->โšก๏ธ๐Ÿšš->๐Ÿ›ข๏ธ๐Ÿ„->๐ŸŒฑ๐ŸŒฑ->๐ŸŒก๏ธโ˜€๏ธโ˜€๏ธ๐ŸŒฑ->โ˜€๏ธ๐Ÿ’ฉ๐Ÿ’ฉ๐ŸŒฑ->๐Ÿ’ฉ๐ŸŒฑ->๐ŸŒŠโšก๏ธ->๐Ÿ›ข๏ธโšก๏ธ->โ˜€๏ธ๐Ÿฆ–๐Ÿฆ–๐Ÿ›ข๏ธ->๐Ÿฆ–๐Ÿ’ฉ->๐Ÿง๐Ÿ’ฉ->๐Ÿ„๐Ÿ’ฉ->๐Ÿ›ข๏ธ๐Ÿ’Š->๐Ÿšš๐Ÿ’Š->๐ŸŒฑ๐Ÿ’Š->โšก๏ธ๐Ÿ’Š->๐Ÿ›ข๏ธ

If we decide that we will only consider transport that gets electricity from the sun, then we still have quite a few other problems to address. The graph helps put things in perspective, and facilitates human cognition of the system.

Compute and Humans

Back to our scenario with what compute needs. โ˜€๏ธ๐Ÿ›ข๏ธ๐Ÿง๐Ÿ—๏ธโšก๏ธ๐Ÿšš have the same meaning and use the same symbol. ๐ŸŒก๏ธ=๐ŸงŠ, ๐ŸŒŠ=๐Ÿ’ง, and ๐Ÿšš on human needs could be either ๐Ÿšข or ๐Ÿšš. If we combined the graphs with the translation for ๐ŸŒก๏ธand ๐ŸŒŠ, we get this graph:
Compute Human Needs๐Ÿญ๏ธ๐Ÿญ๏ธ๐Ÿ—๏ธ๐Ÿ—๏ธ๐Ÿญ๏ธ->๐Ÿ—๏ธโšก๏ธโšก๏ธ๐Ÿญ๏ธ->โšก๏ธ๐Ÿ›ข๏ธ๐Ÿ›ข๏ธ๐Ÿญ๏ธ->๐Ÿ›ข๏ธ๐Ÿ—๏ธ->๐Ÿ—๏ธ๐Ÿšš๐Ÿšš๐Ÿ—๏ธ->๐Ÿšš๐Ÿ—๏ธ->โšก๏ธ๐Ÿง๐Ÿง๐Ÿ—๏ธ->๐Ÿง๐Ÿ—๏ธ->๐Ÿ›ข๏ธ๐Ÿšข๐Ÿšข๐Ÿšข->๐Ÿ—๏ธ๐Ÿšข->โšก๏ธ๐Ÿšข->๐Ÿ›ข๏ธ๐Ÿ’ป๏ธ๐Ÿ’ป๏ธ๐Ÿ’ป๏ธ->๐Ÿญ๏ธ๐Ÿ’ป๏ธ->๐Ÿ—๏ธ๐Ÿ’ป๏ธ->๐Ÿšข๐Ÿ’ป๏ธ->๐Ÿšš๐ŸงŠ๐ŸงŠ๐Ÿ’ป๏ธ->๐ŸงŠ๐Ÿ’ป๏ธ->โšก๏ธ๐Ÿ’ป๏ธ->๐Ÿงโ›ต๏ธโ›ต๏ธ๐Ÿ’ป๏ธ->โ›ต๏ธ๐Ÿšš->๐Ÿ—๏ธ๐Ÿšš->โšก๏ธ๐Ÿšš->๐Ÿง๐Ÿšš->๐Ÿ›ข๏ธ๐Ÿ’ง๐Ÿ’ง๐ŸงŠ->๐Ÿ’ง๐ŸงŠ->โšก๏ธ๐Ÿ ๐Ÿ ๐ŸงŠ->๐Ÿ โšก๏ธ->๐Ÿ›ข๏ธโ˜€๏ธโ˜€๏ธโšก๏ธ->โ˜€๏ธ๐Ÿง->๐ŸงŠ๐Ÿง->๐Ÿง๐Ÿšฐ๐Ÿšฐ๐Ÿง->๐Ÿšฐ๐Ÿฅ๐Ÿฅ๐Ÿง->๐Ÿฅ๐Ÿฒ๐Ÿฒ๐Ÿง->๐Ÿฒ๐ŸŒฑ๐ŸŒฑ๐Ÿง->๐ŸŒฑ๐Ÿฆ–๐Ÿฆ–๐Ÿ›ข๏ธ->๐Ÿฆ–๐Ÿšฐ->๐Ÿ—๏ธ๐Ÿšฐ->๐Ÿ’ง๐Ÿšฐ->โšก๏ธ๐Ÿšฐ->๐Ÿ›ข๏ธ๐Ÿฅ->๐Ÿ—๏ธ๐Ÿฅ->๐Ÿšš๐Ÿฅ->๐Ÿง๐Ÿฅ->๐Ÿ›ข๏ธ๐Ÿฅ->๐Ÿšฐ๐Ÿ’Š๐Ÿ’Š๐Ÿฅ->๐Ÿ’Š๐Ÿฒ->๐Ÿšš๐Ÿฒ->โšก๏ธ๐Ÿฒ->๐Ÿ›ข๏ธ๐Ÿฒ->๐Ÿšฐ๐Ÿ„๐Ÿ„๐Ÿฒ->๐Ÿ„๐Ÿฒ->๐ŸŒฑ๐Ÿ ->๐Ÿ—๏ธ๐Ÿ ->๐Ÿšš๐Ÿ ->๐Ÿ›ข๏ธ๐Ÿ„->๐ŸŒฑ๐ŸŒฑ->๐ŸงŠ๐ŸŒฑ->๐Ÿ’ง๐ŸŒฑ->โ˜€๏ธ๐Ÿ’ฉ๐Ÿ’ฉ๐ŸŒฑ->๐Ÿ’ฉ๐Ÿ’ฉ->๐Ÿง๐Ÿ’ฉ->๐Ÿ›ข๏ธ๐Ÿ’ฉ->๐Ÿ„๐Ÿ’Š->๐Ÿšš๐Ÿ’Š->โšก๏ธ๐Ÿ’Š->๐Ÿ›ข๏ธ๐Ÿ’Š->๐ŸŒฑ
There are a few semantic issues here. We say that maintaining a certain temperature range requires water. While this is currently reasonable for most datacenters, it is less so for cooling humans. Humans do need water for other primary reasons. The main point I want to make, though, is that as a human trying to understand related systems, the map of compute and human needs is roughly as complicated as you can get and still take it in with a viewing. I am tackling a narrow part of visualization and cognition. There are ontologies for many of these entities, but they would be too cumbersome to lay out in the way we have here. (Ong et al. 2017) The main reason why I started to look at these methods, though, was analyzing IT systems and data flow, and there is value to formal versions of this. The data flow ontology isnโ€™t too complicated to have both a cognitive, single-serving view, yet still have machine cognition and a formal, agreed-on method of analysis. (Debruyne et al. 2019)

Structured System Analysis

Structured System Analysis was refined in the 1970s and 1980s as a way to analyze systems, primarily around data flow diagrams (DFDs). It uses three symbols and some conventions for connecting them to make data flow diagrams. (Gane and Sarson 1977) (Yourdon 1989) Think of this as a vertical, dumbed down version of graph analysis. The beautiful thing, though, is that the methods apply to any IT system. ๐ŸŽ† ๐ŸŽ‰ IT stores, transforms, and reports on information. Before most in compute called their profession IT, they called it IS, information systems, which is more appropriate. What we really care about isnโ€™t the technology, it is the information and the system that stores, transforms, and reports on it, no matter what the transforms are, AI or not. This, folks, is our screenplay for IT systems. ๐Ÿป After that, Iโ€™ll look more at the design of triple system analysis, including requirements for resilience.

While different authors choose different symbols to represent the nodes of DFDs, structured system analysis consists of:

๐Ÿ‘ค External Entity (Entity)
This is a source or destination of data. It might be a person, or a group of people, or even sensors.

โš—๏ธ Process
This transforms data from one form to another.

๐Ÿ’ฝ Data Store
This stores data at rest. It might be a stack of paper in a folder or a disk drive. Here is a small diagram that illustrates a data flow:

โš—๏ธ๐Ÿ”ธ1BugScan๐Ÿ’ฝ๐Ÿ”ธ1BugScanDB๐Ÿ‘ค๐Ÿ”ธQAQA

QA uses the BugScan application to check for bugs. The data is stored in the BugScan database. Here is a set of triples for this diagram:

0๐Ÿ”ธ๐Ÿ‘ค๐Ÿ”ธQA๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นQA
0๐Ÿ”ธโš—๏ธ๐Ÿ”ธ1๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นBugScan
0๐Ÿ”ธ๐Ÿ’ฝ๐Ÿ”ธ1๐Ÿ”น๐Ÿท๐Ÿ”นBugScan DB
0๐Ÿ”ธโš—๏ธ๐Ÿ”ธ1๐Ÿ”นโ†”๏ธ๐Ÿ”น๐Ÿ‘ค๐Ÿ”ธQA
0๐Ÿ”ธโš—๏ธ๐Ÿ”ธ1๐Ÿ”นโ†”๏ธ๐Ÿ”น๐Ÿ’ฝ๐Ÿ”ธ1

Here is a top level (0) of a DFD:
โš—๏ธ๐Ÿ”ธ1AccountingServices๐Ÿ‘ค๐Ÿ”ธAcctAccounting๐Ÿ’ฝ๐Ÿ”ธ1HQDigitalData๐Ÿ‘ค๐Ÿ”ธCustACMECustomersโš—๏ธ๐Ÿ”ธ2CustomerServices๐Ÿ‘ค๐Ÿ”ธOpsOperations๐Ÿ‘ค๐Ÿ”ธLeadsCustomerLeadsโš—๏ธ๐Ÿ”ธ3PartnerServices๐Ÿ‘ค๐Ÿ”ธHospPHospitalSupplyPartner๐Ÿ’ฝ๐Ÿ”ธ2HQAlternateMedia๐Ÿ‘ค๐Ÿ”ธOOpsOceanicOperations๐Ÿ‘ค๐Ÿ”ธShipShippingandLogistics๐Ÿ‘ค๐Ÿ”ธEnvMEnvironmentalMeasurementsโš—๏ธ๐Ÿ”ธ4CustomerSupport๐Ÿ‘ค๐Ÿ”ธCstSCustomerSupportโš—๏ธ๐Ÿ”ธ5Telephonicโš—๏ธ๐Ÿ”ธ6CustomerRelationshipManager๐Ÿ‘ค๐Ÿ”ธFldSFieldSales๐Ÿ‘ค๐Ÿ”ธSalesMarketingandSalesโš—๏ธ๐Ÿ”ธ8ProductAcceptanceโš—๏ธ๐Ÿ”ธ7Field Salesโš—๏ธ๐Ÿ”ธ10OperationalIntelligenceandManagement๐Ÿ‘ค๐Ÿ”ธEngInEngineeringIndia๐Ÿ‘ค๐Ÿ”ธPrdctProductTeam๐Ÿ’ฝ๐Ÿ”ธ3ProductDevelopment๐Ÿ‘ค๐Ÿ”ธEngUSEngineeringUSAโš—๏ธ๐Ÿ”ธ9BusinessIntelligenceandManagement๐Ÿ‘ค๐Ÿ”ธExecsExecutivesโš—๏ธ๐Ÿ”ธ11ProductDevelopment
If we expand process 6, our view is entirely within Customer Relationship Manager:
โš—๏ธ๐Ÿ”ธ1SnailMailImport๐Ÿ‘ค๐Ÿ”ธCentACentralAdministrationServices๐Ÿ‘ค๐Ÿ”ธMailRMailRoomStaff๐Ÿ’ฝ๐Ÿ”ธ5ReturnedCards๐Ÿ’ฝ๐Ÿ”ธ2LeadAddresses๐Ÿ’ฝ๐Ÿ”ธ7LeadActivityโš—๏ธ๐Ÿ”ธ2BillingIntegrationโš—๏ธ๐Ÿ”ธ9A-Rโš—๏ธ๐Ÿ”ธ7BulkCardPrintโš—๏ธ๐Ÿ”ธ3MailRoomReceivingโš—๏ธ๐Ÿ”ธ4Mail๐Ÿ‘ค๐Ÿ”ธPOPostalEmployee๐Ÿ‘ค๐Ÿ”ธOLeadsOutsideLeads๐Ÿ’ฝ๐Ÿ”ธ3BulkCardsโš—๏ธ๐Ÿ”ธ5Monthly๐Ÿ‘ค๐Ÿ”ธMktMarketing๐Ÿ‘ค๐Ÿ”ธHQSalesHQSales๐Ÿ’ฝ๐Ÿ”ธ1Creativesโš—๏ธ๐Ÿ”ธ6Social Fanisizer๐Ÿ‘ค๐Ÿ”ธDigMktDigitalMarketing๐Ÿ‘ค๐Ÿ”ธContentHQContentโš—๏ธ๐Ÿ”ธ8ConstantEmailService๐Ÿ’ฝ๐Ÿ”ธ4A-RDatabaseโš—๏ธ๐Ÿ”ธ10ServiceBureauAPI๐Ÿ’ฝ๐Ÿ”ธ6ServiceBureauDatabaseโš—๏ธ๐Ÿ”ธ11Contractsโš—๏ธ๐Ÿ”ธ12Reporting

The view is important. When we are in a view, a node, the node opens up as a graph. It is a wormhole into the perspective of the specific group: the perspective of customer relationship manager, including social media and snail mail cards. Unless somebody is working directly with the Social Fanisizer, they donโ€™t need to know details, but they would need to understand that Lead Addresses are used by both the email service and Social Fanisizer. If we zoom into Social Fanisizer Here is the expanded 6 within 6, the Social Fanisizer process as a graph:

โš—๏ธ๐Ÿ”ธ1FanisizerCloud๐Ÿ’ฝ๐Ÿ”ธ1SuperCloudDatabase๐Ÿ’ฝ๐Ÿ”ธ2IdentityStorage๐Ÿ‘ค๐Ÿ”ธDigMktDigitalMarketing๐Ÿ‘ค๐Ÿ”ธSupCSuperCloudDatabaseSupport๐Ÿ’ฝ๐Ÿ”ธ3UserActivityFor Saleโš—๏ธ๐Ÿ”ธ2IdentiTroll๐Ÿ‘ค๐Ÿ”ธGMomGrandmothersandPeePaws๐Ÿ‘ค๐Ÿ”ธGovGovernmentLeaders๐Ÿ‘ค๐Ÿ”ธTrollsTrollFarmsand MeatTools๐Ÿ‘ค๐Ÿ”ธFodMudFodderandMudderโš—๏ธ๐Ÿ”ธ3AdTargetingEngineโš—๏ธ๐Ÿ”ธ4MediaOutlets

Iโ€™ve used DFDs without the automation at my work for almost a decade. Much of this solution description is based on that experience. It varies both from formal DFDs, but also from formal graph analysis. Unlike conventional graphs, hierarchical paths for the processes are a feature. Consider 0๐Ÿ”ธ6๐Ÿ”ธ11โ–ช๏ธโš—๏ธ๐Ÿ”ธ1๐Ÿ”นโ†”๏ธ๐Ÿ”น๐Ÿ‘ค๐Ÿ”ธCFO In Gane and Sarson this would show that process 6.11.1 has two-way dataflow with the CFO. The unique thing about 3SA is that the emoji visually show that meaning without needing to create symbols. The โ–ช๏ธ shows the level or graph. The level is 0๐Ÿ”ธ6๐Ÿ”ธ11, and is also a process ( 0๐Ÿ”ธ6โ–ช๏ธโš—๏ธ๐Ÿ”ธ11) at level 0๐Ÿ”ธ6, which fits with the intent of Gane and Sarson. I do not pull through meaning between levels. In the previous example of Social Fanisizer, for instance, I would expect those with detailed knowledge of that particular process, the graph at the node 0๐Ÿ”ธ6๐Ÿ”ธ6, to have a different understanding of their processes and datastores. There may well be overlap, but since this is about cognition, it is completely fine to only enforce process as the nesting mechanism. Everybody can agree that Social Fanisizer is part of the Customer Relationship Manager. The groups that provide and consume information from Fanisizer, from their perspective, will likely be much different than a view of the entire org, which be understood by anybody in the organization.

Requirements

Functional Requirements for Resilience

The primary goal 3SA is resilience. Resilience is a bit over-used, but it is still a great word. From a systems perspective, resilience is realized at time of failure. This makes it different than the typical system design aspects, as it requires light and quick reactions in a situation that is likely much different than when the system was originally designed. (Daniel 2014) As humans, we rely on many systems that we fear may collapse. We are stressing the biosphere with all that we do as a civilization, including our cloud compute. (Monserrate 2022) The specifics of what kind of crisesโ€™ we will face over the next few decades are less important than our ability to respond in a resilient way. Be very clear, here, that I donโ€™t see resilience as a synonym for business as usual without severe consequences. We have earned severe consequences, and can expect them. Likely the consequences and situation will be different than we forecast. What we do, how we respond at that point, determines our resilience. We have lots of humans that can help cognitively at time of crisis, and I believe these methods will help. What facilitates resilience from a system perspective? What do/will humans need to adapt systems at time of crisis? My thesis is that communication, meaning, knowledge, maps, collaboration, and streams form interrelated requirements for resilience:

๐ŸŒฑMeaningCommunication๐ŸŒฑResilienceKnowledgeMapsCollaborationStreams๐ŸŒŠ๐ŸŒณ๐Ÿง โ˜Ž๏ธ๐Ÿ—บ๏ธ๐ŸŒŠโ˜Ž๏ธ๐Ÿ‘ฅfacilitates๐ŸŒณ๐Ÿ‘ฅ๐Ÿง ๐Ÿ—บ๏ธ

Pivot to Triples

Normally a document like this is a taxonomy. There is a table of contents, and all of the requirements map to analysis, which maps to a design. The functional requirements all relate to each other in this case, so a mere taxonomy is not really sufficient. Narrative form is necessarily sequential, so it ends up being unwieldy, particularly for non-functional requirements.

This diagram shows the typical dance that system engineer or analyst might navigate for a new information system:

PerformanceCapacitySecurityExtensibilityCompatibilityManageabilityMaintainabilityDisaster RecoveryAvailabilityRPORTODataLogArchivingDataBackupLogRetentionScalabilityAgreed maintenance intervals/cadanceService Level AgreementBusinessLicensingClient Softwr.MemoryComputeStorageWeb ServersMemoryComputeStorageApp. ServersDatabase ServersServer Infra.DatabaseStorageCommunication Ports and ProtocolsNetworkingThird Party IntegrationsDependenciesMaintenanceEvent LoggingAlertingMonitoringTracing, Events and LogsAvailabilityBackup and RecoveryDisaster RecoveryService AccountsAuthenticationData at RestData in TransitAccessSecurityPrototyping and PilotingUser Acceptance TestingCutoverRollbackSunsettingCapacity and Latency** Requirements **** Design **

The problem with this method is around agility. The tools available to a system analyst do not provide sufficient software development velocity within rapidly changing systems and customer demands. A complicated system might take several months of analyst work to generate a 60 page document that nobody on the team has time to read. The conclusion at many organizations is to eliminate the system analyst role, and include it under software development as a task called a system design interview. (Martin 2023) (Schaffer,Erin 2023) System analysis should start with human requirements, rather than solutions, but often the task of system design falls into a particular platform, as a developer thinks in terms of tools and APIs that they are familiar with. While this does contribute to velocity, it also tends to be myopic. As an example, the eight fallacies of distributed computing should be addressed, but often isnโ€™t, because cloud is assumed. (Van Den Hoogen, Ingrid 2007) (Jausovec, Peter 2020) Involving cloud in the solution is likely the correct solution for an organization, but relying on a cloud software developer to imagine non-cloud solutions is unreasonable, and this breeds organizational blind spots. So, we are back to the same problem. How do we get velocity, as well as a broad system perspective that an analyst role can provide? My intention is not to invalidate the system design perspective that different developers might have. My intention is to align these perspectives across different roles with a collaborative method that attains a suitable velocity. Iโ€™m taking an any/all approach that is greased with triples and instant visualization of emerging intent and design. The challenge of this document, then, is to show how these functional requirements and non-functional requirements are reflected in a proposed system design. I will do this in semi-narrative form so that it can flow via a PDF; however, at the end there will also be an interactive artifact that utilizes the design.

This brings up another part of my experience with graph forms of analysis. All you really need is a toe-hold to start productive analysis. Because of the nature of graphs, once you get started, you can grow the analysis into a complete treatment. The reader should have enough triples so far to understand if we jump right in. Letโ€™s lay some down:

๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นCommunication
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”นโ†”๏ธ๐Ÿ”น๐ŸŒฑ๐Ÿ”ธ๐Ÿง 
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”นโ†”๏ธ๐Ÿ”น๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwho๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นWho
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwht๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นWhat
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธhow๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นHow
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwhr๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นWhere
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwhy๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นWhy
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿง ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นMeaning
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿง ๐Ÿ”นโ†”๏ธ๐Ÿ”น๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿง ๐Ÿ”ธvis๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นVisual and semantic standards
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นKnowledge
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”นโ†”๏ธ๐Ÿ”น๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”ธwht๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นWhat knowledge is crucial?
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”ธhow๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นHow do we retain knowledge?
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นMaps
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”นโ†”๏ธ๐Ÿ”น๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”ธqck๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นQuick to learn
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”ธstk๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นStakeholder visibility
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”ธeas๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นEasy to change
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”ธstd๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นStandard for area
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นCollaboration
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”นโ†”๏ธ๐Ÿ”น๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”ธcnt๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นAll may contribute
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”ธvld๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นAll may validate
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”ธact๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นAll may be accountable
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นStreams
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ๐Ÿ”ธqck๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นQuick system state updates
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ๐Ÿ”ธrpl๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นReplay

In graph terminology the root is ๐Ÿ’ก, this document, similar to level 0 in Gane and Sarson terminology. โœ…=requirements ๐Ÿง‘=functional ๐ŸŒฑ=resilience (There may be functional requirements that arenโ€™t necessarily because of resilience.) I use the convention of delimiting the path of node IDs with ๐Ÿ”ธ. The predicate is delimited with ๐Ÿ”น. The node IDs must each be unique. In this case, the path of the node forms the ID. Consider โ€œhowโ€. This is in both nodes โ€œ๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธhowโ€ and โ€œ๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”ธhowโ€. It is possible, and sometimes prudent to build graphs from triples where there is no meaning in the path. Some use Universally Unique IDentifiers (UUIDs). It is true that mistakes in the path are easier to fix than if the store is a relational database; however, you will break references with paths. In this case, the solution description has a fairly standard form, so there is little risk. Iโ€™ve probably written 100 of them. It is easier than the taxonomy of a Word document that relies on indents and font type to arrange the paths.

The document you are reading, the solution description, serves as a repository of the narrative for the nodes, so I wonโ€™t add those in. I will try not to repeat myself. If there is nothing of significance beyond the node labels (๐Ÿท๏ธ), I wonโ€™t add anything. So far, there are edges between the nodes that correspond to the green โ€œfacilitatesโ€ lines in the diagram. They are intentionally two way. There are other relationships between the nodes implied by the triskelion-like diagram center that I will write about later on. Iโ€™d like to add that it was accidental, or, at least, not a conscious decision to create such a nested rule-of-threes diagram. I simply outlined what I thought were the requirements for resilience with an agile system visualization and model. It all just fell into place with the diagram. Now that we have our triple pivot, letโ€™s continue on with narration about the functional requirements. This doubles as a demonstration, so if you donโ€™t understand, hopefully you will if you just follow along for awhile.

โœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”น๐Ÿท๐Ÿ”นCommunication

Wade through the mind-numbing muck of a corporate โ€œwhatโ€™s wrong with our groupโ€ exercise, and you will usually end up with the top ranking advice that better communication is needed. It may seem fruitless to spend all that time arriving at that conclusion every two years like clockwork, but it is still a core problem. Letโ€™s analyze what we mean by communication, in particular communication about systems in crisis. Mostly this involves representing and sharing the knowledge of who, what, how, where, and why with a two-way tight coupling with streams and meaning.

Who is working on what?
This needs to be established quickly. There should be no required integration or schema update. A unique ID is the only procedural/technical item that should be enforced. Association of the ID with a project or role, and any other metadata, should simply flow in the stream.

What changes have been made?
Changes to the system should be posted to streams and visualized in near real-time.

How does the system work?
There should be no limitation on the types of models besides being able to decompose the knowledge. The way that the system meaning is expressed should be flexible, as different people have different perspectives and experience.

โœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿง ๐Ÿ”น๐Ÿท๐Ÿ”น๏ธMeaning

There is no room for confusion about what is meant. If I am stuck in the rain and talking with you over an unstable connection, and I want you to know I am in Portland, I might use a standard phonetic alphabet and say โ€œPapa, Oscar, Romeo, Tango, Lima, Alfa, November, Deltaโ€. The phonetic alphabet has agreed-on meaning, and is designed so that when transmitted over a stream (radiotelephone), there is a low possibility for confusion over similarly sounding words. Meaning should be quickly established with visual queues when possible.

โœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”น๐Ÿท๐Ÿ”น๏ธKnowledge

There needs to be a mechanism to filter for crucial knowledge and to re-assemble for future, unforeseen views.

โœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นMaps

Quick to learn
There should be a minimal number of symbols on the map that requires less than a minute to learn. Stakeholder visibility
Different stakeholders have different needs for visualization.

Easy to change
Modifications to the underlying data should automatically adjust existing maps.

Standard for area
Consider standards that exist for mapping in the domain. (โ€œOpenStreetMap Carto/Symbols - OpenStreetMap Wikiโ€ n.d.)

โœ…๐Ÿ”ธ๐Ÿง‘ ๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นCollaboration

During collaboration, there should be minimal limitations on who can contribute. If any participant feels something is wrong with the system map being built collaboratively, it should be easy to capture. Likewise, if a particular proposition (triple) is verified by an agreed expert, than that should also be easy to capture. Focusing on the core knowledge first, rather than code, platform, frameworks or metal, facilitates collaboration from the start. Further, a focus on decomposed knowledge, coupled with immediate visualization, makes meetings more productive, since there is little delay between gathering knowledge and the visualized model. Decomposed knowledge streams (triples) only require a โ€œlockโ€ or merge on the triple itself. (Kleppmann et al. 2019) (Shapiro et al., n.d.) It is less likely that during collaboration one person will step on another. One person might change the title while somebody else is editing the description. The big win for collaboration is on multi-level data flow diagrams (DFDs), as different areas of expertise can collaborate concurrently to build the models.

โœ…๐Ÿ”ธ๐Ÿง‘ ๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นStreams

Streaming should leverage existing event stream mechanisms for insight. Replay of system changes should be able to be mapped both by timestamp and with queries against multiple streams and datasets.

โœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ Non-functional Requirements

Non-functional requirements are not measurable as application features, so they are often opaque from an agile user story perspective. As we all know, though, if the system is down, slow, or locks up; if the user loses data, these requirements all of a sudden become the most important aspects. There is also a bit of crystal ball reading involved with non-functional requirements. What kinds of things can happen? I mentioned the eight fallacies of distributed computing, but there are other more banal problems. For instance, if data is deleted in the system, intentionally, accidentally, or through malware, and isnโ€™t discovered for several months, then how is it recovered? Many backup systems do not account for this, yet it is a key part of RPO requirements. (Sharma 2020)

Here are the triples associated with the non-functional requirements (๐Ÿ–ฅ๏ธ) for 3SA:

๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธavl๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นAvailability
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธcap๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นCapacity
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธprf๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นPerformance
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธscl๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นScalability
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธext๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นExtensibility
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธmai๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นMaintainability
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธman๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นManageability
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธpor๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นPortability
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธrpo๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นRPO
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿ–ฅ๏ธ๐Ÿ”ธrto๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นRTO

Note that there is nothing sacred about emoji. Text is fine, and often a better choice if there are lots of aspects.

Availability
This system is intended to be used at time of crisis. This means that the non-functional requirements are extreme. Availability should be as many 9s as you can write. Since the data itself is the knowledge of the system, this is attainable. All you need is a copy of the data and something to render it with. There are more details in the analysis and design sections; however, availability is extreme.

Capacity
There should be no constraints on capacity. Since this is for human cognition of systems, the systems are relatively flat and not that dimensional. The stack of resulting triples, like availability, has no limits within the constraints of a system used for human cognition.

Performance
Updates from a change of knowledge atom should trigger an update in the visualization quick enough so it does not hinder the pace of collaboration.

Generating the visualizations takes significant compute. Any personal computer with an optimized graphics system from 2018 or later should be able to handle the graph visualizations, as should mainstream mobile phones.

Scalability
I am assuming human cognition, so this constrains the data. The main constraint on scalability is the complexity of the models. Like most of these aspects, there should be no technical limit as long as the data is constrained to human cognition. This means that it is critical that the types of models and schemas that are reasonable to tackle with these methods are made very clear. At what point should other methods be used?

Extensibility
There needs to be a path to machine cognition if the model becomes too large.

Maintainability
The system needs to be able to be modified at any time without disruption. There is no room to have users function as testers. The design of the quality assurance process is determined at initiation; however, the deployment and code simplicity should be such that disruption is unlikely. Further, user-initiated fall-back should be easy and obvious, a part of every effort.

Even when there are management tasks that need to be completed, like an update of a public certificate, this should not block use of the system at certain levels. As an example, in the case of a certificate that is out of date, there should be alternate paths of validation and transport available to users.

Manageability
This is a fully distributed system. The triples are distributed as single triples and deletion of relations. The software should be identical across installs, and without state tracked with anything but the triples themselves.

Portability
The core knowledge and visualizations should be viewable as-is with a modern phone or computer, 2022 forward, including Mac, Windows, or *NIX.

Recovery Point Objective (RPO)
The system should be able to be restored to the last atom of data gathered. Essentially this means there is zero tolerance. These methods are being used at times of crisis.

Recovery Time Objective (RTO)
The ability to view the current version of local data should never be disrupted. Operational loss of system is unacceptable at any level. This is facilitated via the portability requirements.

๐Ÿ”ฌ Analysis

We now have a set of requirements, and we need to analyze various options as we arrive at a proposed design. This is also where the open world assumption shines, as we can track the possible paths. We might choose one solution now, perhaps incurring technical debt, but if things change, we can choose a different path without having to re-discover the entire system. This is one of the pitfalls of complex systems that are entrenched in an organization, particularly with staff turnover. The only expedient way to change it is to toss out the entire thing and buy all new, often renting the service from a third party. 3SA can help with that by relating a design aspect, or even a particular screen on an operational system back through analysis and requirements without having to read a 60 page solution description. Just the (small) facts Maโ€™am (triples). (Mikkelson 2002)

๐Ÿ”ฌ๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นCommunication

With modern software application development methods, we can expect the system to work slightly differently every day in some cases. This is one of the reasons why monolithic documentation from waterfall methods is not tenable. There is a straw man with waterfall that an architect or analyst just tosses an artifact down the falls to the next group, and washes their hands. The waterfall idea was used as an example of maladaptive workflow. (Clift 2021) (Rovce 1970) Architects, analysts and developers have different perspectives, yes, but that doesnโ€™t mean that it is prudent to push everything on developers in order to liberate us from the perils of the waterfall. A user story is one way to capture a small item of concern, to change the design and quickly bring it through to product. The problem is that it is an isolated perspective. Some requirements are firm, and often in conflict with user stories. We are all familiar with the conflict of โ€œI want to see that data on my phoneโ€. Perhaps that is a good idea, but there are security, data convergence, and backup/recovery implications to this. We can interject roles into the workstream as cat herders, but what if these are captured as triples at the data level from the beginning? These can then be visualized as different perspectives of knowledge. We can re-use and track to intent, leveraging the perspective of multiple roles.

An alternative to having a holistic understanding of the complete system, and pulling through requirements to the workstream, is to use stream telemetry and intelligence software.

Why, who, what, where follow similar lines of thought. Agreed this can change at various velocities. All can be captured in streams, but tracking from intention has advantages, primarily, the knowledge from triples can be assembled into a broader set of knowledge through established meaning.

๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿง ๐Ÿ”ธvis๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นVisual and semantic standards
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ

๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwho๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธโ˜˜๏ธ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwht๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธโ˜˜๏ธ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธhow๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธโ˜˜๏ธ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwhr๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธโ˜˜๏ธ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwhy๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธโ˜˜๏ธ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwho๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwht๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธhow๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwhr๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธโœ…๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธโ˜Ž๏ธ๐Ÿ”ธwhy๐Ÿ”นโžก๏ธ๐Ÿ”น๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธ๐ŸŒŠ
๐Ÿ’ก๐Ÿ”ธ๐Ÿงฌ๐Ÿ”ธโ˜˜๐Ÿ”ธ๏ธasm๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นAssembled Knowledge

๐Ÿ”น๐Ÿท๏ธ๐Ÿ”น

๐Ÿงฌ=Design (DNA is used to render the design into a lifeform, rather than the actual design, but it works just fine as a symbol. Alternatively, like triples, perhaps the cumulative experience of living organism was captured in a self-replicating way. โ€œPeople get so hung up on specifics.โ€ (Cox, Alex 1984))

๐Ÿ”ฌ๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿง ๐Ÿ”น๐Ÿท๐Ÿ”น๏ธMeaning

One criticism, among many, about system analysis in general, is the problem of computability. We live within extremely complex, interrelated systems where humans and nature are involved. What is the meaning of something that is in constant change? My stance is that meaning is what we set out to do with the system. This fits between communication and knowledge. We communicate our intention with items of meaning that ratchet knowledge further. When we merely fall back to streams and AI/ML to evaluate those streams, ironically, we lose meaning. The meaning becomes the existence of the system itself, rather than the essence.

Perhaps the AI model can predict behavior better in the existing world, but that is a different idea than intentional meaning from a human perspective.

Written language goes back 6,000 years. The earliest versions represented a concept with one token, much like emoji. It started with actual tokens to track debt and trade, evolved to pictographs, went through full-on emoji stage in some versions, and then moved on to written word like we know now. (โ€œThe Evolution of Writing Denise Schmandt-Besseratโ€ n.d.) (Tepiฤ‡, Tanackov, and Stojiฤ‡ 2011)

Knowledge at this point in our civilization arc is extremely complex. Imagine a dot on a line 6,000 years ago that moves up ever slightly to the collapse of 1177 BC, goes down again, rises again with Rome an inch off the line, collapses again, and then under our current rise since the dark ages, goes to the moon, literally and figuratively. (๐Ÿ“‘39)

There are several reasons why I conclude that emoji are useful to complex analysis:

  • Immediately recognizable
  • Compact
  • They work well in a graph (see more below about graphs)
  • They can be used in filesystem paths and [!JSON]
  • They are fun and pretty

There are also reasons why emoji are bad, primarily compatibility, manageability, maintainability, and security:

  • Not all applications can view emoji correctly
  • It can be difficult to maintain and manage emoji mappings to ideas over time. (Note that this solution description, with scope and assumptions, make this concern less critical.)
  • Emoji can cause security issues, particularly with invisible elements or misleading views.

Long-form text is usually not immediately understood. For many people, only the first couple of sentences is read in a long narrative. Emoji has quite a few quirks that make it difficult to use in knowledge systems; however, from a human perspective it makes understanding systems at rest and at flow much easier. The priority is human, not machine cognition.

๐Ÿ”ฌ๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒณ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นKnowledge

๐Ÿ”ฌ๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ—บ๏ธ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นMapsMaps

๐Ÿ”ฌ๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐Ÿ‘ฅ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นCollaboration

Whiteboard and Stickies

The Whiteboard and Stickies collaborative business analysis technique gathers users and experts of a system gather in a room with stacks of sticky note pads.

Under the prompting of an analyst, the users lay out aspects of the system by writing small bits of information on the notes and sticking them on a whiteboard. Many who have witnessed this technique have marveled at how well it works. The main reason this works so well is that it is collaborative without the burden of dense jargon or existing description of the system.

This method works well as far as communication for those present at the meeting. The analyst serves as an interpreter. There are limits to the collaboration, as it is all within a local room. Collaboration virtually is difficult.

Meaning is often encoded with color and text of the stickies, as well as text on the whiteboard. There is little control of meaning, as it is whatever people put on the notes. It is guided by the analyst, but there is no schema, which is a disadvantage as far as common, re-used meaning.

Knowledge is captured on the whiteboard itself. Somebody might take a picture or roll the whiteboard into another room. Capturing the knowledge is labor intensive and often a choke point of the analyst. There is an overall visual order. Sometimes the map is in swimlanes; sometimes it is more chaotic. The map usually needs to be expressed in a different form.

All may contribute without barriers to entry. There is instant validation of gathered information. If somebody puts up a sticky note that is inaccurate, it is easy to correct. There is a real-time update of the output of the group

Whiteboard and Stickies is a great example of collaboration, primarily through the simple process and few barriers. It shows how knowledge can be broken down and re-assembled successfully, and the stream of changes can be instantly visualized.

๐Ÿ”ฌ๐Ÿ”ธ๐Ÿง‘๐Ÿ”ธ๐ŸŒฑ๐Ÿ”ธ๐ŸŒŠ๐Ÿ”น๐Ÿท๏ธ๐Ÿ”นStreams

Streams in IT are often key-value pairs with timestamps. These streams are the relative of triples, with key-value being two to a tripleโ€™s three.

Consider this local alarm:

<154>1 20220327T211058.426Z dc1mon.example.com process=โ€œ6 6 3โ€ cpu=โ€œ100โ€ memfMB=โ€œ10โ€

This is in Syslog format. (Gerhards 2009) It illustrates a priority alarm coming through for the available CPU dedicated to process 6.6.3 running at 100 percent, with only 10 MB of free memory. This is an operational stream that could trigger integration with the graph visualization. For instance, process 3, the Ad Targeting Engine on the 6.6 graph could be highlighted with red when the alarm came through:

D1SuperCloudDatabase1FanisizerCloudD2IdentityStorageDigitalMarketingSuperCloudDatabaseSupportD3UserActivityForSale3AdTargetingEngine4MediaOutletsGrandmothersandPeePawsGovernmentLeaders*FodderandMudder2IdentiTroll*TrollFarmsandMeatTools

Perhaps it is useful to alarm on a map of the entire system data flow. This shows an alarm on process 11, subprocess 1, the AI Feeder:

6CustomerRelationshipManager* 6.1SnailMailImport6.2BillingIntegration6.3MailRoomReceiving6.4Mail6.5Monthly6.6Social Fanisizer6.7BulkCardPrint6.8ConstantEmailService6.9A-R6.10ServiceBureauAPI6.11Contracts6.12Reporting8ProductAcceptanceD1HQDigitalDataCustomerLeadsFieldSalesMarketingandSales* 6.1.1TrayFirmware6CentralAdministrationServices6MailRoomStaffD6.5ReturnedCardsD6.2LeadAddressesD6.7Lead