Design of baseline & target architecture

[bensopra]

Hi All,

I'm wondering what are, according to your experience, the most efficient way to model baseline & target architecture (TOGAF speaking) in Archi?

I'm hesitating between creating 2 distinct models, which is not optimal for reuse, or a single model which implies to create elements/relationships which are effective only in baseline or target architecture.

Do you have some advice?

Thank you.

[Jean-Baptiste Sarrodie]

Hi,

I tend to use only one model for both, but with different top level folders under "Views". This allows me to easily work with both states in jArchi if needed by creating a filtering function based on views' parents including/excluding these top level folders.

Regards,

JB

[bensopra]

Sounds good.

In your scenario, let's consider an App Component named "MyApp".

In transformation, this App Component will be reimplemented (new technical stack but same business purpose).
How do you differentiate both components ? Do you provide a kind of version number in Compoment name ? Or do you only rely on parent folder ?

[Jean-Baptiste Sarrodie]

Hi,

In your scenario, let's consider an App Component named "MyApp".

In transformation, this App Component will be reimplemented (new technical stack but same business purpose).
How do you differentiate both components ? Do you provide a kind of version number in Compoment name ? Or do you only rely on parent folder ?

It in fact depends on how you usually manage application versions. In most organization there is some kind official ID for applications, managed in a referential. In this case, if such technical changes lead to a new application ID, then you'll have to create a new application component (with usually the ID as a property or part of the name through a naming convention). Of course, in both your "as-is" and "target" folders you should have some views to map your application components on top of your business processes/functions or capabilities. That should be enough, but if you have some analysis based on which application X replaces application Y, then you could use a directed association with a "replaced by" label to link them.

On the opposite, if such technical changes don't lead to a new application ID, then you keep the same application component, but in both "as-is" and "target" folders you should have some views to detail the underlying technology elements serving or realizing your application.

Regards,

JB

[Chris Usher]

I settled on using ApplicationService to represent what our business knows as an application. This application service carries the application ID as a property. Usually the service is realised by one or more application components. If/when an underlying application component is redesigned or replaced, the application service remains but its implementation has changed.

This allows me to model the target state alongside the as-is in the same model and switch from one state to another by changing which components "realize" the service.