cdaniel
commented
7 years ago Technical literature: https://www.mongodb.com/blog/post/schema-design-for-time-series-data-in-mongodb http://www.askasya.com/post/trackversions/ https://github.com/thiloplanz/v7files/wiki/Vermongo https://tools.ietf.org/html/rfc6902 https://www.slideshare.net/datablend/fluxgraph-a-timemachine-for-your-graphs https://link.springer.com/article/10.1007/s10270-012-0248-x
Intro
Maps represent situation snapshots. At any given time, there is one map describing reality and multiple map variants that describe future scenarios, and after a while, only one of them may describe the reality. I have used the 'may' word, because there is a chance we have not predicted the future.
As time passes, we end up with a series of maps forming a timeline, and multiple, unused branches that represent situations that did not happen (either because market did not respond or because we have chosen different approach). Naturally, it may happen that our map modification effort fails, and in that case we may be required to switch to second best scenario from the past, forming thus a structure very similar to git graph:
Such a map timeline could serve as an universal tracker of what works and what does not for a given company, and therefore enable feedback loop so necessary for learning.
Considerations
Components ownership and existence
Currently, the assumption is that all the components on the map have their counterparts in your company. If you put a 'server' on your map, it means that either you have one, or you plan to have one. With variants, this will be no longer the case. There will be components that do not yet exist (future possibility), could have existed (past option) and do exist (current situation), or did exist (past situation). One component can change state across a number of variants, as well as evolution level.
Competitors
Each component, regardless of its state and evolution, can have defined market references, and those market references may change independent from the component, and sometimes may even replace it. That said, competitors no longer can be bound to components. They have to be bound to a map and point to the component they compete with.
Submap representation
Submaps can be shared across multiple maps. From a parent map perspective, submaps are plain components described in the previous paragraph, but a submap must in addition to a single component track who uses it, and how this usage has been changing and may be changed in the future. If more maps depends on a submap, it would be good to provide synchronization mechanism, which in turns forces two maps using same submap to share a common timeline, which in extreme case may connect all maps in a workspace.
Action representation
Actions can be actually deduced as a diff between maps. If a new state is cloned from the old one, and it is changed, it becomes very easy to show those changes, and visualise how we have are planning to manipulate the chain for future variants, and how we have ended up in current situation. Node addition, maturity change and deletion can be easily discovered, as well as competition changes. However, actions that slow down evolution must be marked manually, as we will never know if maturing component matured because of our effort, or despite our effort.
Removing duplication
Since time was not considered earlier and the assumption was that everything is now and present, it was very easy to mark components as duplicating each other. Now, the duplication view will have to gain the timeline option, too, and it should be possible to mark that certain components will be merged as an action, maybe even from the map level.
Parallel maps
Two maps may not be related in any other way then describing one organisation. There is an open question whether they should share the timeline (since they describe organisation, they could, but it may clutter the timeline). On the other hand, if two maps become related, merges will clutter the timeline.
Restoring nodes
In order to be able to track nodes, when one is deleted, there should be an option to restore it with the same _id, which may be difficult, because _id is hidden from the user.
History
It may be worth to add history of changes here, too, as it is a very similar functionality.
Multi step plans
It should be possible to plan a series of steps that lead to a given goal.