AS-IS, Transition, TO-BE

Started by johmut, December 07, 2021, 10:39:48 AM

Previous topic - Next topic

johmut

What is best-practice to express AS-IS, Transition and TO-BE architecture within the same model?

Object names, definitions, relations and views will evolve across the different iterations from AS-IS towards TO-BE. AFAIK: You cannot have different versions of the same object in Archi. Creating separate models, based on a snapshot of AS-IS, to start working on Transition iterations and a vision om TO-BE breaks inheritance. In other words, there is no waterfall of objects changed in previous models, re-used and added to in later iterations of the models...

Using coArchi, one could imagine using a branching strategy to do this within a single model repository. AS-IS can be the main branch. Transitions and TO-BE can branch off the main branch and merge back in when plateaus are reached. Open future branches can then be fast-forwarded to re-sync with the new version of the main branch (AS-IS). However this does not work from a usability perspective for us architects that need to switch back and forth. AFAIK it is not possible to have different branches of the same model simultaneously open in Archi AND switching branches can take a few minutes for non-trivial model sizes AND you cannot start multiple instances of Archi, each on a different branch.

Looking forward to hearing how you handle this challenge in your day-to-day use of Archi.

Jean-Baptiste Sarrodie

Hi,

That's a common but complicated topic with no "one size fits all" answer, so here's one which works in a particular context (mine) and may, or may not, work for you:

Quote from: johmut on December 07, 2021, 10:39:48 AMObject names, definitions, relations and views will evolve across the different iterations from AS-IS towards TO-BE

With this assumption, it will be impossible to use the same model for AS-IS and TO-BE, but if you relax it a bit there's an approach which works. In my case, I assume that name and definition won't change, only relationships and views will.

Another assumption is that people mainly interact with views, and view provide some context (the view title but also the way they are organized inside a folder hierarchy).

My last assumption is that, at some point some automation is needed which relies on the knowledge that some concept will appear in the future).

With those assumptions in mind, my approach relies on a well defined (but flexible) folder hierarchy for views which make it possible to distinguish views describing the current state or the future state (or even some state in-between). It then becomes easy to know the context in which a view sits.

I personnaly don't use AS-IS and TO-BE, but "current" and "target", with the addition of "project":
  • current: this is the current state of the architecture.
  • target: this is the agreed (ie. validated through some sort of Architecture Committee) state of the architecture.
  • project: this is used for scenarios studied during a project design phase and before validation

They all represent a kind of plateaus that I don't model using an ArchiMate element but through inferred property: Plateau is stored in a property (named "Plateau") of a folder and applies to all views contained inside it or inside one of its descendants (unless such descendant relates to another plateau). So, the plateau of a view is the one of the first parent folder with a defined "Plateau" property. Of course, one could also force the property on a concept.

Determining the plateau of a concept (element or relationship) is a bit more complicated and involves the following algorithm:
  • If a concept has a "Plateau" property, then use it's value. If not...
  • Find all the views containing the selected concept
  • Get the plateaus of those views
  • If the only value for "Plateau" properties is project, then the plateau for the concept is also project
  • If the values for "Plateau" properties are only target or mix of target and project, then the plateau for the concept is target
  • If the values for "Plateau" properties contain current, then the plateau for the concept is also current

This might sound a bit complex, but this logic easily be implemented in jArchi as set of functions, such as: 'getPlateau(concept)', 'isCurrent(concept)', 'isProject(concept)' and 'isTarget(concept)'. It then become really easy to get access to this Plateau or to filter:

// generate a CSV table of application together with the plateau containing them:
$('application-component').each(function(app) {
  console.log(app.name, ',', app.documentation, ',', getPlateau(app));
});

// For a known 'app', generate a CSV table of current flow relationships
$(app).rels('flow-relationship').filter(isCurrent).each(function(rel) {
  console.log('From: '+rel.source.name, ',', 'To: '+rel.target.name, ',', rel.documentation);
});


Quote from: johmut on December 07, 2021, 10:39:48 AMUsing coArchi, one could imagine using a branching strategy to do this within a single model repository. AS-IS can be the main branch. [...]
However this does not work from a usability perspective for us architects that need to switch back and forth. AFAIK it is not possible to have different branches of the same model simultaneously open in Archi AND switching branches can take a few minutes for non-trivial model sizes AND you cannot start multiple instances of Archi, each on a different branch.

