Archi Forum

Archi => General Archi Discussion => Topic started by: johmut on December 07, 2021, 10:39:48 AM

Title: AS-IS, Transition, TO-BE
Post by: johmut on December 07, 2021, 10:39:48 AM
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.
Title: Re: AS-IS, Transition, TO-BE
Post by: Jean-Baptiste Sarrodie on December 07, 2021, 18:00:10 PM
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":

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:

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
Title: Re: AS-IS, Transition, TO-BE
Post by: tpedot on December 14, 2021, 17:23:36 PM
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)