Best Practices for Managing Map Scale

Overview

Scale is often the bain of any software landscape visualization effort. Anyone can successfully visualize several applications, but as this increases from 50 to 100, or even 1000, many visualize languages fall apart.

We will consider two different drivers/impacts of complexity here:

• Organizational: How the structure of your organization can drive visualization requirements, especially the need to split across several maps.
• Volume: How the raw volume of applications and integrations can impact who can understand your maps.

Best practices are labelled as essential, suggested or optional. Regardless of your circumstances, always apply the essential and suggested practices, leaving optional practices to your organisation's particular circumstances. As always, please get in touch if you'd like to discuss tradeoffs in more detail.

📘

Why read this?

The innate capabilities of Aplas software maps (e.g. auto-generation) can handle considerable scale, but it is possible to better handle this scale by adjusting your index metadata and using some more advanced Aplas capabilities.

Essential - Sizing applications

Each application in Aplas has an associated size. We often find customers who use the default size (Regular) for every application. They are missing out on a key capability of Aplas, gradual abstraction as a map is zoomed out.

Here are the available options for Map Size and our suggestions for each:

• Small: Small application/service (think a small town)
• Regular: Standard/regular application (think larger town or small city)
• Large: Core system (think large/capital cities)
• None: Don't include on map (often used for applications that don't integrate, e.g. desktop apps)

❗

Sizing is critical

Sizing applications in Aplas is a must for reducing complexity, at minimum a few Large applications should be included within each region.

Essential - Multi-level tag/regions

When a region has more than ~20 applications, it can be useful to leverage our multi-level tag system. By splitting up large regions into smaller subsets, map navigation can be greatly improved. It can be best compared to the hierarchy in geographic maps, from suburbs to states, to countries. Each level in the hierarchy is displayed only at certain zoom levels, enhancing the users' ability to navigate.

Suggested - Collapse applications

Some organizations have a significant number of very small services (e.g. microservices), which add a considerable volume of applications to their map. If appropriate, these minor applications can be converted into Aplas components. A single application can then be created to encapsulate the components on the map.

🚧

Defining applications vs components

Collapsing multiple applications into a single application should only be done with a consistent approach, as part of how you define applications and components for your organization.

Optional - Multiple maps

You can create many maps in Aplas to reduce the complexity of any one map. However, we suggest you only do this if there is a functional need to split maps (e.g. you have loosely related organizations in a group with few or no interdependencies).

🚧

Multi-map strategy

A multi-map strategy has tradeoffs, including not being able to display integrations across maps, and losing orientation when switching from a superset map to subset maps.

Via map application filter

A map application filter is a powerful method for generating a map that includes a subset of an index's applications. This can be specified when creating a new map in the Application Filter field (e.g. department = 'company a' & mapSize != 'small').

The advantage of this approach is that application filters can be specified after the index is built.

Via index tag groups

Another option is to use the tag group functionality of Aplas to achieve a similar result. In this scenario, each member organization has an associated tag group, while the group organization can also have a superset tag group.

The advantage of this approach is that each member organization can have a completely different set of application tags.

Optional - Single map many publications

The greatest advantage of a single, large-scale map is that everything can be viewed on the same page. However, this might not be appropriate in all cases, especially if you have organisational complexity (e.g. one group company is competing with another and should not be able to view everything).

To solve this issue with a single map, you can create multiple publications, each limiting which parts of a map can be viewed. This is accomplished in different ways depending on the publication interface:

• Metamap: Update Settings > Config > General > Limit Application Tags to whitelist which tags you wish to allow for visualization and search. The full map will still display, but applications outside of the specified tags will be greyed out and inaccessible (see below).

• Metasearch: Update Settings > Config > General > Limit Application Tags to whitelist which tags you wish to allow for search.
• Stylemap: Apply style source filters to limit which applications and regions are displayed. See our style designer article for more information.

👍

Single-map strategy

A single map with multiple publications is a great way to keep everything orientated together, but limit certain groups of users when needed.

Optional - Multiple indexes

In some circumstances, you may want a hard separation between different indexes. Generally, we don't recommend this approach as there is no ability to combine multiple indexes into the same map, style or publication.

Optional - Permissions

Once you've created a publication, you can head back into the Settings > Location to modify who has access to it and where it can be accessed. Possibilities:

• Set publication to Hidden on your landing page, then embed within a member organization's internal portal.
• Set publication User Access to limit access to users of a member organization.

👍

Share first strategy

It can be tempting to put a range of controls around your software asset metadata. But remember, the less people who have access to the information, the less likely they will contribute to its upkeep.