Elements in the Universe of Technology
Post on certain key definitions that will lay out the structure of how entities looks like in the Universe of Technology for Kloudi
Hey there 👋🏼!
There is a theory that Sneh and I have hypothesised as a result of our experience. It talks about how we are witnessing a Big Bang in Tech. The occurrence of this Big Bang has led to an ever expanding universe of tools, so much so that builders of the future of anything tech are seeing this universe complicate the process of building for them.
You will have to wait for our follow up posts for us to elaborate how this led to the genesis of Kloudi, for now a premise for you to remember through your read is that the result of an expanding universe is increased entropy and chaos.
Let chaos reign, and then rein in chaos.
- Andy Grove
This will be blog post on certain key definitions that will lay out the structure of how entities looks like in the Universe of Technology for Kloudi. Later on we will cover other aspects like how do we connect these entities in this universe, operating engine and its form factor, etc.
Entities are primitives that people in technology companies work with on a day-to-day basis. Entities captured in workflows helps move the needle towards a goal/outcome. Example of entities could be Features, Task Lists, Tickets, Bugs, Servers, Deployments, Versions, Platforms, Team Members etc.
Attributes Related to entities
Since we are currently focussed at bug management workflow the entities that matter to us currently are - Bugs, Stack trace, Requests, Trace and Spans, Team-Members, PRs, Comments, Code.
Every entity is connected to each other through bi-directional links resulting in two types of relationships - pre-defined or runtime.
Source is related with the genesis of an Entity. What introduced the entity into the system. For us most of our entities will be populated by data from SAAS tools. User of such SAAS tools can also introduce an entity manually (like creating a logical bug on a product management tool of their choice) but we are not capturing this interaction as of now.
Features/Jobs it can perform
Input (API, RPC, SOC, Webhook, EMail, Slack-Channel, Phone, SMS)
How does a user achieve the desired goal/outcome? How does a work flow currently exist?
With workflow it is important to remember direction matters because in which order the user interacts with entities helps us move more closely towards understanding the current flow and how users achieve their respective outcome.
Things that matter in this are entities involved, relationship between entities, direction of movement, and tools to achieve this work flow. Remember intent, context and state matters here as well. Tagging workflow with all these help us taking a decision around how many work flows form the fundamentals of building a product, company or category.
Think of workflows as vectors, in graph terms (probably similar to Directed Acyclic Graphs). Aggregation of entities in a particular direction make a workflow in graph terms.
Actions and Intents
Builders are Individuals or teams trying to achieve the goal from a workflow. These are the users for Kloudi. Instead of focussing on people and their workflows we are focussing on entity and how they light up in every workflow.
Companies for which builders are working for. Stage, size, sector will help us with narrowing down our experiments.
Attributes of this are unknown, but understanding this is very critical to make sure that the rewards after every jobs to be done can be in sync with the emotion that a user has at that moment.
Though a lot of this seems a little bit theoretical but this helps us in bringing structure to the increasing entropy and building abstractions for Kloudi. In the next couple of pieces we will knit all the entities of Kloudi's Universe together in one piece which will help us visualise the universe and start measuring its interactions against time and productivity.