Best method to differentiate between AS-IS and TO-BE

[BobM]

Hi,

Had a bit of a philosophic breakdown on diagrams and had a few questions:
Time-aware modelling is improved but its not quite great (yet), especially because the layers and filters aren't useful for procloud display (yet, probably not even on the roadmap) and I prefer not to resort to lite clients.

What methods is the most common practice to show the difference between the AS-IS and TO-BE?
Currently I use a legend where I set the elements in bold and thicker lines what is new in the displayed sprint in order to visualize it on procloud diagrams (take note that a shared legend somehow isn't included in the time-aware modelling yet.)
I take it there are better methods?

Another question: how do you guys resolve navigating to what will be developed in what sprint?
We try to abstain from using the browser but prefer navigation cells; We accomplish this by building project pages; But in the end it delivers a huge clutter of pages to maintain.

What are the better practices?

Thanks in advance for the answers

[qwerty]

I don't think there is any cookbook for versioning. Everywhere I was in involved people had different thinking related to versions, how a product is setup and what the implications of changes to versions are. You will have to have lots of workshops to find it out in your case.

q.

[Geert Bellekens]

Another question: how do you guys resolve navigating to what will be developed in what sprint?
We try to abstain from using the browser but prefer navigation cells; We accomplish this by building project pages; But in the end it delivers a huge clutter of pages to maintain.

What are the better practices?

Thanks in advance for the answers

We use change objects and link them to model items using a script.
https://github.com/GeertBellekens/Enterprise-Architect-VBScript-Library/blob/master/Projects/Project%20A/Diagram%20Group/Link%20To%20CR.vbs
https://github.com/GeertBellekens/Enterprise-Architect-VBScript-Library/blob/master/Projects/Project%20A/A%20Scripts/LinkToCRMain.vbs

Change objects are then grouped into releases/sprints

An SQL search gives us an overview of all changes in the model per change and per release.
We do not use diagrams for this purpose.

Geert

[wivel]

Hi Geert

Can you please elaborate a bit?

I am having the same 'challenge' with AS-IS and TO-BE BPMN 2.0 processes, where the changes between releases can be quite substantial. We tried to make a new copy for the TO-BE processes, but then all links and references are still pointing to the AS-IS process.

Henrik

[Geert Bellekens]

We determined that it's not possible to maintain two versions of the same truth (AS-IS vs TO-BE) in the same model, so if anyone needs the old AS-IS situation, they need to refer to a old snapshot of the model.
Our working model only keeps track of the TO-BE situation.

We do "tag" the elements impacted with a change object so we know which model elements where updated for a certain change.

Geert

[Ian Mitchell]

Have a look at eaPortfolioManager.com.
I think we have a reasonably simple way to allow multiple versions of something to exist in the same EA model, where the different versions know about each other, and you can keep track of everything.
Interest: I'm the developer of Portfolio Manager.

[amacara1]

Geert, how do you "tag" the elements impacted with a change object, please?

[Geert Bellekens]

Geert, how do you "tag" the elements impacted with a change object, please?

with the scripts I linked in an earlier reply

Geert

[Modesto Vega]

It depends on what you mean with "As Is" and "To Be".

If it refers to the evolution of an existing application architecture - i.e., Sparx Enterprise Architect - over time, versions are one option (although I can think of others).

If it refers to changes to an enterprise architecture where systems/applications are replaced on a regular basis I would not use versions for this, I would use packages.

These are 2 very different use cases. Sparx EA can be used for both and it is difficult to suggest a method without additional context. The 2nd use case if far more complex, n my opinion, than he first one.

[Mauricio Moya (Arquesoft)]

My strategy is always based on the following scenario: I have a section of the model that I call "Catalogs" where the "AS-IS" representation is located. This AS-IS always shows the current state of the objects (CIs, Servers, Classes, Databases, Processes, etc.).

Then, in another root node of the model we have the "Projects", which are a representation of the different work fronts that exist in the company, each of which intends to make changes to some of the elements of the architecture (CIs, Servers, Classes, Databases, Processes, etc.), therefore they have their own diagrams, reusing, if necessary, objects from the catalog. Each Project corresponds to a TO-BE state, which will incorporate over the time some changes to the AS-IS model.

If the project is executed and deployed correctly, the diagrams and objects created within the project are "promoted" to the catalog section, meaning they become the new AS-IS. If any project was stopped (due to budget, time, incorrect scope, etc.), it is never promoted to the AS-IS and its documentation is maintained within the project section (TO-BEs).

That is the general strategy I use, where objects are reused between the AS-IS and the TO-BE. The bad thing about this strategy is that it makes it difficult to know if a connector is from the AS-IS or from the TO-BE.

[Geert Bellekens]

I've encountered organisations using that Catalog/Projects aproach a few times.

They always had the same theory, and told me they where going to do that.

What I haven't seen is a working example of such an approach in practice. "Promoting" or merging the "project" stuff into the "catalog" stuff is almost impossible and definitely costs massive amounts of time.
Quite often there was this; "yeah we still have to merge that stuff" response.

Another major flaw of this approach is that you loose sight of your dependencies.
If Project A plans to replace a componentA, and project B plans to change some stuff on componentA. How and when will project B get notified?
All these types of inter-project dependencies are very difficult to manage if each project lives and works on it's own island.

That's what Ian is trying to solve with his add-in. So if you insist on this type of approach, I would definitely look into the Portfolio manager to get some automated support for this process.
If not I'm afraid this will only work in theory.

Geert

[Modesto Vega]

I agree with Geert, having tried this approach numerous times we never managed to get it to work. The biggest project with this approach is twofold:
1) As Geert says you loose track of dependencies,
2) Very often projects map the "As Is" before designing the "To Be", this is typical of many organisations trying to create an enterprise architecture baseline.

