Modelling future, present and past states... The "Effluxion of Time"

[Paolo F Cantoni]

As part of our possible future solution description, we have a "Transition diagram", where we place the model items (vertices and arcs) in the current state. We then add the future items and connect the current and future things with a "Transitions to" relationship.  With EA recent ability to allow relationships between relationships and relationships and items, we can specify what the transition will be to the requisite level of detail.  It's a really easy way to see if we've "considered everything".

You've discussed the what but not the why.  I suspect that no one who has commented so far has the same reason for wanting time aware modelling, or potentially for the same notation (where).

You're probably right, I've always been about a decade ahead of the game.     Luckily, my fellow architects are on board and willing to investigate the possibilities.

As to the why, the response I made to qwerty gives you the why - to combat Corporate Alzheimers (especially in the new "gig economy" where consultants are hired on a per-project basis) and to provide evidence of due diligence in considering options (to forestall the inevitable questions - particularly in an academic environment "Why didn't my pet solution get up?").

Happy Friday everybody!
Paolo

[PeterHeintz]

Hi all,
I have the feeling that the issue is in general, overall just too complex to be remarkable supported by a kind of algorithm.
First some Remarks.
Models have typically the purpose to describe something that exist or should exist in future. The terms like As-Was, As-Is, To-Be, Might-Be, … can be applied to both, the model itself and to the thing it describes.
Both, "the model" and "the thing", might be mutable depending on one defines what mutable means, even in state "As-Was" depending on what "As-Was" is applied to.

Anyhow, I think the focus here is on changing a model.

How could a perfect  “seamless determination of the object state at an arbitrary point in time” look like in EA?

Well we could have two slide controls (similar to what we use for zooming), representing the time. Both sliders are on the right hand, representing the “now”. If the user moves the first slider to the left, she/he goes back e.g. five seconds, 3  hours or weeks and month. By doing so, the user sees in EA the model as is was at that time immediately. Further on, the user has a button to show the differences between the past chosen and the “now”. With the second slider the user is able to choose a second time in the past, to be able to compare two past states.

Sounds cool and maybe unrealistic, but it is maybe possible. The question is more, if someone is willing to spend the effort and if our HW is powerful enough.

The time represented by the sliders, needs not really represent the physical time, due to the fact that model changes are discreet events, rather than continues flows.

Having that “ideal feature” we could use it for “AS-Was”, “AS-Is” applied to the model but not all-embracing on the “thing” the model represents.
It would not help on model level, for “To-Be” and “Might-Be”, because that is in the head of the modellers and after transferring it to the model it is the “AS-IS”.

This means in model context, there is never a  “To-Be” and “Might-Be”, because it is future. However, a “AS-IS” model state, might contain “To-Be” and “Might-Be” model fragments, prediction the future of the “thing” those represent.

For that predicting “To-Be” and “Might-Be” , the “ideal feature” above, would not give any remarkable benefit at all.
It is just a different issue!
This issue is, from what I know, called “Variants”. Maybe one has in mind, only the same thing at the same time with different options are vatiants, like a car you buy with some nice assistance systems or without. But it is somehow the same stuff, regarding modelling of things in “states” As-Was, As-Is, To-Be, Might-Be, …

To be continued…!!!

[Glassboy]

Hi all,
I have the feeling that the issue is in general, overall just too complex to be remarkable supported by a kind of algorithm.
First some Remarks.
Models have typically the purpose to describe something that exist or should exist in future. The terms like As-Was, As-Is, To-Be, Might-Be, … can be applied to both, the model itself and to the thing it describes.
Both, "the model" and "the thing", might be mutable depending on one defines what mutable means, even in state "As-Was" depending on what "As-Was" is applied to.

I think Peter is currently winning :-)

[Paolo F Cantoni]

Hi all,
I have the feeling that the issue is in general, overall just too complex to be remarkable supported by a kind of algorithm.
First some Remarks.
Models have typically the purpose to describe something that exists or should exist in future. The terms like As-Was, As-Is, To-Be, Might-Be, … can be applied to both, the model itself and to the thing it describes.
Both, "the model" and "the thing", might be mutable depending on one defines what mutable means, even in state "As-Was" depending on what "As-Was" is applied to.

I think Peter is currently winning :-)

It only LOOKS like he's winning - not that it's a contest.   

Just wait 'till I define "mutable" and "As-Was" (in this context). 

Paolo

[Glassboy]

It only LOOKS like he's winning - not that it's a contest.   

Just wait 'till I define "mutable" and "As-Was" (in this context). 

I'm fairly certain an 'appeal to the future' is a formal logical fallacy :-) 

[Paolo F Cantoni]

[SNIP]

I'm fairly certain an 'appeal to the future' is a formal logical fallacy :-)

Are you indulging in Fallacio? 

Paolo