First thing first: if switching takes few minutes, then you definitely have some issue with your antivirus (I'm sure you have one). Switching on a model containing 10,000 concepts should take no more than 20 seconds (less than 10 on my machine). Other than that, coArchi could be leverage for that purpose (and I know several teams who do) but only when different architects works on AS-IS and TO-BE. When the same guy works on both, switching (even if quick) is not acceptable.

Another option that I've seen (but have limited experience with) is to start with the AS-IS model, save it as another (TO-BE) model and do whatever you want in this TO-BE model. Then, if you want to reflect changes from AS-IS to TO-BE, you simply have to use the model import feature of Archi to import AS-IS into TO-BE. When you're done with TO-BE, make sure it contains only new or changed views, remove every concept that doesn't appear in at least one view and import TO-BE into AS-IS. Of course, this is very limited and doesn't permit in depth analysis of changes.

Hope this helps.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

tpedot

Hello,
I am considering using this code to identify AS-IS TO-BE Architecture.
https://github.com/RichDijk/EAGOC

Here you have one model with two plateaus.

You have one publication around this and you can find the thesis related that capture the logic behind that:
https://www.researchgate.net/publication/332448224_Analytic_Pattern_and_Tool_for_Analysis_of_a_Gap_of_Changes_in_Enterprise_Architectures

You have here a view:
https://github.com/RichDijk/EAGOC/blob/master/ApplicationStructureView.JPG

The script is running against CSV import/export from Archi and it would not be difficult to implement it to Archi.

From my side, I will try to manipulate OpenModel and try to add a view like the pictures above (Add/Change/Removed)


effect

Quote from: Jean-Baptiste Sarrodie on December 07, 2021, 18:00:10 PMHi,

That's a common but complicated topic with no "one size fits all" answer, so here's one which works in a particular context (mine) and may, or may not, work for you:
--
With this assumption, it will be impossible to use the same model for AS-IS and TO-BE, but if you relax it a bit there's an approach which works. In my case, I assume that name and definition won't change, only relationships and views will.

Another assumption is that people mainly interact with views, and view provide some context (the view title but also the way they are organized inside a folder hierarchy).

My last assumption is that, at some point some automation is needed which relies on the knowledge that some concept will appear in the future).

With those assumptions in mind, my approach relies on a well defined (but flexible) folder hierarchy for views which make it possible to distinguish views describing the current state or the future state (or even some state in-between). It then becomes easy to know the context in which a view sits.

I personnaly don't use AS-IS and TO-BE, but "current" and "target", with the addition of "project":
  • current: this is the current state of the architecture.
  • target: this is the agreed (ie. validated through some sort of Architecture Committee) state of the architecture.
  • project: this is used for scenarios studied during a project design phase and before validation

They all represent a kind of plateaus that I don't model using an ArchiMate element but through inferred property: Plateau is stored in a property (named "Plateau") of a folder and applies to all views contained inside it or inside one of its descendants (unless such descendant relates to another plateau). So, the plateau of a view is the one of the first parent folder with a defined "Plateau" property. Of course, one could also force the property on a concept.

Determining the plateau of a concept (element or relationship) is a bit more complicated and involves the following algorithm:
  • If a concept has a "Plateau" property, then use it's value. If not...
  • Find all the views containing the selected concept
  • Get the plateaus of those views
  • If the only value for "Plateau" properties is project, then the plateau for the concept is also project
  • If the values for "Plateau" properties are only target or mix of target and project, then the plateau for the concept is target
  • If the values for "Plateau" properties contain current, then the plateau for the concept is also current

This might sound a bit complex, but this logic easily be implemented in jArchi as set of functions, such as: 'getPlateau(concept)', 'isCurrent(concept)', 'isProject(concept)' and 'isTarget(concept)'. It then become really easy to get access to this Plateau or to filter:

// generate a CSV table of application together with the plateau containing them:
$('application-component').each(function(app) {
  console.log(app.name, ',', app.documentation, ',', getPlateau(app));
});

// For a known 'app', generate a CSV table of current flow relationships
$(app).rels('flow-relationship').filter(isCurrent).each(function(rel) {
  console.log('From: '+rel.source.name, ',', 'To: '+rel.target.name, ',', rel.documentation);
});

JB, would you care to elaborate on the scheme you use? I get half of it, but i would like to understand the other half.

It would also be interesting to know how you, with your experience,  organize "model element" folders (not views).