[Edit: This post has been edited, following later feedback]
I debated whether to get involved with this subject, but we might want to go in this rough direction sometime soon, so I thought I'd throw my "Molotov Cocktail".
As qwerty and Geert have said, there is no "magic bullet", Sparxian or otherwise for this problem at this stage. I've thought about this issue over the decade or so and I believe had some insights into what some of the components of a possible solution might be.
As the others have said, it's about communication. However, what is to be communicated? When and how is it to be communicated? As Modesto has said, in complex organisations and even complex products or landscapes, leaving things to humans alone is not enough. That's why we have a repository. No single human can keep everything in their head nor visualise the complete landscape.
I think everybody agrees that you can't have a "free for all", where anybody can change anything at any time. We also agree that we wish to have a single "model". But what does that mean? Over a decade ago, I introduced the concept of "Doppelgangers". Shadow clones of a real item. As qwerty says, you only want one X. But that doesn't necessarily mean that you have one instance of X, so long as the instances communicate and cooperate correctly. Sparx has "come to the party" (after a fashion) with their, so-called, time-aware modelling.
OK, so for the sake of this discussion, let us assume there is one master (the present state) [notice I didn't use current state]. If this present state item doesn't echo the present state "in real life" (or IRL as we say in the RC hobby
) then we've got bigger problems. This present state item needs to be controlled (in terms of being able to change it) so that it doesn't drift from its tracking of the real-world item. Let us also, again for the sake of this discussion, the "Enterprise" item, to distinguish it from other present state items (say in this or other projects)
The point of the repository is that there should be one item, so the projects, where they use an enterprise item, must use a link to the existing item; not their instance. Consequently, any changes to the "present" item, are immediately surfaced to the project. Except, how does it know? When we create the project and link to the enterprise items, we need to persist the latest date of any such item into the project. Why? Well, we can then determine if any enterprise item has been modified. We can then check back to see what has changed (if it's not obvious) and determine what effect that change has on the project. Let's leave aside what is meant by the "enterprise item has changed".
The project works away (on defining its target state), creating any new items it requires and sometimes, there is a need to postulate a new target state of the enterprise item (say we wish to change the amount of memory on a hardware device). We can't change the enterprise item since the new memory has not yet been applied. We, therefore, need to convert the enterprise item from a link to a target state clone. We link that back to present enterprise item, so we can keep the two in synchronisation as the enterprise item changes.
One insight I think I've had over the years is that when you have two doppelgangers liked by a relationship, that relationship should hold a summary of the changes between the master and the clone. That way, you can compare the relative changes between the two (since both may be changing over time). The relationship holds the state of the difference at a point in time and allows a "compare and contrast operation".
When the project is complete and in production, the enterprise and project items' states need to be consolidated (much in the same way as when one is trying to merge multiple repositories into one). We have a consolidator function that can ease this problem, but it can't solve it. We need to add the ability to interrogate the doppelganger link to highlight the difference and decide in which direction to consolidate.
If we're happy with this description of the process, we can look at how we can manage this. If not, let's refine it to create a specific scenario we can agree on.
Paolo
