Problem with symbol size related to new palette setting

Erik Mossing on December 21, 2020

Dear ARIS friends,

I have been working on a new filter and template for our organization and using the new symbol style is the main change. We have a lot of legacy material that I dont want to change or migrate so I created new symbols for each object in our framework. This approach allows modellers to choose old or new style filter when logging in depending on thieir task. It also supports migrating only requested models over time rather than a big bang migration of everything.

Anyway, I created the new filter by setting up a new database that i populated with my updated models and symbols and the relevant relations. When creating this database I was given a choice wether to use "ARIS default palette" or the old "ARIS default palette (classic)". I selected the first alternative. A later found that our 10+ year old production database has the classic option. (of course, nothing else was available when it was created).

I tested the new filter and template on a test-database (ARIS default palette was used when creating that database too) and everything seemed fine. Decided to test it on our production database with a few key users. They noticed that the new symbols where a bit small and should have a larger default size. Their suggestion was 300% which is huge and I realized that there must be some other parameter involved that controls the symbol sizes. The only difference in settings that I have found so far is the Palette and method filter setting described above. I can change it of course but then I have to migrate all the content on the database as it replaces all classic symbols.

I realize I may have to setup a new database for use of the new palette, filter and template and use a more batch-oriented approach to migration. But first I want to understand how the difference in symbol size can occur with the same template.

Questions:
Are there any know parameters controling symbol size that I have missed?
What is the best-practice approach to migrate to the new symbol palette on a server with many custom symbols?

I am thankful for any thoughts.

Kind Regards and Happy Holidays!

Notify Moderator

5 Replies

MZ

M. Zschuckelt on December 21, 2020
Hello Erik, just to be sure: Have you tested the Macro "Layout models using default palette", if it is of any use for migrating your databases with Default (classic) to Default palette?

It was intended to expand the layout of models such that the new bigger symbols can be accomodated.

With custom symbols for everything you are introducing a hell of complexity in your filter and additional challenges if you have any scripts looking at the symbols of occurrences or object default symbols.

The beauty of switching the palettes is that all your symbols keep their symbol type (type number, GUID) and all code just continues to work like nothing happened.

I do not understand in which mode you want to operate your production database in the future: Default or Default (classic)? Are you going to build old-style looking symbols for the default palette or new-style looking symbols for the default (classic) palette? In the former case you have to

build a filter with additional symbols and connection types for all model types in use

switch the palette

replace all default symbols and symbol occurrences with the old-style looking symbol

In the latter case you save steps 2 and 3, but you will never arrive at really using the new palette. That will remain a migration effort postponed into the future. And until then all your reports need revising and 4 times the amount of testing.

My strong recommendation: Stick with a single set of symbols of which-ever palette you choose. If it is the new one, go for a big-bang migration. The macro may play a part in this. Only if you have really large models occupying a large part of the available canvas you may be running into trouble, because of lack of space. Then you have no option but to re-layout those models first before the migration.

If you run into any other trouble using the macro, seek advice from the support.

And of course, test the migration until it works for you. :-)

One more note: If you offer every symbol twice, your modellers will go crazy mixing them as they please.
Like

Sign in
or register to reply.

Notify Moderator
André Vitor Oliveira on December 21, 2020

Hi Erik,

This kind of differences in symbol size could be an option in properties of the ARIS, to text visualization where have an option to resize the symbol based in attribute name. Maybe you have to turn off this one to keep the symbol as the first image (large symbol).
Also when you migrate databases from ARIS 7x version the symbols are classic and this is the reason about the 'palette classic' to see these 7x symbols in ARIS 10x. I would suggest you to keep use the ARIS default palette even if a database comes from 7x, and any kind symbol modification is better to do using the ARIS Template or ARIS symbol editor instead the filter.

BR

AO

Like

Sign in
or register to reply.

Notify Moderator
EM

Erik Mossing on December 22, 2020 as Reply to M. Zschuckelt

Thank you for your extensive reply!

There are few aspects that I obviously could have detailed better regarding the context of the problem.

Our current environment:
1. Migrated database from ARIS 7.x
2. Custom Filter and template
3. Customizations i terms of changed names on default symbols, derived symbols and custom graphics. Different approaches to customization has been used over the years. Truly a complex hell.
4. Differences between our EA framework and our ARIS configuration. An even worse complex hell.

Planned future state:
1. Same database as above. Mainly to avoid huge migration project. (this is of course a position that can change as there seems to be reason to do so)
2. One-to-one mapping of EA framework and ARIS configuration. This is achieved by deriving models and symbols and giving them custom names but default graphics. Perhaps a compex hell as well but at least a predictable complex hell. This is the main driver besides the updated look&feel.
3. Future modeling is only carried out using the new filter/template. The new filter is strictly following our EA framework so there is no risk of using old symbols as they are not a part of the available symbol palette. (A single set of symbols)
4. Legacy models can be viewed by chosing the old filter. This is also needed as we have a huge archive that we need to be able to use without migration. No new modeling allowed after new filter/template has been launched.
5. If an old style model is requested for migration there will be som manual work. Copy/paste into new model type, select new symbols for existing objects. Apply new template. Manually adjust model layout issues. Only used models will be migrated and the rest will eventually be archived in a separate db.

Regarding reports, we do not have that many that are being used.

I do not understand in which mode you want to operate your production database in the future: Default or Default (classic)

My initial idea was to let this setting remain at Default (classic) as I believed that the new filter and template was enough. All new symbols are using the new Default symbols only, regardess of this setting.

Are you going to build old-style looking symbols for the default palette or new-style looking symbols for the default (classic) palette?

New style symbols and let the setting remain at default (classic). Was under the impression that derived symbol graphics are not controlled by the default(classic)/default setting. Tried to find a way to assign new symbol graphics to the palettes without any luck.

One more note: If you offer every symbol twice, your modellers will go crazy mixing them as they please.

Yes, that would create the most compex hell yet :-) No, that wont happen. A combined filter fill be available only for those acually migrating models.

I have a local server so I can experiment with different alternatives. Will investigate your suggestions. Will also review the strategy to stay at the old database as that seem to make life a lot harder. A slightly less compex hell is our goal.

Thanks once again!

Like

Sign in
or register to reply.

Notify Moderator
EM

Erik Mossing on December 22, 2020 as Reply to André Vitor Oliveira

Thank you for your reply!

Do you know where this property is controlled?

The actual migration of the database happend when ARIS 9 was introduced but for some (lost) reason we didnt choose to use the new palette. Do you mean that even if the imported models use classic symbol graphics, the database should have been set to default?

I want to avoid customized graphics and only used derived symbols with symbols from the default palette for our EA-framework configuration.

Thanks again

/ Erik

Like

Sign in
or register to reply.

Notify Moderator
André Vitor Oliveira on December 23, 2020

Hi Erik

The configuration that I mentioned is find out in this way using the ARIS Cliet:
Options > models > representation > text attributes in symbol = Resize symbol

About the migration, any classic symbols remains to ARIS 7x visualization an after migration you can keep the same visualization just using the classic palette. However any migrated data will use the default palette which keeps the 'new' style of symbols.

And what you want to avoid customized graphics and only used derived symbols, you can do that. If you go to Symbols category in Administration and where have 'ARIS default' you can create a new derived symbol and will set in method Filter wich symbol you want to allow for each object type.

BR
AO

Like

Sign in
or register to reply.

Notify Moderator