We have settled with an approach where we have a PMO view, and a view per system irrespective of whether it is "As Is" or "To Be". Other than an element per programme/project, we are still perfecting what goes into the PMO view.

Ian is trying to solve this issue with the Portfolio Manager add-in but I haven't seen it since the last EAUG event in Reading.

[jcampos]

Hi,

Our Strategy in Andes Architecture is adding a Tag Value called "phase", even using the propierty "phase" to clasify elements and diagrams.

This allow us to perform dynamic filters and clasify easily all the things in the repository. Also, is easier to upload information with a CSV.

Remeber TOGAF framework, is desirable to have an Enterprise Continnum which organice all your elements in packages respect to the phase too. This estrategy could be complemented using baselines.

Jhon.

[timoc]

Another question: how do you guys resolve navigating to what will be developed in what sprint?
We try to abstain from using the browser but prefer navigation cells; We accomplish this by building project pages; But in the end it delivers a huge clutter of pages to maintain.

What are the better practices?

Thanks in advance for the answers

We use change objects and link them to model items using a script.
https://github.com/GeertBellekens/Enterprise-Architect-VBScript-Library/blob/master/Projects/Project%20A/Diagram%20Group/Link%20To%20CR.vbs
https://github.com/GeertBellekens/Enterprise-Architect-VBScript-Library/blob/master/Projects/Project%20A/A%20Scripts/LinkToCRMain.vbs

Change objects are then grouped into releases/sprints

An SQL search gives us an overview of all changes in the model per change and per release.
We do not use diagrams for this purpose.

Geert

Hi Geert,

I've also been looking at versioning recently and i honestly thought the time aware modelling was a good way to go.

I'm now considering your workflow with these scripts and i have to ask how do these scripts compare to the team collaboration windows using 'EAReview' elements that is in v16?

Tim.

[Geert Bellekens]

Hi Geert,

I've also been looking at versioning recently and i honestly thought the time aware modelling was a good way to go.

I'm now considering your workflow with these scripts and i have to ask how do these scripts compare to the team collaboration windows using 'EAReview' elements that is in v16?

Tim.

Our change management workflow has a completely different purpose.
We want to keep track of which elements of the model have been changed, for wich change.
For individual change we want to know who changed it, when it was changed, and what was changed.

Since this is a manual administrative process, we want to keep the overhead as small as possible; so no diagrams or stuff like that.

The review stuff clearly serves a different purpose: discussing, and approving changes in the model.

Geert